Lifecycle Management: There’s an API for That

Speaker 1:  I will introduce Joel Fran- ... Thank you. Franusic. I was so good at it before this session. Joel is the Senior Technical Marketing Manager at Okta. He's a hacker and Senior Technical Marketing Manager, obviously. He likes to keep the simple things simple and make the complex things possible. Prior to Okta, Joel was a Developer Evangelist with Microsoft and Twilio and in his spare time is an avid reader and loves a computer history.

With that, let me introduce Joel to the stage.

Joel Franusic:  Thanks. Hello everybody. Today we're going to be talking about lifecycle management and APIs. Before we get started though, we have to have a slide here to keep all of our lawyers happy, if I make any forward-looking statements, to take those as plans, I guess.

Anyway, a little bit more about me. I've been programming for about 20 years using a bunch of different types of programming languages. Earlier in my career, I also spent about seven years as a sys admin, operations type person. The reason why I'm talking about that is that, or the reason why I mentioned that is that, this talk is really kind of at the intersection of those two disciplines. Right? As the admin, I'd be having to deal with users and the lifecycle that they'd go through; and then, as a programmer, I was always looking for ways to automate things and remove as much human input or intervention as possible.

Here's what we're going to talk about today. We're going to talk about what is lifecycle management, cover that basically at a high level; I'm going to also be talking about the Okta user model, so how Okta models, the user lifecycle; talk a little bit about how you can programmatically manage that user lifecycle sort of at a very high level; and then I'm going to give some concrete examples for that. I'm going to have some interaction from the audience, so if you have laptops or phones you'll be using them and in that part of the session.

Let's get started here. What is lifecycle management? How many people here know what lifecycle management is or think you know what it is? Raise your hand. Okay, so it's about half the room. For those of you who maybe aren't as familiar or aren't sure really what my definition of it would be, the very base, it's talking about how you get users connected to their devices or resources.

What do I mean by users? I mean everything from employees, to contractors, partners, customers. Then, in terms of resources, things like applications, or physical or virtual resources or devices. Then in the middle, here are all the different inputs that you would use to figure out who gets access to what and when and how. This is at a high level what usual lifecycle management, what we define it as.

Then, in terms of what that actually looks like for an individual organization, some organizations have very complex user lifecycles, with a lot of approval steps in different states that the users can be in. Others have a very simple lifecycle.

But what we found across all of our different customers is that, for the most part we have these four basic user lifecycles where you have a provision state. You can think of this as something where you've just added a user into your database, maybe it's an employee that you've just hired but they haven't started on their first day yet, maybe it's some contractors that you just got loaded in but they haven't started on their project yet.

Then, from the provision state, you'll typically transition to an active state, so this is when the person's actually doing their work when they need to have access to all the various resources that they need to have access to. You'll see there's that like review loop and that's really just talking about that's assumed to be an ongoing type of process where you're constantly making sure that people have appropriate access to the resources that they need access to.

Then, this suspend state is really meant to be something for, what that's modeling is you'll have users that maybe a seasonal employee that will only be working for the holiday season or maybe during the summer and so it's only appropriate for them to have access to your various systems while they're actually working, but they're going to be coming back here after year, so it you don't want to fully remove them from your system. Or it might also be that you have an employee who's taken an extended leave or going on a long vacation and you just want to make sure that they're fully engaged in their leave and not trying to sneak a peek at email.

Then, finally, you have the off boarding state, which is when you're fully separating from a user when they're fully leaving and you want to make sure you go through these final processes like getting back inventory of the devices or that you're cutting the last paycheck, stuff like that.

In terms of how Okta manages that user lifecycle, what we have internally is what you'll see here, the big state machine in terms of how you transition from one state to the other. It's a lot more complicated than those four basic states. So what I really want to do is, instead of focusing on or talking about all the different pieces of how we model it, I just want to focus on the four basic things that I was talking about, so the provision state, the active state, the deprovision state.

If you're curious about seeing this, it's all on our website so you don't need to take furious notes. Just know that you can go on developerokta.com and get that whole state diagram.

In terms of what we're going to be talking about today, I'm just going to simplify it down to these four states: the provision, active, suspended, and deactivated or deprovision state. 

Now, in terms of managing the user lifecycle, how do you move your users between all those different lifecycle states? We have a whole bunch of different ways of doing that. We have a full suite of API endpoints that you can use to manage all kinds of things in Okta from the applications to the groups, to the users, to policies, to network zones, all those different things. But with Okta, it's going to be focusing on the user groups.

We also have a whole bunch of different ways of connecting various systems together. You might have an on-premise database that you want to keep synchronized into your Okta or you might have some legacy hardware, some mainframes that you want to be a part of that lifecycle. There is a bunch of different options for handling that, but today I'm going to be focusing on one of them as a service or a protocol and standard called "SCIM."

Then, finally, if you were in our keynote the other day, you saw a little demo of our self-service registration feature, which allows people to register themselves into your Okta tenant. I'm going to be doing a more in-depth kind of demo of that feature.

What you see up here on the screen is, here on your right, is a screenshot of our developer.okta.com site. For any questions that you might have, I'm going to be covering this at a very high level, but if you have specific questions about how it works, what types of things you can do and can't do, this is all available on developer.okta.com and it's super detailed. You can see exactly the kinds of requests that you'll need to make, what you'll need to be sending into the API, and then what kind of responses you can expect to get back.

The other thing I may be demoing a little bit of is SCIM. I'm just curious, how many people here have heard of SCIM before? Oh, man, it's changed a whole lot in the past couple of years. A very basic overview of SCIM. Okay. Kind of a classic example that I like to use is we have a partner called "Envoy." Envoy gives companies those little iPads that you'll see when you go into the front desk and you're there to see someone at that company. You'll typically type in your name and take a picture and sign a NDA. But it's really important for them to have up-to-the-minute information about those users. Let's say you just started on your job and one of your friends wants to come by and say hi. It would be a bad experience if you weren't in that system and they'll be wondering, "Do they really start?" or, "Are they really here?".

What skim helps to do is it helps keep those systems synchronized. If you look here on your left, in that kind of a passport-looking thing, if you think about that as Okta's universal directory, that's the kind of core user's store where everything is. Then, here on your right, if you're looking that kind of shield thing, you can think of that as Envoy system that really wants to have up-to-date user information.

What will happen with SCIM is when a user gets added into the universal directory, if the universal directory determines that based on group or app assignments that that user is being assigned to an application that needs that up-to-date information, then Okta will then send that user information across. So that user information might be, "Hey, you have a new user," or, "Hey, this user has an update to their name or department." Then, at that point, it's then up to that service like Envoy to then record that change, that user information change, and then, at that point, you now have these two systems in sync. I'll be doing a little bit of a demo of that. You'll be seeing I'll have this live updating screen, and all that's going to be powered by SCIM.

Then, lastly, I'll be doing a demo of the self-service registration. This is a new feature that Okta has and this is a way of adding users into your Okta tenant. We have a lot of automated ways of doing this from connecting into HR management systems. We have those pushed over, but oftentimes there's a certain classes of users that's not appropriate to put them into your HR system or maybe they're an external partner or an external customer and you like them to just register for themselves. So that's what I'll be talking about as part of this demo as well.

Let's talk about some of the examples that I'll be giving. You can get really detailed here, all kinds of really interesting and complicated workflows that you can do, but I'm just going to cover at a very high level the basics of what you can do. I'm going to be talking about a couple of different ways of adding in users, talk about how you can run a very basic application audit and then suspending and deactivating those users.

Let's go here and do a quick demo of the various different ways that you can add users into your Okta tenant and then I'll show what it looks like to have a basic script for adding users en masse, give a little demo of SCIM and how that user information gets propagated over, and then, finally, we'll do a demo of self-service registration.

What I'm going to do here is go into this tool called "Postman." Postman, it is a nice and graphical interface that you can use to try out the different parts of the Okta API. Even if you're not a developer, it's a really easy way to explore all the different capabilities and maybe start learning how to do a little bit of basic scripting or programming. But this is something that I use all the time just to try out basic stuff.

What I'm going to do a demo of here is to show you how you can add in a user. What I'm going to do over here is I'm going to close this out and open it up again. What you'll see here over here on your left is all the different API endpoints that I have loaded into Postman. We're going to be talking about users today and so what I'm going to do here is go in and create user. Let's create a user with a password and then what I'll do here is I'll edit this example body and we'll just add in everyone's favorite example user, John Doe, and add in the email, and their login information, and then I'll go over here and hit Send.

What you'll see here is I got an error. The error here is telling me, "Oh, you did not send in the correct type of password." The password requirements in Okta tenant are a lot more complicated than what you sent in. So what I'm going to do here is send a longer password with a number in it. Now, when I hit Send, we're going to get back at the thing saying, "Hey, you added in this test user." So just to verify that, we can go over here into my Okta tenant and go in and take a look at the people that I have in this Okta tenant. You'll see I just added in a John Doe.

That's pretty cool. I can do that by hand, but as you can imagine that get very tedious if you had a long list of users. The next thing to take a look at here is what it would look like to add in a bunch of users en masse. I'm doing this in Python, which is a pretty simple programming language. I picked it because, even if you're not a developer, it's actually pretty easy to understand what's going on.

I'm going to just briefly walk through what this does. Up here at the top, this is just Python including in extra functionality that's not part of the standard programming environment for Python. Here, I'm setting up a user's client, which is, this is part of the Okta SDK. I'm giving it the URL to my org as well as the API token. I'm doing the same for groups client. Then I'm going to skip over this section because this is about how I'm adding in groups. But I'm going to go into you here and just walk through the basics here.

I'm saying with the file called "Example Users," I want to read through it line by line; and for each line, I want to create a candidate, which is the person that is on that line, in that CSV file. I'm going to create a blank user. Then, I'm going to go and try and see if we have an existing user with that email address, just to check and see if they're there yet or not. If there's no one there, if the number of people that came back is zero, then I'm going to go ahead and say that the login for that candidate is the same as their email. Then, I'm going to go ahead and create a user. Then, print out, say that this user has been created.

Then, I will also add the user to a group. I'll run this function that will add them into a group. If the group's not there, it'll be created. Then, I have a little thing here that says, if they're in a group that doesn't start with "co," and you'll see what that means later, I'm going to add them into the paywall group.

Let's take a look here at what this looks like. I'm going to run this. I'm adding in maybe perhaps some familiar names that you've seen there before. While that's happening, I'll be showing you that, as these users are added in, they are going to be assigned to groups which are now assigned to this SCIM application. So as people are being added in by this application, then you'll start seeing them showing up here in the SCIM app.

This is just a demo of, you know, it can be pretty simple to add in users from a CSV. Of course, we can do a CSV import. You don't have to do that yourself, but you can imagine you have these existing systems or some database or some other service where it's not easy to export to CSV. Or maybe you just want it to be an automated process, this is a way that you could build out something like that.

Now that I've shown that, I want to demo some new functionality. I'm going to go over into my applications. I've got an application called "ATCO." This is the same demo that we did up on the stage during the keynote. I'm going to go in a little bit more in-depth and take a look at this.

What we have here is a new registration tab on the applications. This is allowing users to register in for use on this application. What I'm saying here is that this is enabled, so by default it's disabled. That I'm saying when the user registers in, assign them to the self-service registration group so that you can keep track of who came from where.

The other thing that this does is it also applies the password policy of that group. If we want to have a more relaxed password policy or a more advanced password policy, we can change that in that group and then that's used to validate all of the users who are being added in here. Then, by default, we prompt for first, last name, email, and password. But you can add in a whole bunch of more fields here.

Then, finally, there's this section here that's saying, for onboarding, we're saying you can either require that the user validates their email by having an email sent out by Okta and then there'll be a link in there that users will be required to then click on before the user goes active. But for the purposes of today's demo, I'm just going to make it so that people will get immediate access.

With that, what I want to do is give you all the chance to try it out for yourself. If you go to this URL that you see here on the screen, you pull out your laptop or your phone, you can go to Oktane17.j10.com and then add in user information. It doesn't necessarily have to be you. It's also going up here on the screen so you can put in an email address. That's just an example, if you don't want it up on the big screen. But just go ahead and open up again this URL here. You'll see a login page and then you're going to want to scroll to the bottom of that login page and click on, I think it's a sign up, but I'm going to follow along here so that I can try it for everybody here too.

It looks like we have a person who just signed in. Actually, no. That was an existing user. So, yeah, it's going to load up a little screen and then at the very bottom, it will say, "Don't have an account? Sign up." So there we go. We've got Jim Bob and other folks coming in. So that's the very basics of what this looks like. I'll give you a little bit more of a chance to try it out. Then you'll notice that once you've gone in and answered you, I think it's a basic security question, and picked an image for yourself, you'll get sent into a demo application that hasn't been mobile enabled yet so you have to turn your phone sideways to see what that looks like.

But, there you go. You have a live demo here of what it looks like to sign into the application. It's that easy to start getting users into your Okta tenant. Now that we've done that, let's go back to our demo. Feel free to follow along as I'm talking about some of the other things. It's going to be active for the rest of this talk.

Now I want to talk about doing a demo of a rogue accounts report. This is also a new feature that we have in Okta. This is a report that you can do against various applications in Okta. What you want to know is, are the lists of users in Okta that are assigned to this application the same as the users that are actually in that application? So there's certain apps like Salesforce where if someone has admin privileges they can sign in directly to Salesforce, add somebody in, kind of going around existing policy that you might have. So you want to make sure that those users are really kept in sync.

To do a basic demo of what that looks like, maybe you want to have something going on an ongoing basis, you want to have those users checked and compared to an ongoing basis, what I've done here is written a very basic user comparison script.

Let's take a quick look at this. This is doing raw request against the Okta API. A lot of this will look very similar, but basically what I'm doing here is I'm saying: get me everyone who's in this payroll group and for every user in that payroll group, add them to a list of Okta user, so this would be the list of people who are in Okta; and then go out and connect directly to that application, to that SCIM application; and from there, get the list of users; and then for each user in the response from there, if that user is not active, skip over them, so I only want the list of active users; and for each one that you have in there that is active, add them to the list of SCIM users.

Then, here at the bottom, one of the cool things about Python is that it has built-in functionality for a thing for sets, very much like the mathematical set. I can say compare this set of SCIM users against the set of Okta users, subtract the Okta users from the SCIM users, and show me who's left. So let's run that.

So we have a whole bunch of users. Everybody here that registered in weren't part of that paywall group, like this email here, I'm not sure if it's pretty cool. But you'll also see that we have a suspicious person here, Milton Waddams, who, if you've seen "Office Space," you'll know that he has a reputation for getting access to systems or staying on the paywall when he shouldn't be. What we're going to do now is, we've noticed, Oh, hey, Milton is not supposed to be in paywall." So what we're going to do now is go ahead and suspend him.

Let's go back into Postman. What I'm going to do here is do a search for everyone named Milton. I'm going to say "find user." I'm going to change user to Milton. It'll go ahead and do a search. I'll see here that we have this Milton user. I'm going to copy his user ID and now what I want to do is suspend him. I'm going to look in the lifecycle operations. There will be one here that will show me how to suspend users. I'll just replace the user ID with Milton's user ID. Actually, let me do that again because I made a little mistake there. Paste that in. Hit Send.

I've gone and suspended them. Over here, I see the 200 okay. If I go in and check in my Okta tenant and I look for Milton, I should see that he is suspended. Let's look for Milton. So there's Milton, Milton is suspended pending further investigation. We'll be able to then figure out what's going on, why they were in one system but not in another.

Then, finally, let's go ahead and talk about how to suspend users. I now also have another little script that you can use to go ahead and take everybody out of Okta tenant. To do that, I'm going to run my clean script. Again, this is a pretty similar to what you've seen before. This is a very raw Python script I'm calling directly against our API's. But again, it's very similar. I'm saying for each user that's found in all of the users in the Okta tenant, skip over my current user, so this is the user that issued the API token. I don't want to delete myself. But for everybody else, go through and deactivate them. Once you deactivate them, then you can also delete those users.

This is a fairly recent addition into Okta. You have the ability to completely wipe users out of your Okta tenant. I recommend against that unless you're really sure that's what you want to do because of kind of audit and compliance reasons it makes a lot of sense to have users around in your system in a deactivated state. But if you really want to clean everyone out, you can go through and delete them.

Then, similarly, I'm going through and saying for each group in Okta, in my Okta tenant, skip over ones that aren't Okta-issued or Okta-mastered; and then for everyone that is Okta-mastered, go through and delete them unless it's this demo group. I set up some demo groups for this demo that I don't want to take out. What I'm going to do now is run that. Part of what's going to be going on here is going through and deleting them. So I wanted to thank you for participating. While you've been a great audience, I'm not sure I really trust you, so I'm also making sure that all these user accounts are getting cleaned out. As this goes through, we'll start seeing these user accounts getting taken out of the Okta tenant.

Let's see here, make sure that it's running. Oh, I need to actually run it and not just ...I'm going to run the same command again.

Now it's running through. You can see it started going through and deleting users. We can see them all starting to get pulled out. That's all happening because of SCIM. SCIM is telling this service, "Hey, this user is deleted. This user is deleted." It's going through and wiping them all out.

So that's a very high-level overview of how to do lifecycle management in Okta. Of course, there's a bunch of more complicated things you can do from creating users and stating them and setting passwords and all kinds of different things, but I just wanted to kind of go over what we talked about at a high level, talk about these four basic states that pretty much every company or organization will have: the provision, active, suspended, and off-boardered or deactivated states.

You can see here a bunch of the different types of things that you can do in those various states and systems that you can influence. We covered some basic overviews around how to add users; how to run reports, and audit the various applications, then how to suspend and deactivate those users.

Then, everything that I demoed here is available online. All of the code that I was showing off, you can write yourself. I'm also going to be putting it up just in my GitHub page. Everything that you saw here is available online. So, Postman, we have a great getting started a guide for how to use that on developer.okta.com. We also have a basic Python SDK. This is going to be updated soon, but you can use it now to start exploring around.

Then, for the self-service registration, that feature is still in beta but once it is generally available or it goes into early access, that page, that URL used to sign up was this application that's open ID connect application. That's what I used to demo here and that's the same app that was used on stage during our keynote.

Then, finally, if you're interested in learning more about SCIM, we have a full sample SCIM app. That's what I was using up there. It's really easy to get that going.

So that's the basics. If you want to learn more about lifecycle management, or what our plans are, and how to dive deeper into user lifecycle and how to manage all that, maybe not programmatically but hear more about these various features that we have, these are some of the sessions that you should look into.

With that, we're going to open for questions. If you have a question, you can raise your hand and we've got people that will give a mic to you. We have it so that it's on the recording and so I can also hear it. With that, any questions?

Audience:  Is there a WSDL site that I can connect to, like .NET or PowerShell or something like that?

Joel Franusic:  No. Our APIs are REST-based so we we don't use that kind of SOAP type of ... For people who aren't familiar with the various APIs, there's different ways of connecting to remote services, one of them is called "SOAP." In SOAP, you have a thing called a "WSDL," which is the full description of all the different endpoints that you have and the different properties that they have in them. We're using a different methodology that's called "REST." REST is sort of built on top of the mechanics of HTTP and so everything in REST is typically modeled as a resource, just like a web page is a resource. You can have a user resource or a group resource and then you can do the four basic CRUD operations on them.

The short answer is, no, we don't have WSDL. We are in the process of publishing Swagger, which is kind of similar to that, and there are API clients that can ingest Swagger and then build out a basic client for you.

Any other questions? All right. Well, if there's no more questions, I'll be hanging out here, feel free to come up to me and talk to me in person. I want to thank you very much and hope you have a great rest of your day.