Okta + Identity Governance: Who Has Access to What?

Sandeep Kumbhat:  Hey guys, welcome to this session. It's Okta and Identity Governance together. So for the next 40 minutes or so we're going to take you through what Okta has been doing with Identity Governance and administration, also how do we partner with best of breed IGA vendors in the industry. My name is Sandeep Kumbhat and I'm a principal solution architect with Okta, I do act as a liaison between the product management as well as the enterprise architecture team. With me I have Vikas Tyagi.

Vikas Tyagi:  Hey guys, Vikas here, I work for Cyber Inc solutions, primarily working on the Identity Governance side. I've been working in this space for more than 15 years now and I'm happy to be here and share what we have done working with Sandeep. 

Sandeep Kumbhat:  From a background perspective we both have about 15 to 20 years of experience in Identity Governance, our roots are from Sun Identity Stack as well as Oracle Identity Stack. We're going to take you through little bit of you know our journey towards Identity Governance, if you are onboarding Okta how can you also certify your access within your IGA systems. Quick agenda over here, what is Identity Governance? Just a quick show of hands who has taken care of SOX compliance within their organisation. Who all have SailPoint? Show of hands. OIM? Okay, that's good to know, the rest I'm assuming you are on the journey of producing compliance reports and certification reports? Okay. 

So what role does Okta play? I'm going to talk about the current status and what we are release and early access for some of the compliance reporting requirements. Then we're going to switch it over to a live demonstration of a new functionality, which we release as part of our partner engagement with Cyber Inc, it's called IGA bridge, which bridges Okta and a lot of IGA vendors together to produce compliance certification processes. Which is combined with both Okta and the IGA vendors applications. So we're going to talk about that and then we're going to summarise with the strategy going forward for the IGA. 

What is Identity Governance? From a tone perspective it's a Gartner coined term, it's called Identity Governance and Administration. There are five key steps associated with IGA process all together. It starts with access discovery, access discovery is all about how best your user accounts and permissions from your target sources, also reconciling user identity and account, and target information from various other target resources, which you don't have control of. So we can import it using MANA processes. Once you get it within Okta, or any of your provisional systems out there, you do want to produce a business catalogue out of it so that your certifies can easily read that information and certify the access information within your systems. 

So that's called Access Discovery, or Access Harvesting process, that's usually the first process for an IGA process. When it comes down to when you do have those identities and so they are true defined, you do want to manage those life cycles of users as well. This process is typically called Identity Administration, or User Provisioning and De-provisioning. In Okta's term it's called Okta's Life Cycle Management, where you do manage your accounts, your groups, your relationship with those accounts and groups, as well as entitlements and attributes for various different applications. Those entitlements could be permission sets, lets say if it's SalesForce it could be attributes, which could be profile attributes in those cases. 

When you do have those rules based provisioning processes going on you do come across scenarios where you do want to request ad hoc access for an account, for an application, for an entitlement, or for a group. You do want to have a request approval process, and whereby you can go into a request approval tracking system and request that access. It goes through an approval process and whereby you can track who approved when, if there are multiple stages of approvals you'll go through that approval cycle, and then you get that access downstream from an end user perspective. 

So once you have your rules based provisioning and your access request based provisioning being taken care of, you have two options to produce compliance reports out of it. Number one is access certification, this is a process, which SOX bound organisations or SOX derived process actually take. We do produce access certification campaigns, and those campaigns could be run on a periodic basis, it could be quarterly reports or quarterly processes, annually, semi annually. Those certifications are usually focused on something very specific, there's a financially significant application in my organisation, I do want to produce a report, which showcases who has access to what and who has those significant entitlements being ... They have been accessing those significant entitlements within the application. 

The certification process is going to take you through a process for a time, for a kind of a time snapshot of the access at a particular time when you run the campaign. It records who approved that certification process as well. So once you run through the certification process you do need to hand over reports to your internal and external auditors, that's where the reporting process comes into the picture. You can produce reports based on user access and application access, events like password change events, who changed what, and who changed when. When was an anomaly in the system actually discovered, all of those reports can be produced and those reports could also include some compliance focus reports, which could be your segregation of duty reports. Like toxic combinations of policies, for example a single person cannot have an access request or let's say accounts payables and accounts receivables, both kind of accesses. Those are SOD policies. 

When you do discover that within the access reporting phase it's the detective phase, if you do take care of it in the administration phase, it's the preventative phase for your access reporting and segregation of duty conflict resolution. So let's say you've onboarded on application and you went through the entire process of certification, once you finish a certification campaign it starts again. You rediscover what changed within the application within the next certification campaign, and then you reconcile those changed accounts and permissions back into the system. 

So this is your typical identity governance process, what role does Okta play over here? All the blue bubbles, which you see over here, that's where Okta is playing currently. So starting from access discovery to identity administration, to access request and approvals, the boxes in gray, which you see where we partner with service now for access requests and comprehensive entitlement requests approval process. Access certification is one area where we're going to talk about where we partner with Sale Point and Saviynt and of course Oracle Identity Manager. So we're going to talk about that, and access reporting of course Okta participates in those reporting processes as well. 

So lets dig a little bit deeper into what Okta provides from a life cycle management perspective. So at the end of the day everything in the organisation is a life cycle, humans have lifecycles, your resources have life cycle, your apps have a life cycle. When it comes down to Okta, Okta manages those identities who needs access to resources. Resources could be your applications, your directories, your API's and so on and so forth. So it begins with an identity lifecycle, you bring in an identity, and you assign accesses to those identities. So you establish that identity, assign resources and policies. You manage changes to those accounts and identities and you end the relationship with an identity. So that's your life cycle management process, and that's what Okta does out of the box for various different applications. There are about 100 out of the box life cycle management and provision connectors, which Okta provides within the Okta Integration Network, and there are more coming up. We are doubling down on the life cycle management so we're going to produce more and more connectors for provisioning and de-provisioning. 

From a process perspective you must be familiar with this slide where Okta of course can take various different sources of information, starting from your HR systems to your multiple directories out there. Provision to various different target sources including Cloud applications, as well as on premise applications as well. So if you do want to provision to legacy applications out there, be it SMP or Oracle or be it whatever your on premise application is, we do have an on premise provisioning agent through which you can extend the reach of Okta's life cycle management to beyond Cloud applications as well. There are other avenues how you can extend those integrations to on premise and other hosted applications where we do not have provisioning to. There's a skim template through which you can extend your integrations, and there is also integrations through various different API gateways. If you would want to extend it through Mulesoft or other API gateways, which do have connectors to a lot of those on prem maps, we can even extend integration to your on premise applications. 

So that will take care of your life cycle management process from an Okta standpoint. Customer examples you see here, Post, Vivint Solar and Pivotal, they have been using Okta to produce those security and compliance reports right out of Okta's lifecycle management processes. Introducing a few of the new features, which we rolled out early last year, actually this year. Access request workflow, has anybody been using the Beta or the early access for access requests? If not till now I would really encourage you to test it out. So we did release a life beta access request workflow within Okta, through which you can define a process as if you want to request an application to Box and you do want to have an approval request process going on with that. You can have a group approval process or an individual account administrator approval process defined within Okta. The administrator can also have their task inbox through which they can receive all those requests from end users, review it, approve it and also record that approval within Okta's CIS log. So all of that could be done within Okta natively. 

Where do we do partner with service now is where we do need to extend the access request flows to entitlement based requests. Where you do want to go fine grain and you want to request particular entitlement within SNP, within offer 65. I want to have a new permission set with the SalesForce, so that you can define that permission set within Service Now. How Service Now would call Okta is essentially by publishing all of the API's, which it's going to call from an Okta perspective onto the Service Now catalogue. That catalogue is going to be available for everyone who's using Service Now, as you see on the screen right now, you can request access to Box and entitlement within Box. When you do that the user is going to submit their justification within Service Now and Box admin approval is going to get the notification, they can approve it and that orchestration work flow within Service Now is going to call Okta's API's to fulfill that entitlement request within Okta. Then Okta thereby provisions back into the Box application. So you can literally take care of the entire access request workflow with Okta and Service Now combination together. 

From a reporting standpoint, again coming back to what Okta provides out of the box, we did release certain access audit reports this year, early this year, and those are ranging from account assignment reports to account un-assignment reports. So if you look at the report over here on the left, and there's a configuration box on the top, you can define that hey I want to run a report for Salesforce, who got Salesforce within my organisation and within that time period. I can include attributes from Salesforce directly and specify in my report, which all attributes I want to see. I can download those reports, I can check out anomalies as what changed within those accesses from the last time I actually had provisioned over there. Those are going to be all over there in your report, which you generate out there. So there could be an assignment report and un-assignment report, which you can generate. 

There's a third kind of report, which we have released just early this month, which is a rogue account report. It's available in early access, what that does is essentially if you have an automated provisioning connector with Okta you could reconcile the rogue account, the orphan accounts, which have probably been starting from your target application directly. Push that into Okta again, and check for anomalies over there. If there are anomalies you can remedy it, if there is a life cycle management connector out there from an Okta perspective, or you could also produce reports in terms of these are the remediation actions, which you need to take out. 

If there is no lifecycle management connector you can also import an application audit report, or a CSV file from the target, if it's a disconnected resource, push it into Okta and then you can again start comparing what changed when and, which of the orphan accounts are there in my application. So this is available today from an early access perspective, you can enable that in your sandbox environments, it can start running security event reports. 

There are situation where you do have your identity governance process in place and you do want to comply with all of these certifications and kind of processes from a SOX perspective. Thereby comes the best of breed coexistence with a lot of the IGA vendors out there in this space. Okta has several customers who have both Okta and Saviynt, Okta and Identity Governance as well as Okta and SailPoint Identity IQ. There are several customers, which I couldn't list out over here from a reference standpoint, but there are customers who are using both of these solutions together, their IG and Okta. With a loose coupling or a tight coupling architecture. So I'm going to go through a few of the reference architectures from some of the customer examples, and we'll look into a few examples. 

Saviynt is a Cloud access governance solutions, so Saviynt already has a bridge established with Okta. So if you do want to run your identity governance and administration process completely in the Cloud, same as Okta, Saviynt has that Cloud access governance solution for you. What Saviynt does is essentially it can pull information directly from our user groups and apps API's and publish that within Saviynt's access governance console. You can then certify those accesses within Saviynt and it will push all the remediation actions back into Okta. So this is out of the box. 

When it comes down to Oracle Identity Manager, the example I'm showing over here is from a large national insurance banking and finance organisation. They hold Oracle Identity Manager and Okta together, what they have done over here is they essentially didn't want to integrate Okta and OIM together. They did not want to invest in an OIM connector, so they did deploy a mechanism where it was a loose coupling between Okta and OIM. Where the provision from OIM to acted directory all the entitlements and attributes, which they wanted to push into Okta. Okta thereby pulled using Okta's active directory agent it pulled that information within Okta. So both the systems were kept in sync, anything changed within active directory or OIM, Okta could pick it up and synchronise both the systems out there. So this is a light production environment for one of the customers I'm talking about. So this is kind of a loose coupling, OIM and Okta are not talking together directly. 

There are scenarios where you do want to connect both of these systems a little bit more tightly. That's where you can deploy connectors from your IGA vendors, in this case OIM has a rest connector. That rest connector can call out of the box Okta's crud API's, which are rest enabled. So you can deploy that connector and you can push information starting from Oracle identity manager to Okta. Now what's the use for this kind of an integration? The immediate use is you remove the loose coupling, you take out the active directory from the picture all together and you provision everything from OIM to Okta directly. OIM can track those user accounts, which are getting provision from OIM to Okta. So that's the reference architecture we hear. 

Talk about the pro's and con's of this architecture a little shortly as I introduce the bridge. OIM's architecture, Sale Point we have a similar architecture. Sale Point does not have a rest connector so you can deploy a skim connector. Skim connector would call skim façade, which is on top of Okta's rest API's and you can take the same kind of a route to provision accounts and entitlements from Sale Point to Okta. So this is again a tight coupling, flowing from Sale Point to Okta. 

Now there's a need where you don't want to use SailPoint and OIM for application onboarding, because you want to leverage Okta for Cloud application onboarding on the applications, which are very easily, which you can onboard very easily within Okta. So let's say there are about 100 to 200 applications on Cloud, which you want to onboard. If you want to onboard within an IGA system it's going to take you a while. If you want to onboard within Okta probably it could be a few weeks to onboard 100 to 200 Cloud applications for provisioning. That's what the purpose of this bridge is, you've got about 100 to 200 Cloud apps, or more than those applications, I'm just taking an example. Now you want to start reconciling that information from Okta and create all those assets within OIM or Sale Point, so just to begin with OIM and Sale Point and we can extend it to other IGA systems as well. 

So introducing a new bridge, which we have worked together with Cyber Inc and this bridge does certain things, which I'm going to go through. One of the first things is user from Okta to OIM and SaillPoint. So when you create a new user, lets say there is a contractor user or additional user population, which are all there in Okta. You could reconcile those users from Okta to your IGA systems as well. Secondly when you onboard an application, and picking up an example of SalesForce, let's say you onboard a SalesForce within Okta and you want to replicate all of the application artifacts in your IGA system, you would be able to do that with this bridge. There are several processes associated with created this bridge, creating these application artifacts in the IGA systems. This bridge handles everything out of the box, so you don't need to worry about any of those artifacts being created manually. User accounts from Okta to OIM Sale Point as well, so you succeeded, lets say with one of these sample accounts within SalesForce and that account should now get associated with the application you onboarded within the IGA system. So all those accounts will also get synchronised and get attached to your IGA system. 

Then you can take certification actions within your IGA system and it's going to closely remediate all the actions within Okta as well. So this is what the purpose of the bridge is, to keep both the systems in sync and give you at the end of the day one single business dashboard for certification. So if you're using Oracle Identity Manager or SailPoint, you can use those dashboards for access certifications even for Cloud applications, which are onboarded within Okta. 

A few of the obvious benefits are is it's extremely fast, when you run the bridge you almost can reconcile any artifact from Okta to your IGA system. So application and account onboarding is the quickest, probably about 100th of the time, and I'm not exaggerating. If you compare it with an IGA system onboarding the same application. Audit and compliance attestation with close loop remediation. Till now, you had to do everything manually within your IGA system to test a Cloud application, which is onboard in Okta. You can run through that process and it'll have a closed loop remediation with Okta as well. Reduced total cost of ownership of course, because you're eliminating a lot of OIM and Sale Point jobs in terms of creation of those tasks and processes. Reducing risk as well, you're not dependent on your OIM developer or Sale Point developers to generate those artifacts. Scalable, it's a modular function so you can run for one application or multiple applications at times. So these are the artifacts and some benefits of the bridge. 

From a functionality perspective there are two bridges right now for OIM and Sale Point separately. As this diagram talks about you have your Cloud applications and other apps where Okta has life cycle management connectors for being managed within Okta, you want to synchronise those within your IGA systems. These bridge ... Both the bridges OIM and Sale Point bridges are going to synchronise that information. The artifacts, which you see on those arrows are all going to be created with the bridge. So in the background the bridge calls OIM and Sale Points API's to create those artifacts within those systems. 

On the other side when the certification process gets completed within the IGA system it sends all the information back within Okta, so that Okta can remediate those actions within the Cloud applications as well. There are a few things, which we are doing in addition to building this bridge, which we have done right now for accounts provisioning and de-provisioning from Okta to the IGA vendors. We are going to do a role and group synchronisation as well, so that's something, which we don't do today because there are some role and group scheme IPA's which are not available within Okta. We're going to do that in addition to what we are doing today when the API gets released, we have an announcement request raised for that. We are also going to reconcile entitlements from Okta and connected applications within the IGA systems so that you can even request for entitlements. You can certify entitlements as well for the target applications. 

Access request fulfilment from your IGA systems to Okta, so if your IGA system be it SailPoint or OIM happens to be your dashboard for access request, you would be able to raise requests to Cloud applications as well. Or even any application connected to Okta, and you would be able to get the fulfilment done within the cloud application out of the box using the bridge. The other aspects, which we are going to take care of is accounts synchronisation from OIM SailPoint to Okta. So let's say you have connected few of the apps within OIM or SailPoint and you do want to synchronise those accounts as well. Because all Okta is doing is creating single sign on and multi factor experience for your end users, then you would be able to synchronise those users as well so that they can take care of the federation assignments and the single sided assignments. 

Last but not the least if there are other IGA systems, which you are using, on a need basis we're going to extend this bridge to other IGA vendors and providers as well. Be it Elixir, be it other IGA vendors. So from a strategy perspective it's a pretty you know kind of two faceted strategy. On the right you'll see the security focus strategy, which talks about if you want to do all the report generation from an events' perspective within Okta. Okta can generate those compliance specific reports, which are basically securing focus. What changed within that application? Was there an anomaly? Was there a rogue account? Was there an orphaned account? Who has access to what application from my, let's say Cloud applications perspective? You can generate all those reports within Okta, and that's going to be categorised into a security focused report generation. Then you do have the access certification requirements from a campaign management perspective.

Then it goes to the left side, which is the compliance focused area, and that's where you will leverage this bridge or even Cloud access governance solutions like Saviynt, which has out of the box integration with Okta to carry out the same processes. Any questions, which you might have? Sure. 

Audience 1:  Is there any way for Okta to take over some of this IGA functionality? Especially molds, so certifying all access to Okta, things like roles? 

Sandeep Kumbhat:  That's correct, very good question. The question was, is there any plan from an Okta standpoint to generally release this access certification functionality, and also have roles and groups to be reconciled within Okta. Was that your question? 

Audience 1:  Correct. 

Sandeep Kumbhat:  So yeah there's a difference in methodology, which Okta schema has today from a groups and roles perspective, we do take care of groups in a flat hierarchy or kind of flat structure. So for roles and nested roles we do need to incorporate that hierarchical nature for schema, and that's something, which we're thinking of. So that's on the radar, there are no concrete plans yet but we are thinking about it. The access certification side, we want to take a little bit different approach towards access certification. I'm not sure if, I've spent about 10 years with Oracle and of course have dealt with Sale Point as well. Not a lot of people are super satisfied with the IGA process altogether, so when Okta takes care of access certification, lets say whenever in the future, we do want to take care of it in a little bit of different way. We want to generate exception based reports rather than creating kind of a rubber stamp kind of an effort for your line managers, or your application stake holders. 

So we might want to tackle it a little bit differently from an approach standpoint. So right now the strategy is going to be security versus compliance focused, if you do have IGA processes, which you need to take care of today I think I would recommend to have partnership between Okta and an IGA vendor. 

Speaker 1:  Thank you, thank you very much I think we'll about wrap it up and you'll be on to your next sessions. Thank you. 

Sandeep Kumbhat:  Thank you guys.