Oktane19: The Expert Guide to Building the Custom Okta Integrations You Need
Sonalia Vaidya: My name is Sonalia Vaidya. I'm part of Okta's sales engineering team. Been here more than five years now. I'm based in New York City so I work with Okta's east coast customers. So, our session today is around all the different integration possibilities with Okta. I'm also going to be joined by three of our esteemed customers, Alegan, Wiley and Alliance data. And so after I finish my session, I will formally introduce Sandy, Saravan and Darren to come up and talk about their own stories and challenges they solved with Okta.
Sonalia Vaidya: So getting right into it. Just to set the stage for this discussion right, we all know that enterprise IT and on-prem IT infrastructure is extremely complex, it is expensive. Many companies have grown from acquisition. So you know, it's very common for us to have customers who have multiple different user stores. Often, they're not consolidated because AD consolidation is again, time consuming and expensive. So we find that you know, there's sort of entrusted domains, users are being managed separately on different active directory stores. And then of course, you know every business is now trying to be a digital business, right? I promised myself after all the negative press, that I will not use the word digital transformation. So I'll stay away from that.
Sonalia Vaidya: But you know, every business is trying to be digital, so you now have not only employees, but you have customer identities, you have partners to manage and often those are in different user stores, again, right? So there's islands of identity all over the place. And then a lot of the traditional systems for CRM or ERP, retail, supply chain, a lot of these are still on brand systems. So although most of your companies are in some shape or form in that journey to move on-prem services to cloud, the reality is that there is a lot of on-prem infrastructure to manage, right?
Sonalia Vaidya: If there is one thing I want you to take away from today's session, it is the fact that we at Okta are tirelessly working towards our mission to enable you to connect any type of user with any type of device to any type of technology and doing so in a secure manner. That's really at the end of the day, that is our mission. But if we want to become the identity standard, right? Okta talks about this vision of being the industry identity standard, the reality is we have to integrate with what you have today. Sure we are great, you know when it comes to cloud services and we do that seamlessly. But we really do have to solve your problems today, which is integrating with a lot of custom developed applications or services that are still maybe on-prem or maybe they're hosted in the cloud, but they're still custom services.
Sonalia Vaidya: So with that, I mean what are we talking about? We're talking about a team different integration patterns that are supported today with your Okta service. And I'll let you digest that for a minute. Also, those are eighteen different ways that Okta can potentially connect to a custom service or application. Now, you'll notice obviously across all of these, many will solve authentication use cases. Some will solve authentication as well as authorization, MFA included. And some will solve more complex provisioning, de provisioning, automating the lifecycle management of a user to downstream systems. So there's all kinds of use cases. I've picked a few to talk about today to go into a little bit of detail and then we'll here more detail from our customers as well.
Sonalia Vaidya: So the first one that I'll talk about is Radius. Now Radius is essentially an older networking protocol that was developed back in the nineties. Still being used for a lot of services. So the most common ones we see are VPM services, Cisco ESA and checkpoint. Many other VPM's use Radius. River proxy type solutions like Net scaler uses is capable of Radius authentication. So, if you have any of these services currently, Okta can support your flows for authentication very well using a very lightweight design, right? In this flow, we have a Radius agent. So, that's Okta's Radius agent, which install on-prem, so the communication between the agent and your Radius client is basically internal to your network.
Sonalia Vaidya: Okta is obviously on the public internet, the only communication needed from Okta's radius agent is outbound for four three. So, that's the only port you need to open on your firewall. Why would you use Okta for this, right? Because a lot of times you're already doing eighty authentication for some of these use cases. The beauty of this design is one, it's the security is managed in Okta, the authentication is managed. You're already using Okta. The beauty is you can layer on multi factor authentication. So, in that request, which you send from your Radius client, let's say it's a CISCO client or whatever the user is trying to log into, in that single request you can send credentials plus an OTP or a push.
Sonalia Vaidya: And that comes to the agent. The agent communicates to Okta, Okta invokes, does the primary authentication and then invokes the MFA and then returns a success or failure based on both. So the nice thing about this is you can layer in multi factor into some of the older services of flows that you wouldn't be able to easily do. We can also pass group membership back when that request comes to Okta, we can actually pass back information about the user to handle even authorization, right? So that's additional.
Sonalia Vaidya: The next one is the adapt cloud interface. This is something that is just there, right? So if you have applications that are using adapt authentication, then you can basically point those simply to Okta. Today, this service is capable of adapt search and bind so you can handle the authentication use case. And similar to Radius, you can also send the OTP or push in that initial request. Okta can process both primary and secondary authentication. This one is simple, there's no other component, right? The Okta services basically just provides you with an adapt S interface where it can process authentication requests.
Sonalia Vaidya: So the next one is O Auth. Now O Auth is a much more modern standard, right? O Auth is basically an open standard for token based authentication and authorization. There is an identity layer that is based on the O Auth two dot oh protocol, called open ID connect. That is the part that handles the authentication part. Now, Okta as a service, your Okta service has O Auth compliant authorization server which enables you to do fine grained authorization. It is also an open ID connect certified provider. So, you can handle both use cases for authentication from OIDC clients as well as fine grained authorization.
Sonalia Vaidya: Now in this flow, we have the user accessing some type of service on mobile. There is a headless app in the back end. Now a headless app is basically an application that does not have a graphical user interface. It's basically doing some back end processing to the three API's you see. That app essentially can delegate all of it's authentication and authorization to Okta. And Okta returns the required JSONtokens, whether it's the ID token for the users information and authentication, success whether it's OR tokens for further authorization. You can also, basically you're protecting those API's within Okta.
Sonalia Vaidya: You can also define scopes. So scopes are like permissions, what the user can do or is not allowed to do within those different API services. You can define all of those within Okta's authorization server. So this is obviously for much more modern app development. But most often, I mean I would say most of our customers are in the journey to provide mobile apps for their own customers or vendors or partners and this is useful because now if you're using Okta, you can build your authentication layer in your mobile apps or web apps, directly into Okta. And a lot of that information is on our developer.okta.com. So anything you wish to learn about OR open identity connect, please take a look at our developer.okta.com.
Sonalia Vaidya: The next one is a pretty common, I would say deployment model. So in this model you have on-prem web applications. You have a rivers proxy solution that basically protects the web application. And when the user tries to access that web application, the initial authentication and verification is handled by the rivers proxy. And once the user is validated, it then logs the user in or starts a session based on different mechanisms. But more often it's should be headers.
Sonalia Vaidya: Although there are other mechanisms like certificates or there are other flows. But most commonly I would say we see the header based flow is extremely common in this type of scenario. Now, Okta can augment this so if you are already doing this, Okta can augment this flow by taking the load off all of those authentication flows, security policies, password policies, MFA policies, which you're already going to define in Okta. And your reverse proxy essentially delegates back to Okta. So users accessing the application, the reverse proxy delegates back to Okta. The integration between Okta and the reverse proxy is based on SAML open ID connect. And Okta can validate the user, do the MFA plus pass any of the header information that the reverse proxy needs to pass into the specific application.
Sonalia Vaidya: So you can definitely protect your existing on-prem web applications in this manner. And we're going to hear more on this from one of our customers. So the next one is a company that we acquired about more than a year back I think called Scale FT. And Scale FT essentially does privileged access management for server access. So think about your use cases for SSH or RDP type login to physical windows or Linux servers. And Scale FT secures that flow. It also manages the local server accounts. It does some auditing on that process as well.
Sonalia Vaidya: Now this product is now fully integrated in Okta. It's called advanced server access. And all of the policy framework is going to be available within Okta. So, when you let's say you're assigning a developer access to some servers or a system admin access to certain servers, you can do that through the same mechanism. You can do that through group management or you know however you do your assignment policies in Okta.
Sonalia Vaidya: There are two components here. So there is a client component that is installed on the users device. There is also a server component and that's installed on the physical server. And these two pieces will work with Okta's policy framework to grant the user one time admiral certificates when the user is about to login. So the flow is that the user tries to sign in let's say to a server through RDP or SSH. The first validation is the Okta validation. So first of all, we need a primary authentication so user can be validated by Okta. That may be just their AD credentials or just their Okta credential.
Sonalia Vaidya: If you want to do MFA in this flow, you can. So same Okta flow. And then of course there's the authorization within Okta. So if that user is authorized to that server, then it will grant the user a one time certificate, which is used for access. So there are no temporary credentials in this flow, everything is handled using these lightweight one time certificates. If the user gets disabled, it's a pretty quick reaction for the user to get cut off from all the other access. So they will not be able to sign into another server if the user gets disabled. And I think maybe this was in one of our demos. I don't know if you guys caught that.
Sonalia Vaidya: And the last one, probably the one that handles the more complex use cases for provisioning, de-provisioning, basically managing user accounts in downstream applications. This flow, it handled essentially by the scum framework in Okta. So, think of- think of the example of a data base maybe that you have on-prem. You want to now automate the provisioning de-provisioning or you have a custom application that has some API's that will allow you to create and update the user. You can now have Okta scum agent which again goes on-prem. It's lightweight, talks to Okta on outbound 443. That scum agent in tandem with a custom module, that custom module will essentially do the sequel commands into your database or that custom module will do the API commands to create the user in some custom service or application.
Sonalia Vaidya: In this way, you can centralize all of your user management in Okta, right? So now what you do is you manage that end point like another application in Okta. You see the same type of panel, you can say I want to create update de-provision and you can manage all of those flows. They all go through that scum agent and handle the downstream provisioning and de-provisioning. And we'll hear a lot more detail on this from two of our customers. So with that, we are ready for customer stories. And I'm very excited to introduce Sandy Dalal from Allergan. He is director of IM services and Allergan is probably Okta's, one of Okta's oldest customers. So thank you for joining us.
Sandy Dalal: Good afternoon. My name is Sandy Dalal and I'm responsible for identity and access management services at Allergan. Allergan a pharmaceutical company and we sell branded drugs. Our most well known brand is Botox. We do research and development in a number of pharmaceutical areas, most notably medical aesthetics. In terms of our company, we have twenty three thousand people in our work force across a hundred and ten companies worldwide.
Sandy Dalal: Allergan was Okta customer number seven. So, we've had Okta in place since 2010. And so we definitely appreciate the journey we've taken with Okta and the partnership. So the high level view into our identity and access management ecosystem. As you can see, we have work day as a master. So all of our employees and contingents are sourced out of work day. We have active directory, so that's our corporate authentication store. And all users in groups in active directory are mastered by Okta.
Sandy Dalal: Okta's at the center of our ecosystem here. It provides a bunch of services that you are probably all familiar with. Single sign-on, multi-factor authentication, API, lifecycle management; we use everything. And we use Aquera for automated provisioning. So, Aquera is really, when you look at this ecosystem, really the glue that ties a lot of these systems together. Okay, so the challenge that we had at Allergan is that we have an extensive sales force. But our sales people weren't getting the access that they needed to applications in a timely manner.
Sandy Dalal: And so the way we provision accounts at Allergan, it's maybe not much different than some of your companies. We have a request process, an IT team gets a task and they manually provision the account. In some cases with some of our cloud vendors, we provide lists, like through an eligibility or roster file, so they get a list of names and then they just provision those accounts in the cloud. What ended up happening was for our sales people, it was taking up to twenty eight days for their IT onboarding to complete. And so there's a million business things that a sales person needs to do in the first few weeks like selling, learning, just a lot of things.
Sandy Dalal: So any problems with onboarding could completely derail them, it could push them back or set them back months. And in some cases, it could even discourage them to leave the company. Another challenge we had was we lacked visibility across systems. We didn't always know who had access to what and that became a problem when people left the company and we had to turn off access to applications.
Sandy Dalal: So needless to say there was a lot of business frustration across the company as you can imagine. So the approach that we took to address the issue is that we decided to automate provisioning for the applications that were being used by our sales people. And so, we started to work with a company called Aquera and Aquera's focus is really around building provisioning connectors and also these last mile integrations.
Sandy Dalal: And the reason why Aquera appealed to Allergan, is that Allergan is cloud first when we evaluate vendors. We want to see that they're in the cloud and Aquera was SAS manage service. With scum, with Sonalia, she showed us the slide on scum. The other good thing about Aquera is that there was really no custom coding. So at Allergan, we're not trying to build an internal dev ops. So working with partners that we could rely on to do custom coding was important to us. Another important advantage is that there was no infrastructure. If you've done anything with scum, like you know there's web servers and things of that nature, there was really no infrastructure that we needed it all with Aquera.
Sandy Dalal: The only thing we had to use was an agent that we installed on-prem. If you've used the on-prem provisioning agent with Okta or if you've used the active directory agent, it's very much the same thing. It just allows Aquera service to talk to any applications that sit inside your firewall. One other thing is that I'm sure you've all added applications from the Okta application that works. Some of those applications have provisioning capabilities. In Allergan case, we tried some of those apps and in some cases they just didn't meet our requirements. So we could not use them.
Sandy Dalal: The real nice thing about Aquera, it's just plug and play. So, if you want a provision to an application... if you want to provision to an application, all you do is you add an application from their catalog and then there's an Aquera application in the Okta application at work. You add that application and it's just configuration at that point. So there's usually a scum end point you need to configure. You can get that from Aquera and just pace that into the configuration.
Sandy Dalal: And you map any attributes that are needed by the connector and that's pretty much it. I mean, I know scim's pretty complicated but I think Aquera did a really good job of really removing that complexity for us. So, I mean in some ways I thin Okta had a gap that Aquera really helped us fill. Okay so, this is how we use Aquera's technology. So I mentioned the example of sales on boarding and some of the challenges we had. We knew from our HR system who our sales people were, but we didn't really know from the HR record what access or what application access they needed. We couldn't determine that. So we did have an internal database called ORG man, which acted as the source of truth for sales people.
Sandy Dalal: So what we ended up doing was, we used Aquera to connect ORG man to Okta. And once we had a connection, we were able to import specific attributes from ORG man into the Okta profile. Those attributes were mastered by ORG man. From there, what we did was we created group rules within Okta and with those group rules, we were able to assign users to the applications that sales people needed to do their jobs. So, once they get assigned to the application, we had the connector that we built Aquera, it would automatically provision the account. Similarly, when someone left the organization, in our case we had worked as a master. So, they get terminated in HR and that would trigger IT off boarding. So what would happen immediately is that their Okta account would get turned off, which would stop single sign on to any applications they had access to. And in addition, because we had the Aquera connectors, it would also de-provision those accounts.
Sandy Dalal: So this really helped meet our compliance needs. We also use a tool, RSA and with RSA it's really for identity governance. So, we're an audited organization and so we have to do security access reviews and re certifications and things of that nature. And so, RSA had a scum interface and a lot of what you need in RSA is data driven. So we were able to leverage some of the connectors that we built with Aquera to pull in information from some of the apps we connected to including Okta into RSA without any additional effort. Once we had that data, our Allergan people were able to do security access reviews with real time enriched data to make better decisions on access. The other additional benefit that we had is that we had a view across applications at Allergan. So this is a common scenario, but when someone leaves the company, they generally get terminated in the HR system. We could quickly find out if they had active accounts in other applications. And if they did, we can detect them and remediate them.
Sandy Dalal: So, you know the integration helped and RSA really became a detective control for us in turning off access when people left the company. So with this platform, we have work day as a source of truth for employees and contingents and we had ORG man as a source of true force or Allergan sales people. Both of these systems were hooked into Okta. And with Okta, when Okta was coupled with Aquera, it provided the automated provisioning services. We had RSA which is doing the identity governance, also hooked in with Okta to complete the picture here. Today at Allergan, we have about four hundred apps that we've integrated with Okta. And I'd say primarily most of those are single sign on enabled. In the last year, 2018, we added about a hundred and twenty apps, or integrated about a hundred and twenty apps alone.
Sandy Dalal: And I would say about 15% of our total are apps that have some kind of automated provision capability. And now that we've unlocked this capability with Aquera, we're ready to ramp up. So I think the key takeaway on this picture is you have a single line from your source of truth into IT. So if we have a new sales person who joins the company, they get added to work day and they get added to ORG man and all IT actions downstream are automated. There's no manual intervention required. So automated provisioning drove a lot of value for Allergan. We can now onboard hundreds of people at a time and the faster we can provision their accounts, the faster their productive for Allergan. And Aquera really drove a lot of value for Allergan as well in that they were able to eliminate the cycles it took to provision accounts and that resulted in generating top line dollars for the organization.
Sandy Dalal: So in the end, Allergan IT was viewed as a hero. We had implemented a solution with Aquera to automate, or automate the provisioning of accounts for our sales people. And our IT onboarding process improved tremendously as you can see from some of the metrics here. And Aquera really helped. They empowered our users, they made our Allergan sales organization really happy and they really helped our bottom line. I hope you enjoyed that. I'll be around for any questions after the session. Thank you.
Sonalia Vaidya: Thank you so much Sandy. So, in the interest of time, I'm going to call our next speaker, Saravanan Thiyagarajan from John Wiley and he is director at IM services for John Wiley. So, welcome and thank you. Here's the clicker. Yeah.
Saravanan: Good afternoon everyone. I'm Saravanan Thiyagarajan who is an identity and access management for Wiley. So, just a quick background, who is Wiley? What do we do? Wiley is been two hundred years old, heritage of publishing. What do we do? We divide up digital learning products and solutions. We support researchers to communicate their discoveries that brings a value at or in some cases that makes a difference. Then we also provide online content in journals, books and other digital content. So just wanted to set the stage, what are the business challenge that what we are trying to solve today?
Saravanan: The first one is more or less, everyone would be facing a high volume of password resets. And are prone, during the onboarding process or lack of visibility into user access and obligations or permissions. The most important one is loss of productivity and the high operational cost. If you look at it, all these are interlinked one way or the other. When the new joiners start and if he or she doesn't have access to the applications, obviously there will be a lot of frustrations that turns into a lot of productivity loss. In turn, they will be generating a lot of tickets and that ended up in high operational cost. So, I'm going to spend good time in this light, which resolved most of the problem statements. As we can see, in my center, in my use case, access factor is the HR system and HR system is access factor that gets integrated into Okta through our custom built scum platform.
Saravanan: Now why do we need to go with custom build? Because we started this journey two and a half years ago or three years ago. At that time, the connectors were evolving over a period of time. In our scenario, due to the time constraints and everything, and due to Wiley specific requirements, we ended up doing custom scum platform. We started building the scum platform. So how did we start building the scum platform? As mentioned by Sandy and others, scum platform, I mean you have to have on-prem agent, that's all you need to have on your on-prem agent and you are going to build a platform. The technology behind the scum platform is all purely microservice. We used spring boat, spring cloud and we also need to use Okta's DK and Okta on-prem agent.
Saravanan: So as I mentioned earlier, the reason for the scum connector, custom scum connector is due to our requirements, some of the ridebacks and other things weren't available at that time. I'm sure now it is available, we can make use of those connectors. Now the other use case that I wanted to mention, primarily or mostly people will use scum for provisioning applications that are on-prem. In my scenario, on-prem agents, on-prem applications, I do have multiple on-prem applications. I'm going to just select clarity as one of my on-prem applications. So, we started building the first scum for the success factor. We call it as an upstream. The reason because we are pulling the data from success factor and we are sending it into Okta. In the second use case, from Okta and a new user is provisioned, okay? I want to provision the user in my clarity system, which is on-prem, which exposes web service. So we used the same scum connector or the gateway to provision to the downstream applications. The third use is a little bit interesting, I'm not sure how many of you are planning or using bots for provisioning or de-provisioning.
Saravanan: Even today morning, one of the key note speaker mentioned they're heavily investing in blog chain and robotic process automation. So, in the scenario, in the third scenario which is A is four hundred system, A is four hundred system if you go and ask can you expose your web service API? There's no API. So, then how do we de-provision? It's just a normal problem. So in that case, we were debating whether we can do scripting or what are the other technologies we can use? Scripting do help, but it doesn't solve a lot of problem. One of the challenges, when one user has multiple accounts, I think in the AS400 they call it as profiles. If you have multiple profiles, it's tricky to correlate this one person has one profile or multiple profiles.
Saravanan: In those scenarios, you cannot automate those scripting. So we started using the bots. What is the robotic automatic process does is? Once the user gets disabled in Okta, all we do is using another scum microservice. We write a ticket into the service nodule. That's it. The scum code will say my process is done. I notify the service nodule. So the bots wake up and then it goes to the service nodule and then it will identify who the user is getting terminated and then goes into A is 400 green screen, I wish I could have a demo but it's due to time constraint, couldn't put the demos there.
Saravanan: So it goes into green screen as human does, like an A is 400 administrator. Find out the people and then disables it. When it disables, it also takes the picture that it is disabled and it stores for it for auditing purpose. So if internal auditor, you are... any of you are an auditing team wants to take a look at it, 'Hey can I have the screenshot?' Well that is a screenshot. That is a hue, that is a ticket which is open that is an incident reported that is an incident that is also closed. So, probably I should say, that is a 19th integration pattern which would be bots. So, here is a quick solution outcome. I said like, what are the problem statements? So here are the benefits by using scum.
Saravanan: Just wanted to give you a little bit more context to develop your own scum, it's not rocket science. First time it will be a little challenging, but there are good training systems by Okta. scum for developers. And there are good tutorials in the Okta developer guide. So, you can refer to that please. So the solution outcomes are we can see that 80% reduction in password reset. User onboard right? Earlier it took more than a day, not many number of days, but we were running into days. Now it takes less than two hours. We were trying to become right now it's near real time, we are trying for real time. Sooner I'm sure began at you there. So the 60% reduction in new hire rates because almost, not all, majority of the on-prem applications are getting integrated into Okta's platform using this scum platform.
Saravanan: So, provisioning for targeted applications which are on-prem can be easily achievable. So, in turn, it reduces the audit by 70 person. So, the manual hours are significantly reduced. And these are the business benefits. As I mentioned, it enhance the user experience because day one, when the user walks in, new hire comes in, they know where they have their laptop, they will have Office 365, they can start their first day in a very productive manner, rather with lots of frustrations, running to help this. 'Hey I don't have access. How do I create tickets?' Then the last point, rapid application onboarding. So this gives a confident to the business teams, business owners that we can get any type of applications and we can quickly onboard them. The last one is automated hire to retire process.
Saravanan: Thank you all. For any questions, I'll be around. Thank you.
Sonalia Vaidya: Great, thank you so much Saravanan. I'm going to invite our next speaker Darren Linden. He is director IT services at Alliance Data. And thank you Darren for being here today. Here this is your mic. Clicker.
Darren: Okay, thank you very much. Good afternoon. That's okay I can go fast. I realize I'm standing in between you and key notes or happy hour or whatever your schedule is. So I will try to be brief. Hi my name is Darren Linden, I'm senior director of IT services at Alliance Data. I want to walk through quickly kind of our multi cloud data center journey partnering with Okta and SP Gateway. What is Alliance Data? Alliance Data is multiple businesses, three distinct businesses. We're ultimately the engine behind loyalty and marketing programs for over a thousand consumer facing companies. We have twenty thousand users around the globe. But what we do at Alliance Data, we're basically a whole co.
Darren: We provide the large mature enterprise systems and applications that consolidate and run our business. That is our role. We started out pre Okta with major IT problems. We basically, our business model is acquire, but not necessarily integrate. We loosely couple our business units together, you know the vision is let them do what they do. But then at the end of the day, we have to roll up all the performance for planning, you know financial close, human resources, intelligence, that sort of thing. This is what we do. So we had a very aged Microsoft stack. We had multiple business units that had the same naming space, so we had conflicting naming spaces. We had no SSO, we had you know different LSB's, use different user credentials to log in to these systems. It was very fragile and probably the worst part from an IT standpoint is we had very smart people who spent basically every day trying to keep the thing working.
Darren: That drove frustration in the business. We always had outages, as Murphy had it mostly during close, a month in of forecasting. It was very frustrating and we essentially couldn't scale this environment. So, we had to come up with a new plan. So we basically took a clean whiteboard and we said, 'What do we want to do?' Well, our number one goal was to provide basically a single user experience across the entire twenty thousand seat population, regardless of line of business or location. We needed to provide MFA, we didn't have that prior. And services like self service password reset. Okta was a slam dunk for us. It made the most sense, it's the best in the market in terms of SSO and SASS, kind of that user experience.
Darren: But we had a major gap. You know we have very large on-prem complex applications. Mostly in the oracle space, which we needed, we needed kind of a hybrid solution and that's where SP Gateway came in. SP Gateway essentially fronts these applications. They look like a cloud app to our end user. Everything is in the Okta portal and it's great. Not only is the end user experience great, but we increased our security posture, basically is zero trust environment and we were able to do this without really major integration or project work within the lines of businesses. So as we built this out, we kind of started with alliance data itself and then we rolled on business units into this environment.
Darren: So business benefits, there's several. From an end user standpoint, I kind of mentioned, it's a single user experience, no matter what business you work for or what location you work for. You log in to your computer and we you know, you authenticate to your local active directory and that gets a pass through Okta. We talked about increasing our security posture with MFA and we basically didn't have to do a bunch of customization on our applications to make this work. Most importantly for us, it gave us a cloud first posture, like most businesses out there, we want to get out of running our data centers. So we needed to get basically these large mature apps out of the on-prem data center. So, that led us to what we call the lift and shift phase.
Darren: We basically extended this architecture to OCI and AWS. This architecture led the way for us to quickly move our entire oracle ecosystem to OCI and many of our other business apps to AWS. We essentially have no on-prem data center at this point, thanks to the power of Okta and SP Gateway. In summary, it's a great solution for us, you know it... at the end of the day it gives us the agility to keep up with our business as we acquire companies. It's easy to snap on a business unit. We can turn on a business service, we can turn off a business service or we can decouple a business unit. It reduced the complexity and for both IT and our in user population while improving our security posture and really drove an A service for us.
Darren: The business is happy now, systems are online and accessed anywhere, any time from any device. So, I just wanted to highlight our great partnership with SP Gateway and Okta. Thank you.
Want to easily provision and deprovision users into your company’s unique ecosystem of applications, and provide simple, secure access to enterprise apps–on-prem or in the cloud? You can! There’s a lot you can do with the pre-built connectors in the Okta Integration Network, and when you have custom business processes and applications to integrate, Okta can help with that, too. Join this session to hear from the experts on how to create custom integrations using standard protocols:
• Allergan created a vendor-supported identity control center using Okta and the Aquera SCIM Gateway to provide automated LCM, attribute mastering, and IGA imports across their applications
• Alliance Data created a multi-datacenter solution using SPGateway and Okta to bring SSO, MFA, and fine-grained access policies to multiple business units
• Wiley created SCIM integrations to SAP SuccessFactors and downstream applications to create a central identity system to create accounts, manage attributes, and deprovision users