Oktane18: Workday -- Integrating MuleSoft to Secure Endpoints and Build New Productivity Apps

Tom Smith: Thanks for coming everybody. Again, my name is Tom Smith. I am a partner solutions architect with Okta. Here today to talk about integrating Mulesoft to secure endpoints and build new productivity apps with some of my colleagues from Workday. The way this is going to work is I'm going to give a high level overview of API Access Management at Okta then I'll pretty brief. I'll go through things pretty quickly. Then I'll turn it over to the Workday team and the Workday team will talk about a specific implementation that they've done with Mulesoft and Okta. This is our standard disclaimer. You've probably already seen this a few times already today so I'm not going to spend too much more time on it.

Why did Okta build API Access Management? There's a problem and opportunity here. APIs and applications are proliferating. You're probably all seeing this in your own domains. This is a good problem to have because these new applications and APIs are building out great new user experiences. They're connecting applications and services that have never been connected before. So again, great problem to have. But, how do we manage all these APIs? How do we manage access to all of these APIs? We don't want to slow down the velocity of development and the creation of these applications and APIs but we do want to make sure that they are secure also. That's where Okta and Mulesoft come in. Basically making APIs easier to manage and more secure at the same time.

Why use Okta for API access management? Essentially it's because we know the most about the user context. We not only know if the user is authenticated but ... you all know this through applying Okta access policies ... that you can decide when a user is authenticated. So, depending on all of those granular context like IP address, user group, so you have very granular control over when a user can authenticate. You also know, of course, whether the user through Okta, whether the user is active, whether that user has been suspended, whether that user has been deprovisioned. Those are all things that Okta brings to bear in that user context. You can also apply adaptive MFA to that user authentication event. So again, going back to those policies, you can decide whether the user needs step up off and whether that user needs to enter a second factor to fully authenticate. Those are all things that can go into controlling that user access to an API endpoint. This slide kind of shows where we fit in the whole spectrum of API management. Okta, we're not an API management company. I know that's kind of a subtle verbal distinction there but we provide that access pillar. We are best in breed, we are an identity company, we provide those factors again that can control when a user can get access to the API. A solution like Mulesoft is going to provide all of those other pillars like the life cycle of the API, exposing it developers, but where Okta comes in is really in managing access to that API.

This is ... I'm not going to go into this in too much detail, but this shows the basic authorization flow for API access management. Our API access management solution is based on OAuth. I'll walk through what the end user experience looks like first. An end user authenticates or attempts to authenticate and then Okta, again applying all of those policies that you've set up in your tenant, decides whether that authentication event is valid. Is the user name, password okay? Does the user need another factor? Are they coming from a white listed IP address? If all of that checks out, then Okta's going to issue or mint an access token and in most cases an ID token as well. I just want to point out here that I'm not showing the ID token in this case but in most cases for authentication purposes, you would want to issue an ID token and validate that ID token to authenticate the user.

In terms of authorization, Okta is going to mint that access token and is going to include in that access token any scopes that have been requested by the application and are appropriate for that user depending on the policies that you've set up in Okta. Okta sends that access token down to the application. The application sends that access token to the API gateway, in this case Mulesoft. The API gateway checks to see if that token is valid and if the scopes that it includes are appropriate for the endpoint that's being requested. If so, then the API gateway sends the request on to the target API, gets the data payload, then sends that data payload back down to the application. Okay? So that's kind of a whirlwind tour of a basic authorization flow in OAuth.

And that's what it's like for an end user. The use case that the Workday team is going to be talking about is really more about client authentication which we support as well with API Access Management. That's kind of that lower level where the application has the client ID and client secret. Very similar to the end user flow that I just went through. Okta's going to issue that access token only with the scopes that that application should have access to but then the flow is the same. The application sends that token to the API gateway and the API gateway makes a decision about the access token and the access from there. Workday is using Mulesoft and Okta to build out APIs, microservices and applications. Again, it's the best in breed approach. With that, I'll introduce Jose from Workday who's going to introduce the Workday team.

Jose: Thanks Tom.

Tom Smith: Yep.

Jose: Here. All right. Hi folks. Thanks for attending the session today. Just going to give a quick overview about why we chose the Access Management in the first place at Workday. As Tom said, API gateway, we purchased it around late last year. We rolled out this microservices architecture here at Workday. We did a sit-down with all the internal business teams and as we got to the final team which was the Workday on Workday team, we ran a couple of API query's and we actually seen the concern was the scopes of the API, the payload. Basically the Workday team wanted the same access as the user has in the UI to be returned to mimic what's in the payload. When we rolled this architecture, we didn't really have a solution for this. We actually took a step back and reached out to Okta to see if they have any solutions and Access Management came into the picture.

The remainder of the presentation, Derek, which is our software developer will skip overview on their integration landscape of our whole Workday implementation. Praveen Awasthy will talk about the more granular implementation at Workday, how we succeeded with this, microservices architecture using Okta's management. And Tae, whose our primary Okta administrator will finalize the presentation with a short demo and will give you a little bit more detail on what we implemented here at Workday. Just wanted to set the stage here for the upcoming slides here, so with that said, I'm going to hand it over to Derek. He's going to give a little bit more background on the landscape here.

Derek: Great. Thanks Jose. I also want to thank the Okta team for giving us the opportunity here to share our story and the challenges that we faced with essentially securing our APIs, like Tom mentioned, and forming a firm work around authorization. So without further ado, let's go ahead to the next slide here. So we've actually had quite a bit of history with Okta. A strong partnership. Primarily in identity management, right? I think everybody here's familiar with their single sign on applications. But the story changes quite a bit. As we start to grow and you see some of the applications that are on the screen here, we separated them out to be into three separate functional areas. Enterprise applications, collaboration and identity management for user management. As the story changes a bit as we start to on board some of these applications because rather than just authenticating the user, which we're all familiar with, now we get into the business of authenticating applications to applications.

Let's take that one more step lower. The integrations that connect those applications, and the data that's flowing from endpoint to endpoint. These are not the same story. They're similar stories but they're three separate ways of authenticating. And so, really with Access Management, we've been able to come up with a really comprehensive way of dealing with both users, applications and integrations. What I mean by that is that, right in the middle of the screen there you see padlock with users and resources and apps. Actually Praveen is going to go ahead and talk about a little bit how we locked those things down. But really, that's the guts of what we're trying to secure. It's not simple picking a solution. There are a lot of different applications on the market today that we could have easily picked up and purchased just like Access Management but because we already had a back ground with Identity Management it became a no brainer for us because now we have this consolidated suite where people ... And a knowledge base with Okta getting management ... we're able to administer this without too much uptake. Not a big learning curve there. So really that was the impetus for building so many applications that you're seeing on the right side.

We chose a microservice oriented architecture to connect our endpoints so we see it as a vehicle that moves our data across our IT automation platform. These endpoints, I'm sure you're used to seeing some of these familiar names, but the secret here is that each one of these applications has their own way of authenticating. If you've ever had to build one of these processes out, you'll know that the definitions are completely different. Access Management provides us just a very streamlined standardized way to authenticate these applications. We're actually doing it through the RAML so if you're familiar with defining these APIs, within the ramal we have configuration where we can directly connect it to the configuration in Access Management. So, that really gives us some economies of scale. One thing to point out is that, this is just a best practice for Workday, our microservices are actually centralized so that our master data can propagate to multiple sources as you're seeing here. Now, these target applications, they serve as templates for us. So as we attach another application to this picture, we basically copy the template and then basically move ... well, we don't really have to redo the demo. We can copy the template and move the data in a similar manner. It really does have some economies at scale for us. Our business-

Derek: Have some economies to scale for us. Our business teams love it because now they have this contextual data that they can pass on to their own applications which they didn't have before. And so, really I think this IT automation platform in combination with access management has really given us kind of a step up to other IT shops. So you're taking a...basically a screenshot of what our IT automation platform looks like now. If we turn back the clock two or three years, we're actually on premise. Not to say that that's a bad thing, it's a very stable environment. But, there were some gaps that we had to address. Pretty much on the left side which is, we wanted to ensure that we had centralized data gateway. So as we're converging all the applications at the micro services that you saw in previous screen, we wanted to make sure that we had this ability over each thread as that data crosses through those resources, and persists to the source and target applications.

We wanted to make sure that we had simplified governance, again really just having that visibility so that if there was an error, we could go into the logs and essentially troubleshoot from there. I'll save the middle one for my last point. We have availability of AWUS so I think everybody's familiar with zero down time or close to that. The world pretty much collapses when they go down. So, we're just very thankful that we've been able to assemble this platform in combination with access management. The last point that I'm going to make about our platform is that with access management we've been given the ability to lockdown, again, our microservices and have that fine, fine level of authorization at the RAML level. The definition of the API. Really, it's just...prior this, we really didn't have a solution, I don't want to steal Praveen's thunder but, basically, we were doing basic Auth to get access for each of these applications and the layers that you're seeing on the screen.

So, we worked very closely with our security team. This is our internal security team to come up with some goals for what essentially this access management product was going to do and how it was going to work in our ecosystem. The first thing that we wanted to do was maintain the level of access throughout the gateway.

So I think kind of a testament to the cloud applications and all the SAS applications that we've worked with, they do a great job of securing the data when it's inside of their application right? I think where there's still a gap, and this is more from an industry perspective, is when that data goes outside of that application, right? So all those permissions, all those policies, all those personas, they get kind of washed. And now, you're stuck with this payload. And so, what access management allows us to do, is to continue that level of security, and that level of authentication throughout the process from source to target. And then what we can do is we can define at very fine levels, the resources and the operations that our users, and our applications have access to. So, that was very important to us. Secondly, we wanted to maintain the segregation of duties across the applications. Not everyone can be a superuser, right? We're probably all admins in this room but not everybody can be one. We have reporting users, right? And those users should have respective access. They should only have the get operation, right? They shouldn't be able to read and update or delete or even create records. So we needed to maintain that across the gateway. Thirdly, we needed to be task specific. We needed to make sure that if people had access to one resource in one part of the application, fast forward to when they're reaching out to another application, they have to have that same level of access that's task oriented.

And then finally, basically the thing that I've been talking about all this time is that we need granular resource management. Again, Praveen will show you guys how we implemented this from end to end. But, just wanted to stress the fact that without access management, basically we're using basic Auth for this. We've learned a lot of things along the way, and I think that access management, again, has created a comprehensive solution for us to move forward to the next level. So, with that, I'm going to introduce Praveen, who's going to show us how we implemented at Workday.

Praveen: Thanks Derek. Hello everyone I am Praveen and just before I get started, I just want to get the feel of the audience. How many of you have used Mulesoft as an API gateway tool? So you guys are familiar with the way in which we manage APIs there. Good.

So, having that said that, we have been developing these APIs on Mulesoft as Derek said, that there were a lot of requirements from security and they wanted us to maintain the kind of standard we are maintaining with all of the other products in Workday. So we are considering these APIs as well as one of the products, even though they are internal APIs, and these are being shared by internal folks within IT. So what you see here on the screen here. So, we were developing these APIs on API gateway and we are managing all these APIs, we are doing the throttling we are doing all the stuff. But, that was secured through a basic op. And, to get access these APIs was very simple. Just a two-step process; you request a client credential, you go to API gateway, request for an API, you get the client credentials, you use those credentials and you can get access to the full API.

So there is no granularity on the API level that, okay if you want access to only to a delete method, we don't need to get access to, we don't need to give access to delete to everybody else, but just to the admin folks or somebody who is just provisioning and de provisioning users. In those cases there is no way that we can control through these APIs. And that's what...we ran into issues and we worked with Mulesoft as well as Okta and I think we were the first ones to go live on this policy, they created a policy for us that okay...I'll just go over about how easy it is to set that up.

So this was the state before we moved on to Okta access management. And now what I want to go over is, what is the state of...sorry...yeah... So how does it look like now? That's what I'm going to cover, and how does it change the architecture or how the overall framework has been evolved by adding Okta API access management piece. So as you can see, this is the same architecture that, there's a client type, there's the API gateway, and the implementation layer. So as a client experience, nothing is going to change.

The client is going to request API access through API gateway. Same. But change comes at this point that instead of API gateway maintaining all the client credentials and all the scopes and everything related to security, identity management. What we have done is, what this Okta API access management has provided us. That requested goes out to Okta, and Okta is the place where all these client credentials, all the token management, API scopes, policy rules, everything related to identity has been managed. And that is the right thing to do because we have been using identity management solution for all the other things as directors develop for apps, and for a lot of user management stuff, so why not for the APIs. And once we got the solution we got really excited and though, "Okay, let's see if we can implement within Workday." And so once this request gets outed to Okta, Okta is the place which is then rating the client credentials, and Okta is the place where this OAuth token is getting rated.

An OAuth token is getting then rated with the proper scopes. So within an API, if somebody has only read-only scope, they will get access to an API but only to that scope and they can only invoke that particular method within an API. So it's very granular. And, again, so if the client is going to pass that token to API gateway, API gateway is not going to validate that token. Because they are not maintaining the identity, they will again that token validation to Okta, and Okta is going to validate the token, and if it is valid they will get access to the API. It looks very simple and I think Tom has also touched upon this flow. It looks simple to explain it here but we're implementing it, it took us some time to understand and to get it right. But once we got it right, what I want to just showcase in the coming slides, how easy it is to set that up.

So there are two pieces to it, we have to make configuration changes at the Mulesoft at the side as well as at the Okta side. At the Mulesoft side, this is one time setup that you have to do client management piece. They have a very beautiful UI you can just go there and tell all the Okta rated details. I have some screenshots I'll share that. And then within Mulesoft they use terminal logic called RAML. So all these APIs are defined using this RAML definitions. And, that is where you make sure that you are using the right security scheme. Are you using OAuth, basic Auth, everything is maintained there. So since we are going from basic Auth to OAuth, we are to make changes in that API definition. And then the policy which has been created by Okta and Mulesoft, and that's the policy that I talked to you about earlier that we configured the policy a long time back. And had some revisions coming from Mulesoft, we had some revisions from Okta side, and while they were both needed, we were able to get it going. And on the Okta side what are its setup steps I think Tay is the next one to go over it. But before I give it over to Tay, he's our admin...sorry...sorry about that. Okay. Okay.

So from the Mulesoft side this the client management screenshot I was talking about that they have a UI where can enter all the Okta related details. You can have a registration URL, you can have introspection client, so this is one time setup and if you set with the Okta admin you can do that within an hour. And then this is the definitions of API which you have to update because you're going to move from basic Auth to OAuth. This is again, one time setup for an API because since we have started using OAuth and we are able to get control on all these resources. You see for this demo API we have get, post, put, and delete. All these APIs in all these resources or all these methods within this API are now granularly controlled. If somebody needs access to only get...

Praveen: Add now granularly control. If somebody needs access to only get we can do that. Previously if someone gets access to this API they'll get access to all these methods. And last but not the least this is the policy. This is the out-of-the-box policy provided by MuleSoft and which is, again, one-time configuration for an API. You have to do this for each and every API. But if you click on these view details you can see forget method what other scopes you need. So as a client when you go and look in this API you can definitely see, okay, I need access to get method and they know they need access to the scope. So when they're requesting for a client credentials they can just mention the scope, they can get the token, and then they can move forward to get the access to the API. And now I think I can pass it over to Tay. Thanks guys.

Derek: So what Praveen showed you was on the MuleSoft side, how that configuration is done. So back into Okta side. So what we need is we need to create the scopes that we want to be using for our API. So in this case it's going to be read user, delete user, and write user.

And the next piece is writing the policy within the Okta site where in this case we're actually just creating a policy for our client. In this case I created three policies. One for the client that can read from the user, one that can write to the user, and one that can delete the user. And on the right side you see that within that policy we create the rule saying that, oh, for this client, for this policy this client will only get the read user scope. And then so for the other two clients they get the additional read user, or write user, and delete user scopes as well. So the idea is basically when you do a get post or put the ideas, you know, one client they can do the get. But because their token may not have the ability for the scope for writing or deleting, you know, you get the forbidden access here. So, you know, and this is just a quick example of if we wanted to show, you know, the actions regarding, you know, what your token has the ability to do, whether it's get post or put.

So I just wanted to show you quickly. I've got a quick little demo set up just to show you that, an actual working API. And so what I have here is I've already set up my read client, my write client, and my delete client environments. So for this read I'm going to go ahead and go and request a new token. So I'm going to grab this token here and apply it to this get request. So I already did this earlier so you can see. So what I'm doing right now is I am calling, you know, to get the user's information based off of a user ID 4001. So when I click send it should give me back the results. In this case I got back Praveen who is a Principal Engineer at Workday.

And so if I attempted to do the same thing to, let's say I wanted to update Praveen's record and make him an IT director I can go ahead. And if I attempt to do that using that same token that I got for that client it will give me that I have an invalid scope. So the required scope for this API, or this method, is I need a write user scope. So I'm going to go ahead and change over to the client that has the correct scopes and I'm going to go ahead and request to get a token for that client. And so as you can see here, if I scroll down, there's a read and write user scope that this token actually gets. So I'm going to go ahead and copy this token. And just to show you that I can still do a get request I'll go and get the same user again using this new token.

So he's a Principal Engineer. But this time I'm going to use the same token, and I'd better update the right user so I'm going to change this to 4001. So I'm going to send that, put the request which should basically change his title to IT Director. So I got a message saying success and so I'm going to go back to the get user and do a send again. So I see here now that, you know, I was able to write to this user account, and Praveen has been promoted to an IT Director now.

And last, but not least, you know, this client has the ability to delete records. So I'm just going to go ahead and get the token for this one, and as you can see, this has all three scopes. Read user, write user, and delete user. So I'm going to go ahead and grab this token here and just to show you that it works when you do a get. So this time I'm going to go ahead and get a different record. In this case this is Jose, our IT Manager. And so what I'm going to do now is show you the delete method. And if I try to send this, oh, I need the token here, I should be able to delete his record as well. So if I now go ahead and try to get Jose's record again, you know, I come up with nothing. So apparently he left Workday, he didn't like our teams, so he decided to move on. But, you know, to bigger and better things.But that's the end of the demo and I'll turn it over back to Tom.

Tom Smith: Thank you. So I think we have time for questions. Anybody have questions either for me or the Workday team? Yes.

Speaker 1: Yeah. So one question I have is if you're forcing access to the API through MuleSoft, through Gateway, correct? What did you have to do with the API to ensure direct access was being protected as well? So, if you bypass the Gateway and go directly to your API. Does that make sense?

Praveen: Yeah, it does. Yeah, it does actually. So that's the beauty of API Gateway. Like you don't have to make any changes to the implementation layer. So the complete access has been controlled at the Gateway layer so you are not making changes to the vein which API was implemented.

Speaker 1: And of course all access through the Gateway then?

Praveen: Yeah. All access to an API-

Speaker 1: Even if you have the record?

Praveen: No, you cannot. You can just block that access.

Speaker 1: Okay.

Praveen: Yeah. So that's how-

Speaker 2: For each request that's coming on HTTP request are you going to Okta to do the JWT validation?

Praveen: Each request? Yes, we are.

Speaker 2: Yeah. So how do you plan that for a scale? We have applications that do 35 requests per second in terms of running through Gateway. For each request if you go to Okta you're going to choke that bottle.

Praveen: I mean that's something that we have-

Tom Smith: Yeah. So you can validate the token locally if you want to. So you can download the JSON web key set.

Speaker 2: Right.

Tom Smith: From the public endpoint and you can validate that token locally.

Speaker 2: But that means that you need to understand the entire scope of APIs and which client have access to which scopes if you have to do it locally. Otherwise you don't, JWT validation and, you know, you can just down ... you can, it does validate. You can just, you know, decrypt the token and it's valid. But how do you know that this client, this client ID from this application has only read access. For that you need the whole profile.

Tom Smith: Yeah. So yeah. So let me back up. So you can, in general, do validate access tokens either locally or through the introspect endpoint at Okta. The way that the MuleSoft has done it is that they actually set up, and I don't know if this is the way you guys implemented it, but the way that MuleSoft does it by default is that when they see an access token that they haven't seen before they reach out to Okta, to the introspect endpoint, validate the access token, and part of that validation is comparing it. Like is the request that's coming in for this endpoint, does the access token include that scope. Okay?

So if it does then it's going to basically create a local session for that access token based on the lifetime of the access token that it's gotten from the introspect endpoints. So that will mean it doesn't have to go up to the introspect endpoint when it sees that access token again coming in.

Praveen: Yeah. That is very proven. Yeah.

Tom Smith: Okay. Cool.

Other questions?

Speaker 3: So is that part of like, you know, the fake access token or is it a JWT?

Tom Smith: It is a JWT. Yup.

Other questions? All right. Great. Thanks again for coming everybody.

Praveen: Thank you.

Tom Smith: Really appreciate it.