Beyond Passwords: Modern Authentication & Authorization for IBM i

Aaron Magid 00:00
Sessions thus far, I guess session, I should say thus far is some common vulnerabilities that we see in IBM applications and how we can mitigate those as our applications move into the next phase of their development. Right. A lot of different companies that I’m seeing are adopting a lot of new technologies. They’re adopting a lot of new architectures. And those architectures and technologies naturally come with some concerns. And what I’m seeing, I think the, one of the inspirations for this webinar series is that what we’re seeing is that a lot of the ways that these technologies are being implemented are creating problems for companies. Meaning somewhat ironically, I see companies implementing authorization systems to try to make their systems more secure, but doing it in an incorrect way that actually creates deeper problems or more easily exploitable vulnerabilities. So we want to make sure that we’re, we wanted to come out and provide some information here and some walkthroughs that’ll help your applications use these technologies effectively and also make sure that we’re all clear on what some of the initial steps are that we can take to start securing these applications. So just taking a look at this, I wanted to cover a couple of really key points up front in this discussion. There’s three, three main points that, that I want to point out here from what I have observed in the companies that I have talked to. One, number one, and this is going to hit in a lot of the things we talk about today, number one is our teams and our applications need to be extremely agile. What I mean by that is there is. I talk about this a lot actually in my presentations. There is something of an arms race happening between hackers and security professionals. Right. That’s been going on for a long time. That’s not really new. But what’s happening there basically is this process, right, where we have a security system, we have an encryption algorithm, something like that. Either a hacker or a government or a state or a government sponsored hacker cracks that and starts breaking into systems. And so we then up our security game to cover that, to patch that hole, basically. And then they find the next one and we move on from there. Right? And as technology moves, technologies that previously may have been secure are no longer. A lot of presentations that I’ve seen touch on the, the topic of encryption and quantum computing, you know that a lot of, a lot of security systems are based on the. For example, a lot of security systems are based on the amount of time that it would take to break in, meaning it’s possible to Break in, it just would take you a billion years or a trillion years. So we don’t really care. As technology advances, computers get faster, those numbers start to come down and they actually start to get into a threshold or into an, into an area where it’s actually feasible to start breaking them. So anyway, all that to say we have to make sure that we’re moving, that we’re moving forward and that we’re able to respond quickly to threats. Because what happens when a vulnerability comes out is the vulnerabilities are published and everybody knows about them, right? And so at that point, every hacker out there worth their salt is going to try to get into your systems using that new vulnerability. If anybody remembers you when, when the log 4J vulnerability happened, right, there was a massive flood of attacks that happened. Because once that kind of vulnerability comes out, everybody’s looking for it. So we need to be able to respond quickly. And so there are some pieces that we’ll talk about related to that later on here. Another piece that I have observed in IBM I shops, the IBM I has a security system unlike any other platform. It is incredibly powerful in its permission management capabilities. You know, you probably, if you’ve been to any of our other presentations, you’ve heard us talk about how the security is embedded in the operating system, meaning you can’t sort of get under it, which is a common method of breaking into other platforms because the security is actually down all the way network throughout the entire system. And you have the ability to set very, very detailed access controls on specific objects, down to specific permissions on specific objects in your applications. The thing I’ve observed is that nobody does that. What I’ve observed in my travels throughout a lot of different IBMi companies is that it’s too much work to do that. And so we need to make sure that we aren’t relying on that if our team isn’t actually going to do it. And so that’s one of the key things we’re going to talk about here, is strategies that we can use to get those benefits more easily. And the last thing that I want to mention is almost every time that I have seen a company contemplating throwing out the ibmi, we’re going to ignore the feasibility of that for, you know, for a minute here. But every time that I have seen a company I think talk about that, the conversation begins with everybody in the organization does something this way except the ibmi, right? Everybody in the company is using our standard OAUTH system except the IBMi. Everybody’s got MFA except the IBMi, everybody’s got SSO, except the right, it’s always an accept. And that’s where that conversation starts. So as a side note, outside of the security, one thing that I want to mention to the IBMI professionals in the room is that if you’re getting those kinds of, those kinds of criticisms of the platform, if you’re starting to see that, that there’s a threat there to the longevity of the platform, or if it’s being questioned, these paths where we start talking about standards, they’re a good first step for you because what you might find is that if you can resolve the non standard aspect of your, of the platform, you might actually see those criticisms start to shrink. And I have actually watched that happen in companies.

Dan Magid 06:36

Aaron, not to interrupt you, but IBM announced today that they will have native MFA in 7.6 of the operating system.

Aaron Magid 06:48

That is amazing. That is very exciting. Thanks for saying that because I actually haven’t seen that yet. I knew they were working on it, but it just came out today. Yeah, wow, cool. Great. So we’re going to talk about those things and we’re going to talk about some points that we can use to validate the solutions that are available to us. All right, so let’s jump in. So as we talk through this, the way we’re going to go about this session is we’re going to start with a, with what I would term a typical IBMI application. And that’s, that’s typical in my experience, meaning of the applications that I have seen. We’re going to start there and we’re going to work through some of the vulnerabilities that are there that I see almost every day at a new company. Almost every day I see these vulnerabilities and they’re present everywhere. So we’re going to talk through these and we’re going to talk through what we can actually do about them. So let’s start out here with this application. There’s two major attributes that I want to cover in here. This application that we’re going to talk about, and I see this all the time, is we’ve got an application that is accessible via two methods. You’ve got direct 5250 access for some users and then you got A web app somewhere.net Java node, Python, doesn’t really matter what it is, that application is generally going to be coming in over a direct database connection in most of the systems that I see. So you’ve got 5250 access to the screens and then you’ve got direct ODBC or jdbc, whatever the equivalent is for your particular system coming into the database and interacting with it. And there are some problems there that we’re going to talk about here. So let’s jump over here and let’s, let’s pull up that application. So over here what we’re looking at is a diagram of that type of system, right? So I’ve got my IBMi on the left and I’ve got a, I’ve got my database, I’ve got programs and I’ve got screens right in this application. Obviously an extremely simplistic view of the IBMi application, but I think it’ll, it’ll do for what we have here. Now there’s two ways, two types of users that we have here. We have 5,250 users on the right side. These guys are going in directly to the screens. And then we’ve got our web app users that are coming in through this web app through some process. We’re not going to get into how that side of things works. And then that web app is then talking over a direct database connection to the database. So it’s bypassing the screens and the programs coming in directly to the database. Right. So these are our two processes. Now just a quick side note, I’m not including what, what we call screen scraper tools, the GUI, the IBM screen modernization tools, because behind the scenes they’re typically operating in the same function. So we’re more interested at the low level how you’re actually talking to it, meaning in our terminology here, if you have, you know, a web app generator that’s processing your 5250 screens, I would still term that from a technical perspective a5250 user, because under the hood they’re actually still using that, that screen interface. So just, just a point there as to why that’s not on the diagram. Now there are a couple of things that can be problematic within this application. I’m actually just going to, to switch over here again for a second and those are in this application we, we are using, we’re using password based authentication, direct password authentication with direct user profile access typically. So on the 5250 side, we’re using that direct profile access with, with password based authentication. So looking at our diagram here, what that means is our 5250 users are providing, we’re focusing on this side. Our 5250 users are providing their password to a user profile on the platform, on the actual IBM to get into this application and use it. So you have a direct user profile on the system and, and they’re sending in their password. And there’s a side note that I want to make here and I’m going to explain why in a second. And that note is I have, I have not seen an application in my experience that does that outside of the IBMi world. I don’t think I’ve ever seen an application that does that, that gives you direct user profile access on the physical server that the application is running on. Right? If I run a web app on, you know, on a Linux machine, for example, I don’t give people profiles to connect into my Linux machine. And the reason for that is because it’s pretty trivial once you do that to get around these screens, right? We talked about how the security of the IBMI is powerful because it’s networked directly into the operating system. When you put in through these, when you, when you do this access control through the screens and when you use what’s termed menu based security within there, what you’ve essentially done is you’ve lifted up your security layer and created a gap in between the, the machine and the actual application. What I mean by that is if I have an attacker here, grab this guy over here, this guy comes into your network and he says, oh, I know the IP address of the IBM I and I was on this guy’s computer, so I have his credentials. So what I’m going to do is I’m not going to go through the screens, I’m just going to connect directly over the network and open up a database connection. Right now all of a sudden I have access to, to do things that the application wouldn’t have wanted me to do. And the reason I can do that is because I have a user profile on the machine, right? And that’s why we don’t want to do this. That’s why this is not good from a security standpoint to have that situation. Now again, almost every application I’ve seen has that situation. So we’ll talk about how we deal with that in a minute. But this is the critical problem, right? This user profile can be abused. Now the response to that, this is why I covered it up front, is you could say, oh well, I’m going to manage every object and I’m going to make sure that you only have permissions to do what you need to do on your user profile. And if your company is able to do that, that’s amazing. I have generally not seen that in applications. Meaning what I have seen typically is as too much work. And so what happens is eventually you end up with a template or a wide, a sort of wide brush authorization that you give to your users that says you have access to this set of objects. And what happens over time is objects are added that really don’t need to be in there. And what that does, what that means is that this attacker has access to things that they really shouldn’t have access to. And unfortunately you don’t usually find out until it’s too late. So that’s one of the key points here. We don’t want that kind of authentication. The other piece, there’s actually a problem with both methods here. I want to make sure to talk about this because a lot of groups I think are under the mistaken notion, I would say that the web app is secure because it’s not doing that. So the web app here also has a problem. The web app is doing a direct database connection into the ibmi. And I know, you know, you can’t respond here obviously because it’s a one way webinar, but I, you know, I, I encourage you to think about whether or not you’ve seen this kind of thing in your company. I see it in almost every company that I work with. And that is eventually this web app ends up having a profile on the IBMi that is massively over provisioned. Meaning there’s a, there’s a story that happens here that I see almost every, almost everywhere. Basically what that is, is you have the web app team that needs to talk to the IBM I team and they keep on sending in their requests and they keep on calling to the database and they keep getting rejected, right? They need a new object, they need a new database table and they don’t have access to what they need. So they put in the call to the IBMY team, the IBMI team responds, they get the access that they need and it takes some time. Well, eventually both teams get tired of that arrangement. The web app team doesn’t want to wait because they’ve got a deadline and the IBMY team doesn’t want to keep being bothered with that. And so what ends up happening is this guy ends up being an all object profile. And that is really, really bad because what that means is that I’ve got a web app here that is external to the IBM I running on a separate machine that has credentials to the IBMI that can access anything on the system. And this machine is usually accessible to the Internet. So now this guy go back to our little attacker over here this guy says, oh, if I can get into this Windows application, I don’t even need to deal with IBMi Security. Yeah, the IBM is solid. I don’t even need to worry about it. All I need to do is get into this guy and I’ve got credentials then that have all, you know, that have all object authority on the. I do whatever I want, right? I’m, I’m free at that point, right? And I’ve watched these vulnerabilities take shape and I watched them exploited and it’s really, you know, it’s a, it’s a very natural thing that happens, but it’s, it’s a huge problem from a security standpoint. So what I want to go through here is, okay, what, what can we do about these two scenarios, right? Both of these access methods have huge problems, right? One is again just to recap is the direct profile access and with passwords, which I, you know, I will say actually I do see a lot of people who have, for example, like a Word document on their PC or a sticky note on their PC that has unencrypted their IBMI credentials in it, which again I understand why people do it, but that just, you know, exponentially increases the danger of this setup, right? So we’ve got poorly protected credentials that can be used to connect to the machine and we’ve got over provisioned credentials from another direction that can be used to access the machine. So both ways we got a big problem here. So let’s take a look at what we can actually do about that process or about that, that type of application. Well, the first thing, let’s target that 5250 access first, right? So just for reference here, we’re talking about this guy, this guy that’s got direct profile access from human users. The problem here is that you have an attacker who comes in who gets the credentials and then can access the system directly. So one great way of dealing with this that is used across the industry is adding in a layer of multifactor authentication into this system, right? If I have multi factor authentication on my 5250 sessions and I’ll talk about, we’ll go through very briefly what that is for anyone who’s not familiar with it. If I have that, then if that attacker gets my credentials, they still can’t get into the system, they still can’t get into the application because this is for a human user. And we have an additional factor beyond the password that they’re going to need in order to get into the Application. So MFA is a fairly clean way of getting this in. Now actually implementing it in the IBM. I take some work and I’m hoping that IBM’s announcement will make that easier. It does take some work though, and we need to make sure that we’re using it for all of the access methods that our users have. So we’re going to actually go through this. But first I want to just mention that kind of back to the initial thing that I said in this presentation. Just having MFA checking the box that we have, MFA is not good enough. Right. We need to make sure that it is actually secure and that it is actually fitting with our organizations, our organizational standards. Right. So there are some pieces here that go beyond just saying, okay, great, I’ve got an MFA system. Now I can sit back and you know, watch the attacks be repelled. Right? That’s not going to work. So let’s jump in and take a look at MFA and, and how we can get that done. So first of all, you understand the basics of mfa. So fundamentally what MFA does, multifactor authentication is we, what it does is we have an additional factor with which to validate our user, right? Password based authentication has one factor. It has a password that is the one thing that you are using to validate the user, which since it’s based on something that, based on knowledge, it can be stolen, it can be taken off of your machine remotely, relatively easily. What multi factor authentication does is it says we’re going to add an additional piece that is different, that is fundamentally different. For example, something the user has like a phone, like an authenticator app, like a key generator fob or another device and it also, or, or it can add something that the user is. Meaning biometric authentication, Right. Probably you’ve all seen this kind of thing. You know, your banking app on your phone might, you know, scan your thumbprint or do a facial recognition to get you into the, into the application. That, that’s the, that’s the other option is getting those kinds of pieces, those kinds of systems in. Now what that does for us, going back to our diagram for a second, is let’s say this attacker has the password to a user. Well, this authentication process just got more complicated where what happens is you authenticate and then you have an MFA provider up here where this screen then comes out and it says, hey, is this person validated? And the MFA system then goes back out to the user and, and says,

Aaron Magid 21:28

can you confirm this? Right? And then the user confirms it and then the screen will let them in. Now the power of that is that the attacker has your password in this scenario, but they do not have your phone, for example, they don’t, they haven’t swiped your phone on the street. And so what happens here is they go to the screen and they say, here’s my password. And the screen then says, let’s check. And you get a notification on your phone that says, hey, are you trying to log in right now? And you say, no, I’m not. And not only will that block this access, but it will also usually flag it so that you can actually investigate the address that it came from and potentially report and block that, that user. Right? So we need to make sure that. So, so this process improves the security of this flow because it allows us to set, to ensure that just having the password is not enough to get into the system. So we set that up in our last, our last presentation. I just want to go through this really quickly so you guys can see that this actually can be done.

Aaron Magid 22:41

So what I have here in my application, this should look pretty familiar to everybody. So what I have here is my, my MFA enabled 5250 application. And what I’m going to do is I’m going to try to sign in. So I’m going to come in here and I’m going to say MFA user, right? My lockdown user. And I’m going to sign in, right? So it’s normal. I’m not doing anything different here at this point. Now what’s going to happen is when I try to log in, that’s going to send a message over to my phone that says, hey, is this you trying to log in? And it’s going to give me an approve or a deny button. Now I’m going to come in and I’m going to say, yeah, that’s me. I’m going to say approve. And that’s going to let me into the 5250. So now we know that I am who I say I am with much more certainty than if it was just my password. Just for reference here. I sign off and I come back down here and I sign in again. And then this time I go in and I say, and no. And then I’m going to say, actually here, you can see it actually says, is this suspicious or not? I’m going to say, no, it’s not suspicious. And it then kicks me back out to the login screen. So we did a deeper dive on this, a deeper demo on this last time. I’m going to switch back over to, to our diagrams for a second to explain how this works. Because that’s really what we want to add today is, is how we’re actually doing this. So when you do mfa, right, what happens here is we send our password, the application, and then we’re going to have a secondary validation step, right? And so what that’s going to do is that’s going to enhance the security of our 5250 connections by ensuring that, again, I am who I say I am with more, with more validity or more certainty than just with a password. So the way this works is my5250, you bundle in with the user, my5250, right. It’s going to talk to the screens. They’re going to then go request a push notification or like we said in our diagram, and that’s then going to go out to my, to my phone and, and back to the mfa. Now, what we need to make this happen is one more piece here. We need a connector system in here that will allow us to, that will allow that screen application to actually make the MFA call, right? So what’s happening here is the screen is sending a message to a connector application, which is then handling the MFA flow and telling it exactly what to do. Now, in this particular case, just to give you another piece of information about this, the way that the authentication is happening is we are hooking on to an initial program for this user. So the, the user is as limited capabilities and comes into their initial program. That program, when it’s, when it runs, does the MFA call and, and kills their session if they are not allowed to, to come in through the. Or if they’re. MFA is rejected. Right. So that process allows us again to, without modifying the internals of our existing application, we can go in and we can actually add on MFA in here. So just as a general strategy for you to look into, it’s a powerful thing. Now, there’s a couple of things that we need to watch out for with this process, right. So we’ve done a little bit of work here, right. But we need to make sure that we haven’t just said, okay, I’ve checked the box, I’m good to go. Right. We’re not done yet. So a couple of things that I want to call out here. The most important one for MFA is we want to make sure that it is using standard MFA providers. What do I mean by that? I have seen MFA implementations that use either a homegrown system, you know, a small, a small, not widely used system, or can Use a very, a powerful system, but not an industry standard one. There’s, there’s problems with both of those structures. One is whenever new software is developed, right, you’re, there are always problems. We want a battle tested system, right? So I would not write a new MFA system. I wouldn’t go, go through that because there are companies out there that, that’s their job to do your MFA for you and to do that security and that, that device validation, that is a much more trustworthy way of doing it than something that is provided by either a homegrown system or even honestly a smaller vendor. Right? That’s not, that’s not the route that we want to go with these. Because the problem that we’re going to have is we want again, your security systems will be the, your security systems will be the biggest target of attacks. We need to make sure these are battle tested. Really, really solid integrations. They don’t just get the job done. They have to be go beyond that. And another piece is if your IBMI is using a different MFA system, even if it’s bulletproof, it’s using a different authentication system than the rest of your company, then that’s going to create security problems for your business because it’s going to slow down your ability to react to changes. It’s going to slow down the organization’s ability to implement new requirements as required or new systems as requirements change. Because they’re going to have to change things for the whole company and then they’re going to have to go over the IBMI and change that system. And again, going back to our original, to one of the original points that I made, that is also going to draw more criticism to the IBMi because you’re still going to get that criticism from the CIO saying everybody in the company is using Duo for mfa. But then when we go to the IBM, I’ve got to use this other system that doesn’t support what everybody else is doing, right. So it doesn’t solve those problems, doesn’t address those problems. We’re not using a standard system. So I just encourage everybody, you go into this, make sure that you can use a standard provider. When I went into this demo, I am using actually here, I’ll show my phone again. I am using Duo. You can see the app on my screen. I am using Duo for this integration. This is not something that Eridani built, you know, an MFA provider. This is not something that is homegrown. This is not just something I downloaded. This is a bulletproof, battle tested security company that is managing the mfa and I’m getting my IBMI to talk to that. That’s something that I can rely on. So that’s a key point here. Another piece is we haven’t addressed the direct ODBC problem, so we’re going to go talk about that one next.

Aaron Magid 29:38

So once we’ve got that set up, once we’ve got our mfa, right, We’ve now helped out with this side of the system, the 5250 side. Now we’re still giving direct profile access, which isn’t great, but in many applications on the IBM I, it’s a much larger effort to, to get away from the 5250 entirely. And again, screen scrapers don’t do the job. They don’t get that part done because they’re still going through it behind the scenes. So it’s, it takes work to do this. So we’ll talk about that in a, in a later stage here. So we’ve covered this side, right? So this part that we have now helped out with, right? We basically said, okay, this guy’s pretty good, right? This side of things is pretty solid, but we have an issue with the, with these, with this access here, with this direct database access. And again I have watched these vulnerabilities come up and I have seen them exploited. Right, because again, just to reiterate on our situation here, we have a, a web app here that has direct, usually over provisioned credentials to the ibmi. Now there’s a couple of impacts of that. So let’s zoom in on this guy. There’s a couple of impacts of that. One is that the IBMI team doesn’t really own the IBMI’s resources. And that’s sort of an interesting point. So I want to, I think. So I want to dive into that a little bit. What do I mean when I say the IBMI team does not own the ibmi? Well, what I mean is the IBMI team can’t work freely on their application because other teams have direct access into the system. So again, another point here that, that may resonate with you. I’ve seen this over and over and over again when we have this kind of structure where we’ve got direct odbc, especially with these higher permissions. The reason that’s happening is because this web app needs to access our database or it needs to access our programs. If it’s going directly at our data, which is the deepest level of our application, that means that this web app has to deeply understand our IBM I application for Example, it needs to know what your database table layout is. It needs to know what all of them are so that it can write the appropriate queries. It needs to know what each column is, what the names are, what the types are, how it’s all set up so that it can set up integrations effectively. The problem with that is that this creates an extremely tightly coupled integration between these two systems, right? So this guy is very, very rigid in how these two integrations are, how these two systems are talking to each other. What that means is the IBMI gets locked in to its current to its existing state. Meaning if I want to make a change to the IBM I application potentially to patch a security vulnerability, and that’s going to change a column in one of my database tables, I can’t do it because I need to go call the web app team and say, hey, we’re going to change our database. So you need to change all. You need to go through your whole application, find every single query that interacts with this database table, and you need to make sure that you’ve updated it so that it fits with our new structure. And then what’s going to happen is your web app, if you’re lucky, you get a quick response. But what I see typically is the project manager on the on the web app team says, well, I don’t have time for that. I got a product release that we’re trying to get out, so we’ll get to it in six months. Or if you’re lucky, we’ll get to it in three weeks. That means you’re waiting three weeks to make a security patch to your application while you’re waiting for the web app team to go fix their stuff, to go update their side. Because if you make the change without talking to them or waiting for them, their application breaks. So what that ends up doing is it slows down the IBM I to a crawl where we can’t maintain the system, we can’t keep up. So vulnerabilities come out. And we have problems with maintaining our system and staying up to date because we’re locked in tightly to all of the other applications. So the next thing that we want to do is we need the IBM I team to own the IBM I application. And that means we need to go like this. We need to put a brick wall in between that web app and the IBMI’s internals. And this is a concept that is known throughout the software industry, that is widely followed. And this is the concept of you build it, you own it. Meaning if I Build the application. I own it. You don’t get to touch my data. You don’t get to go into my database and interact with my programs directly. I will tell you how you can talk to my system, because the problem is that any platform will have this problem if it is designed in this way. And the thing is, almost every IPMI application that I think I’ve ever seen has this kind of structure in it. And again, it’s not that it’s an unreasonable thing. It’s not that somebody did something wrong, you know. You know, early 2000s, this was the way to get into the IBMI. This was the thing that you did, and it was the best way to do it. So it makes a lot of sense. Thing is, we’re not in the early 2000s anymore. And so what we want to do is get to an architecture that fits with the modern technologies that are available to us now on IBM. So let’s talk about what that is. So in here, we want to set up a business function interface to our IBM I application. And everybody will go through that layer. And what that layer is most commonly is a REST API. Now, you know, there’s plenty of other ways of doing this. You know, messaging systems are totally valid. You know, Kafka is totally valid. All those other service buses totally find message queues. The important point here is you’ve got a standard interface that says you will talk to the interface and it will figure out what to do on the IBMi. And critically, that interface is owned by the IBMi team. That’s really, really important. Because if I create an API here. So here, let’s close this guy up a little bit. And we’re going to say, okay, we’re going to put in an API here. If this application, this API is owned by the IBMI team, then we’re not locked in by these connections. Because what’s going to happen is this API, because it’s maintained by this same team, they can coordinate changes to that API so that if they want to promote a change to their application, they own the API, they can update it. They’re not calling a project manager on another team. What becomes extremely dangerous is when you have another team that’s maintaining that business interface to the ibmi. And again, I see this all the time, because what happens is if that is maintained by another team, then we haven’t actually done anything. Here we’re in the same situation that we were in before with a dot net team is maintaining the API goes in directly to the ibmi, which Means we have to call their project manager. We got to work with their developers. Everybody’s got to know everything about everybody else’s business. We haven’t actually solved any problems. We still have the maintenance nightmare. We still have the security problems. We’re still moving at a crawl in terms of our application development, and we’re still breaking stuff in production because we have this organizational structure that is creating problems in the application. So critical, critical point. Just having an API in your ecosystem doesn’t solve this problem. We have an API and it’s maintained by the IBM I team. It is part of the IBMI application. And what that API does is it says, I’m not gonna give you an interface to run a query against my database because that encourages you or makes you tightly coupled to my system. I’m not gonna do that. What I’m gonna do is I’m gonna give you a business function over a secure interface to get into my application. Right? So. Meaning we’ll get into an example of this in a second. Meaning you don’t get direct ODBC access to my system. What you do is you talk to my API when you need something, you authenticate securely and you call a business interface. Meaning you don’t say, run this query to, to get the account data. You say, hey, IBMI give me the account data, and we will figure out how to get that data to you. We get to own the system. The IBM I team owns the system because they own the IBMI application. That’s how we want to set this up. That will allow us to move faster. And it also solves the problem of the direct, highly provisioned profiles. Because the net team doesn’t even have a user profile on the IBMi, they call your API. And your API talks to the IBM I database. That’s how we want to set this up. Let’s do it.

Dan Magid 38:58

Aaron. It also solves the problem of people connecting to your database that you’re not in control of. So you don’t end up not being able to maintain. You do reorganize your database tables or do other kinds of maintenance functions because somebody keeps connecting to your IBM.

Aaron Magid 39:15

I’ve seen that. We’ve seen that. I don’t mean to laugh at other people’s pain, but it is kind of funny to me that people get into this whack a mole game where they’re trying to kill a database connection. And because the NET team is really good at what they do, they set up their system so that if the database connection drops, they just connect Again, you got your IBM administrator who wants to make a change to a database table that won’t affect the application, but they can’t get a lock on it because there’s a connection open to it that’s using it. So they kill the connection, another one opens up, you know, 10 milliseconds later and they keep on, you know, wait, wait, I just closed that. Like, you know, going through and trying to get these things to, to shut down. Yeah, we, we see that, we see that a lot. And again, it’s just another example of slowing down our maintenance to a crawl, which means we can’t keep up with standards, right? Not even ignoring zero day vulnerabilities and things like that, which I, you should never ignore, but ignoring it for a moment, right? We can’t keep up with the standards, we can’t be ahead of the curve because we’re stuck waiting for all the other teams. So again, put that brick wall in there, cut a little hole in it that says you can ask me for this and I will figure out how to do it. You put a mailbox in there and you say, right, you put your request in here, I will process it and give it back to you. You don’t get to see what’s behind that wall. That is how you separate these systems out so that you can get much more effective systems. So let’s jump in and generate an API. We’re going to, we’re going to take a look at this and how this functions. So again, thinking of this as though we currently have an API. Let’s say we have, we currently have an API that uses, that has direct ODBC access for the applications that need to talk to it. So what I’m going to do here is I’m going to go over to my API system and I’m going to say, I want to generate an API. So I’m going to do here is, I’m going to say, okay, let’s do the simplest API that we can come up with. So we’re going to do what we call a one to one.

Aaron Magid 41:25

So I’m creating an API here that will go out and get the account balances from one table. And I’m using this QIWS QCUS cdt, which you all have. So you can replicate this example if you want me, give this a name and I’m going to say, go ahead and create an API for me. Now I want to say up front, the way this is going to come out of the system initially is the bad API, right? Or at least there’s at least one attribute of it, which is bad, which is that we call this a one to one. A one to one is an API that’s one endpoint that just runs one function and returns the result directly. If you build APIs like this, you haven’t really solved the tight coupling problem. And I’ll show you why. Because if I compile my API,

Aaron Magid 42:13

give this a second. I think I’m asking a lot of my computer between the screen sharing and the compile. All right, then we start this guy up. Then what I’m going to do is go over to Postman and I’m going to call this API. What I get back is the records from the database exactly as they exist in the database. Which means if I change one of these columns, it’s going to change the output of my API, which means the. NET team is still. It’s a little bit better, but they’re still writing code that has to internally understand my IBM I structure my IBM I database. We don’t want that. So this is better, but it’s not 100% of the way there. So what we want to do is make this a more abstract business interface. Meaning we’re not saying, run this query for me, we’re saying, ask me for the account balances and I will give them to you. You don’t care how I do it. So what we’re going to do here is we’re going to update this guy, make this a little bit better. I’ve got my structure here and I’ll show you what this is. So what I’m doing here is I’m saying, okay, I’ve got a query that returns an array of records like this. I’m giving it an example and I’m saying here I’d like to change it so that the records look like this. And what I’m doing is I’m just doing a data mapping here, but that can have a really powerful impact here. If you notice, this column is going from custom to customer number. The customer data is going from a flat structure with these column names over to a more complex JSON structure that is more oriented toward the conceptual data that we are actually working with. Right. So these are all critical things when we’re working with this, with this type of system. Right. Well, what that does when I create this interface that goes directly to our. Sorry, that. That’s not directly going to my database. It’s actually doing some logic in there that becomes a very, very powerful system because my, my alternate applications and My, the other applications in the system that need to interact with my process don’t need to have that internal knowledge of the application in order to interact with it.

Aaron Magid 44:52

Okay, so we’re back here and what I’m going to do. So if you notice here, my, my code has been updated, right? So I have this, this code over here that has my customer number, it has my, my JSON structure in it, right? So I’ve got business logic in here that is going to do what I need to map out this, this call. So give me a second here and we’re going to, we’re going to go get this up in, in Postman. Actually, I apologize. I confused myself for a second. Hold on. We’re going to just go here and we’re going to do a package dev. Okay, one second here,

Aaron Magid 45:50

one second. Okay, cool. And what we’re going to do is pull that guy up. Just give me a second here to compile it a little bit slowly.

Aaron Magid 46:04

Okay, cool. We’ll restart this guy and then we’ll get this guy over into our, into our Postman, modify that guy and we’re going to send this request again and get our output. Right. So now I’m calling that API Endpoint and I’ve got a, I’ve got a business oriented structure here. Now the important point here is that if you look at my API, there is no indication on this screen that I am talking directly to a database. There is no indication of what query I’m running. There’s no indication that I’m even talking to an ibmi. Right? And that’s a critical piece of this application because that’s what’s going to break that coupling between the applications. So now once I have this, I now have a structure where the. NET team doesn’t need to know anything about the ibmi. And because they don’t need to know anything, they don’t need to have any tight coupling or any dependencies on that knowledge and that will allow me to move forward with my application. Now there’s another piece here which is we need to make sure that we have good authentication in here. So because if you have an API that’s using poor authentication mechanisms, you haven’t really solved anything. Right? So we’re going to use JSON web token based authentication for this. JSON web tokens for anyone who’s not familiar are the backbone of OAuth. If you’ve worked with those technologies, you’ve seen these before. But just very quickly, I have a JSON web token in my call here. Basically what a JSON web token does is it basically gives you an access pass that has been granted by a, by a trusted authority, right? So the analogy that we like to use is like when you’re in school you get a bathroom pass or hall pass, right? What these are doing is they are a pass that is issued to you by a trusted authority, the teacher, to go do something very specific, right? That’s what a JSON web token does. We’re not giving you credentials to the system. We’re not giving you an all access pass to do whatever you want to do. We’re not just letting you roam, you know, roam the whole world freely. We’re saying you can go here and if you have a question about whether or not this is valid, you can go talk to the teacher who, who signed this one, right? So we have a trusted authority that is granting you access. And it is not an IBM I user profile. It is restricted only to the application. So looking at this, the way that, that this works, I actually have my token already. What I, what I do to get in here is I first talk to my authorization server, I send it my credentials and I get back a JSON web token which looks like this, this looks like a bunch of garbage. It’s actually not garbage though and I’ll show you what I mean by that.

Aaron Magid 48:55

This token, I just put this into a decoder so it shows exactly what this is. This token says in its payload. It actually says, ah, this token belongs to the user aaroni.com and it provides these authorities. So it is allowed to do these specific things. Right? It’s not a user profile on the IBM, it is an application credential set and we can validate this website can’t do it because it doesn’t have the key to validate this. But your actual server will validate that this token was signed and generated by, by a trusted authority. So when I take this key, if I go to my postman and actually what I’m going to do first is I’m going to take it out of this call because I already had it in here. If I take my token out of here and I send that call, it’s going to come back and, and it’s going to say nope, I don’t know who you are, right? You are not allowed to, you’re not allowed to talk to this API. Now when I put this token in that says I have the account balances read authority, it’s going to go in, it’s going to validate that token, it doesn’t just blindly take. It’s going to validate the token to make sure that it is actually signed by an appropriate authority and then it’s, if it is valid, it’s going to check the authorization, it’s going to check the, the scopes that I have in there and it’s going to decide whether or not I can call this API, just to give you an example, or just prove this. If I delete a character, let’s say I tamper with this JSON web token, I delete a character out of it and I send this call again, it’s going to say nope, because it’s going to say internally the signature validation failed. Meaning I don’t trust this token. It’s been tampered with. And I can tell that it’s been tampered with. So yeah, I’m not, I’m not taking this. Right. So this is going to keep again our system much more secure. Now when you go into this process, when you get into this kind of authentication, there’s another critical point here now that we’ve set that up in our application, which is we need to make sure that our app, that our, our authorization here with our JSON web tokens is fitting is secure in itself. Meaning we want it to be standard, we want to be using standard authorization providers and we need to make sure that if passwords are still being used, which if you notice in my Postman call I have a password in here, if I go over here, you can actually see I’ve got a set of credentials in here and an ultra secure password in this demo application, right? I’ve got a password in here. So we need to make sure they’re being stored and validated securely. And I’ve seen a lot of applications that make a mistake here where they’ve got, for example, a database table that is, that’s storing all the passwords in it or that’s encoding them base 64 or something like that, you know, which can be decoded trivially, right? We need to make sure that our passwords are, are protected if you are storing passwords in your own system, which is possible, but if you’re doing that in here, we want to make sure they’re being stored securely. So the recommendation I’m going to make here is that you store them using what’s called a one way hash. Within Aerodynamic Connect applications, we use an algorithm called bcrypt. And basically what that does is it basically show, it says the way we actually store that password. You know, my password, my Password is just password, but the way it’s actually stored in my system is like this. And this value, it is mathematically impossible to determine what the original password is from this. So somebody can steal my password database and they won’t have gotten anything because it is mathematically impossible to retrieve the original password from this hash value now. And it is possible, though, if someone has the right password to validate using this, that they have the correct password. So it’s got this great attribute in there where we can validate passwords, but they cannot be stolen. So this is how we want to make sure we’re doing this now. That’s, that’s that next step. So, going back to our diagram for a second, we now have an API layer. We don’t have direct connections. These guys are using JSON web tokens to access the system, right? To access our API, which is owned by the IBMI team, that’s then locking that down. And so now what we can do here is we can say, all right, we’ve pretty solidly covered this access. So now our web app team is going through the API. Our 5250 users have MFA. And what we’ve now done is this attacker. No matter where they’re coming in here, they’re going to have problems, right? They can’t just use the password because they’ve got the MFA call. And they can’t extract credentials from this web app because there are no credentials in there. And they can’t just go directly to the database because nobody is allowed direct database access. They can only go through the API. And even if they have access to the API, the API is going to restrict what they’re allowed to do and give us an extra layer of security. So this guy has effectively been neutralized from what we have seen in our application. So this is a pretty good state to be in if you can get those pieces in there. The mfa for the 5250 and the. And cutting out all the direct access and getting it through a standard layer that’s maintained by the IBMI team that’s going to dramatically improve your security. As a side note, it’s also going to improve your maintenance and your performance and a whole lot of other attributes of the application. But that’s for a different webinar. So I want to just, in our last minutes here, I want to take a view toward the future and what you can do here in your applications. As we mentioned at the beginning, we need to make sure that we are agile in our application development so that we can keep up with this security arms race. And we need to make sure that we’re using standard modern security systems so that we don’t get that uncomfortable criticism, but also so that we can actually maintain effective, effective authorizations on our system. Right. If I look back at that API for a second, this authorization is way simpler, which means we can actually manage it. This web app is not being granted access to specific objects object by object, as they’re working with it. The 5250 users aren’t getting that either. What they’re doing is they’re getting business function scopes, they’re getting a, a permission that says you are allowed to read account balances. And then on the IBM I side, we’re managing what that means. So that means we’re not doing individual accesses for individual users. It’s going through the API layer. So nobody actually has access to anything. They go to the API and they say, I want to do this business function. And we can then control it from there so we don’t ever have to grant someone a direct access to an individual object. So those are some of the key points. First thing to look at as you proceed on this journey is there’s usually a much wider organization outside of the ibmi, right? You got a bunch of other applications outside of here, right? You might have a whole bunch of other things in here. I don’t have to go through all of them. And they are probably all using a standardized authentication layer. That might be Okta, it might be Entra, it could be a whole bunch of other systems. They’re going to be using a standard system for this. So once you’ve got this flow in here with this API, this API is using these tokens. It’s a fairly straightforward thing. It’s pretty trivial thing with Erdani Connect especially. But regardless of what architecture you’re using, it’s a good thing to do for this API to use this system as well. Meaning instead of having password stored, instead of using any of that, we’re just going to the company’s standard system and using that. And that gives us centralized management. That makes it a lot more straightforward for the security team. And it also helps us avoid the potential of broken homegrown integrations. You know, that, you know, obviously we’re delegating the password management and all that authorization. If you’re using Entra, you’re delegating it to Microsoft, right? You’re delegating it to companies that can be focused on this going to Okta, you’re Delegating it to a security company rather than focusing on it with your team with your limited time. So it’s going to save you time and also make things more secure. Aaron, there is a.

Dan Magid 57:16

There is a question here. In the last minute. The question is. Well, you can, you can look, is it Eridani API kind of, or web services server? If so, is it running on the IBM I. Do I need to change my ODBC access?

Aaron Magid 57:30

Good question. So an AirDonty Connect server can run wherever you want. It can run on the IBM I directly or it can actually run on a separate server. So we can put this guy on here and say everybody has HTTP access over to here and that’s totally fine. Or it can run separately. The key point is that we want to make sure that it’s owned and maintained by the IBM I team. That’s what’s going to make the critical difference, regardless of where it’s running.

Dan Magid 57:58

It could even run in the cloud, right? It could run, right?

Aaron Magid 58:01

Yeah, it can be anywhere. Now I personally am not a huge fan of, of running the API directly up there just because. Meaning in a separate data center because you know, you got to make sure your network is set up properly. If you’ve got a network team, that’s great. The smaller shops, I usually don’t recommend it because you have to make sure the network security is right for that long distance call. But it. Yeah, but that is also totally valid.

Dan Magid 58:28

Great.

Aaron Magid 58:29

Any other questions or.

Dan Magid 58:31

No, I think we’re good.

Aaron Magid 58:32

Okay, cool. All right, well that’s about what I wanted to show, which is a one last quick comment here, which is on. On observability. As you’re securing this thing. When you get into those standard systems, you also often can use their standard observability systems. And I know we’ve done other webinars on observability and, and monitoring those kinds of things, but that’s also very important when you’re.

Dan Magid 58:51

I think we’re going to get into some more detail on that in a future session as well, but I’ll. I’ll leave that to Maya to close things up.

Aaron Magid 58:57

Yeah, exactly. All right, well, thank you all for listening to all that stuff and you know, going through all my demos and diagrams. I hope it was useful. And Maya, I’ll pass it back to you to close us up. Yeah.

Maia Samboy 59:08

We have two sessions left in this series. The next is going to be Secure by Design DevOps Security for IBM I. That’ll be on Tuesday, April 29th at 1pm CST as well and then the next one after that will be on monitoring and observability. It’ll be May 13th. I’ll send those details out to you all with the recording of this session as well as recording of our first session, just in case you missed it. So big thank you to everyone who came out today. Again, if you have any follow up questions, feel free to reach out to me over email. Can pass that along to Dan and Erin and we can take care of that for you. So we hope to see you all next time. Again, thanks so much for joining us. And look out for that email from me.

Dan Magid 59:47

Thanks everybody.

Aaron Magid 59:49

All right, thank you all.

Maia Samboy 59:50

Have a good one.

Aaron Magid 59:51

All right, bye.