Securing AI Access in JD Edwards: Identity and Access Management Essentials
August 1st, 2025
13 min read
This session, Securing AI Access: Identity and Access Management (IAM) Essentials, provides a foundational overview of key security principles needed for managing AI and cloud environments. Led by Sean Mead, Information Security Officer at ERP Suites, the presentation explores the critical aspects of IAM—identity, authentication, and authorization—especially in the context of cloud infrastructure. From defining identities to enforcing role-based permissions and multi-factor authentication (MFA), the session equips participants with a comprehensive understanding of how to safeguard digital systems.
Table of Contents
Transcript
Introduction and Speaker Background
Hello everyone, welcome to the Securing AI Access. This is Identity and Access Management Essentials. This is meant to be a brief overview of some of the most important points of Securing AI access and specifically we are focusing on Identity and Access Management Essentials. With that being said, my name is Sean Mead. I am the Information Security Officer at ERP Suites. I'm in charge of the ERP Suites, cybersecurity as well as audit and compliance. And I'm a member of Infraguard, which is a collaboration between the FBI and the private sector. If you want more information on that, feel free to go to infragardinfragard.org and you can read all about it. And I am, I'm charged with not only ERP security, but also with advising our customers and making sure that we're keeping things locked down and, and segregated properly there. With that, I would like to introduce Brian Connor to you. We'll go ahead and get things started as as mentioned before.
What is Identity and Access Management (IAM)?
As mentioned before, this is on identity and access management. We're we're on the overall subject of securing AI access. So what is IM we, we see this term all, all the time or we see these this acronym for lack of a better term, and it's just identity and access management. This is a, as it states, a security discipline that focuses on who accesses which resources and when. This is a huge deal. This is one of the most important things and it is definitely at the foundational level of everything that we want to do security wise. It's the only way to make things focused properly. And as we look at this, we want to look at also in the cloud. We'll mention it overall, but we're of course targeting the cloud at this point and it is a zero. It is part of our zero trust approach on this or as we move into this with the cloud. So it involves managing digital identities, verifying user access, authorizing appropriate permissions. Basically what it really comes down to is we are trying to determine everything about who you are and what you're allowed to see or do.
The IAM Triad: Identity, Authentication, and Authorization
So let's kind of break this down and this I, I love this picture. It's it actually, I think people do get a little hyped up when they look at these particular terms. We're going to try and define these a little bit and take just a few moments to try and hit them more directly. So identity management, I, I love this. It, it kind of hit me one day that identity management, we enter into this in a company or in anything we access kind of the same way that we, we enter into it when we're born. For the most part, we have someone who is in the position of authority to give us a name. And that's what happens. We are given a name, then that someone in authority turns around and makes others aware of that name. So identity management, how we start as far as The Who are you? What name have you been given? Because from this point forward, we're going to be using that name that you are now given to determine what you can access. Specifically, we're talking about user accounts in the IT world.
Now, now that we've given you a name, then comes authentication. Well, how do I know that it's really you? How do I really validate that? Just because you're saying that the name that was given to you is you? How can I be sure that you're the one who's trying to access my reports, my Social Security number, my whatever? How can I trust that? Just a little bit of a story to give us a little bit of idea of how important this can be. I don't know how many people know of the person named Rich Little. He was an impersonator and is still alive as far as I know, but he's been doing it forever and a day. My point with him is there was a time when my understanding is he actually was being watched fairly closely by the rumor has it by the FBI for one very specific reason. The technology at the time could not distinguish his impersonations of certain people, including certain presidents by voice. So the technology at the time, if he were to impersonated by voice, he could nail it and it would let him in. This is important for us to realize because that would be a case where the authentication failed, not failed and was noticed, but failed to do its job. And it actually could have let someone in who was not really that person. They're just claiming to be that person and they sound like that person in his case. So verification of identity we do with passwords and the modern in this modern day and age, we use multi factor authentication. MFA, are you really who you say you are?
So after we've gotten your name, after we've established this is your name, you're telling me that your name. Now I want you to give me something that should be actually in the end, the combination should be unique to you. Not, not close to not, not, not rare, but absolutely unique is what we want. So although passwords are a great start and passwords should be of course very complex, especially with with big systems with a lot of important PII data, but passwords are really the base of an awful lot of things. So using a password vault or something of that nature may help people with this in order to have at least one really good complex password. But that still can be hacked when it's all said and done. So that's why we incorporate MFA as well to validate that you are who you say you are. I believe at this point in time, almost anyone who would even be in this seminar would have had experience either through your bank or through something else, even if it's through the SMS style, some type of one time password to make sure. And that's what authentication really means is now I have validated you are associated with this name that I have for you. That's great. Now we've got a person, we've got them identified. They really are who they say they are. What's the next step?
Well, that's authorization. So what are you authorized to do? Permissions that these are the permissions that an identity has to the cloud resources to whatever resources. I mean it it we're focusing on cloud today but it could be any part of that. What are you allowed to do by the ruling authority of that system? And so authorization is something that is usually not something that the users, right are looking at or it's not something that they enter in and say I have authorization to this and that. That should be in the background and that should have been given to them. So once we know your name, once we know you are who you have said you are in that account name now in the background, that gives you certain permissions and authorizations.
Identity Management in the Cloud
So in identity management we have we have these different sections and you can have we have the identity itself. So we've already spoken of the user account. So that is just the name at this point. This can be done in the cloud or with the cloud either in a non Federated manner or a Federated manner. The difference between those being the non Federated basically means you are doing something that is in the cloud only and Federated is we're somehow integrating it with one of our identity providers such as Microsoft Enter ID. And we can also go so far through that type of thing as to have automatic, I'm sorry, automatic provisioning. And these are so that Federated and non Federated, those are the two options for managing these identities in the cloud environment. And it it's important to to recognize that non Federated is it may seem good at the beginning, but Federated winds up making it to where you can see things in more of a single pane of glass. So basically your federation, your federation database, whatever that may be.
Let's use Microsoft enter ID as our example for the moment. That may be your database for identity and authorization in the end. And not just identity authorization, but I'm sorry, but also for authentication. It'll hold all of that, but it also allows for that automatic provisioning. Now, this is kind of a big deal and it definitely helps with logs and things of that nature because you can have a central database sending logs and letting you know when there are failures and things of that nature. Also want to point out there that there are another type of account. There is another type of account called an API or service account. Now these accounts really should only be used for integrations. They should not be used for login access. They should be kept separate and in their definition. Again that comes down to keeping keeping thing, keeping the guardrails in place in the right places at the right times. A service account that is using an API or being used by an API really should not have login direct log login access for many reasons, but not the least of which is usually an API service account can get into a lot of very critical infrastructure because it's it's how things are happening on the fly or automated in the background. And we'd rather users or that not to be directly hacked because it's a standard user account. So these are the different types of identity management that we have toward the cloud.
Authentication Methods and Best Practices
So now that we've covered the identity portion and the federation as far as getting those usernames and and even passwords to a certain degree, we're going to go into the next classification of authentication. And I realize that does include passwords, but let's let's hit those in a more direct fashion or in these quantities here, Single sign on a common encrypted database of usernames and passwords. Well, this can be through ADFS, this can be through Intra ID, this can be through Octa. There are there are various products out there that allow for single sign on databases. This in and of itself single sign on does not automatically mean multi factor authentication. So I I think that's worth mentioning. Just because we say that we have SSO or single sign on, that does not automatically mean that there is multi factor authentication attached. And that's why that's our next bar here, multi factor that is a method of verification beyond just the password and it's meant to be in addition to a password or even biometrics and such as a one time password.
So one time password is a an interesting phrase that we use for a lot of different things. It can be an SMS multi factor. It can wind up being we use for example and and a lot of companies use Cisco Duo, some use Microsoft Authenticator. There's all kinds of different products out there to do this one time password event or or occurrence and that is attached of course to your password and your username in such a way that these things must all be present to get you in. I cannot say enough about for the cloud especially how important multi factor authentication is because passwords get hacked sometimes people don't put as much effort as they should into passwords and multi. Once you get a database of username and passwords that's that could be the end all that could allow people to get into your systems. But with multi factor authentication and that one time password, depending on what form you have taken that in combination with the other, it is a very nice front gate and is very much safer than just a password. Furthermore, and the cloud we can also go location based. So we can set rules concerning where a user has to be or can be located to access the resources and and that can go across the board. So we may have a user that is authorized to access, I don't know, we can let's say the most the deepest, darkest secrets of our company, they are allowed to access that in the systems as long as they are in the state of Ohio. Now whatever our reasoning is for that is not as important as just the fact that we can specify location based. So we don't want them to be able to access that stuff if they are outside of the state of Ohio for whatever reason.
Now let's make that a little more broad and let's say in the United States, there are certain things, certain entities I don't know, such as the Department of Defense, who would probably prefer that from you not access their databases from certain countries. And so location based is another one of the tools that we have to create allow lists or block lists when it comes to someone being able to get in in the 1st place. Now I mentioned about biometrics, Please note this is not MFA. Multi factor authentication is different. It is the one time password. That's how we do things in kind of a timed fashion and a coded fashion. But biometrics can be a password replacement, and it is used by many companies and even people with laptops, I know that may not consider it this way, but biometrics can include not only fingerprints, which is the first thing that people usually imagine in their minds, but it can be facial recognition, things of this nature. Depending on what type of phone, smartphone you may have and how you have set it up for access, you probably are using this on a daily basis.
Authorization Structures and Role-Based Access
So we've hit the identity, we've given the person an account, a user account, a name. We've now given them the ability to be recognized the the authentication. So this is, we now believe this person to be the real person who should be able to access anything based on or that has been given to this particular username. So now we get to authorization. So what can they get to? What can they see? So default security roles, default grouping of user accounts created to manage the cloud. When we get into the cloud especially, there is role based security that should be engaged right out of the gate. Default security roles such as the security department, such as the database administrators, application specialists. These don't necessarily need to all be able to see all of the same things. So we create default security roles in the cloud to make sure that we can divide these up and it makes it very scalable if we are using a role based or role based security. So these default security roles not only help us with that role based and make sure they they remove a bunch of human error, it also makes it make it easier to classify groups. But it also helps a great deal in scalability policies. These define permissions to the resources in the cloud environment. They are attached to these security roles.
So let's let's look at this. What are we supposed to be allowed to do when we are in the cloud? So the default security roles are based on what you need to do. So security has access to security controls. We, we touched on this like cloud guard and response recipes, things of that nature. But we also have networking. They should have access to the networking compartments. These are policies that are put into place that define those permissions. So if this per if this security role is called networking, then we're going to create a policy that says you're allowed to see anything that has to do with how the packets travel from below 1 machine or one location to another. That is, that is your realm. By doing that, those two link together and now we have a permission. This defines what abilities are associated to a policy such as read or manage. So we have a policy that defines who the members of the group are. Then those security roles are built around that based on those and then the permissions, what specifically are you allowed to do? Not just see, but do? Are you allowed to have read only access or are we wanting you to be able to actually make changes in the environment? So, for example, security, if you're in the security role, the policy states that you should. In this case, we're going to say that the policy states you can see everything, but your permission is only to read because the networking personnel or the application people are the ones who are actually making changes or should be making changes. Security should be able to see it, but not necessarily to make a change in there. If we define these things using these security roles and policies and permissions in the cloud, it becomes very scalable. And furthermore there are pre configured ones. For example in OCI when when we're using a landing zone especially there are pre configured security roles that are already set up and ready to roll. You can add more as you need to customize them, make sure that they are configured properly for your organization. But this is but all of these together and especially that now the last one is more telling us the benefits of the authorization. But those first three, those are the definition of the way we do authorization in the cloud and that's what makes it scalable and pre and then we can use pre configured policies as well.
Questions and Closing Remarks
So we do want to thank you for this. This is meant to be an overview. We did not get into a whole lot of details of the how necessarily, but hopefully we've covered some of the what and why of of this this subject area over overall with securing AI access and access to the cloud. Actually any kind of identity and access management, these are essentials in doing this. Brian Connor is our Director of JDE Security at ERP Suites. He has been in JD security for you know a couple years and actually several and he has helped customers and clients across the globe quite literally. So he is very qualified in that position. I just want to at least give some introduction even though we couldn't hear from him directly.
Are there any questions? You can put them into the chat. If there are any questions, we'll still give it a moment. I'll ask for the next slide while we're waiting in case there are any questions. I know it takes a couple of moments for it to pop up. So as far as if there is anything out of this you would like to delve into more deeply, how can we help you? Well, the best way is to talk with us and there these are some of the different activities coming up where you might come up to our booth or come up and see us and including of course contacting an account manager or calling ERP Suites directly. With that, I'll give it just another moment. So Brian has popped up, is SMSA secure method of MFA? Overall, SMS is not considered as secure a method of MFA as one time passwords as Microsoft Authenticator, Google Authenticator, you name it. Just fill in the blank authenticator. SMS is not considered as secure as much as anything because it is. It has a much longer time attached to it. So if you're using SMS for your authentication, you're going to have to have your timeouts in minutes at least, if not hours. And whereas A1 time password usually recycles any in the seconds, we, we measure that in seconds. So I would not consider consider SMSA good secure method of MFA compared to all the other options that we have available out there.
Any more questions you can still post them in here or reach out to to any anybody from ERP Suites and we'll be able to follow up with you and I don't mind staying on here another minute or so and give everyone one last chance. I want to go ahead and once again, thank everyone who attended, everyone who's still on here, thank you for your attention and thank you for your time. ERP Suites appreciates it very much. Thank you.
Topics: