Identity Lifecycle Management: OneLogin Mini Demo

Identity lifecycle management allows you to take advantage of automated user provisioning and deprovisioning into downstream applications that support it. Now, we operate off the SCIM protocol here. So if your application supports SCIM, you're probably in pretty good hands. What we're able to do here is mess with the different attributes that we're going to push down into those applications. So maybe we're able to take a standard attribute like first name and push it into the application as first name. Or maybe with something like username, we need to do a little bit of a transform. So username equals firstname.lastname. However, we're still able to take those components and attributes inside of one login and push them into the downstream applications. On top of just attribute assignment. We are also able to do things like entitlements based on what the application supports. So when we look at user provisioning for onboarding, deprovisioning for offboarding, or maybe just an update around someone who has a change of name or change of title, all of these different scenarios, we can work with those applications. When looking at those different types of tasks, we can either allow them to be performed automatically, or check one of these boxes to put an admin approval in front of that option. We can also set default behavior. So if a user is deleted in one login, what do we want to automatically do in that app? And same thing if the user is suspended. All of these different actions allow us to not only make onboarding more efficient, but it helps improve security and costs around offboarding. That way, we're not leaving orphaned accounts out there that can be accessed, and we can recoup licenses for an application where a user is no longer accessing it. When it comes to the provisioning component, we can keep things vague or we can get specific with our rules. So maybe I want everyone to be assigned the same type of license inside of this downstream application. Or maybe in the example of this rule I have, I want to give someone a different license based on their privilege. So I'm looking at my user's title. And if it equals manager, I'm going to give them a different license than maybe I would give to my typical end user. You can add multiple rules here and have different conditions and outputs. What it looks like in action is here I am creating a new user, and I'm going to give them a certain department which will assign them applications like Office 365 that are configured for provisioning. So as soon as I create this user, I can go over to their application page and see that Office 365 is ready to provision. Now I have an admin approval in front of this task, so I'll open it up and go ahead and approve it. Now that the user has been successfully provisioned, they could access that application and already have a license in front of it. Now, just as easily from the offboarding perspective, if I were to suspend or delete this user, we can see that I'll now have a provisioning task to delete this user. I'll go ahead and approve that and recoup my licenses that could have been floating out there and making sure that I don't have an Office 365 account that is just floating without being used.