Moving an entire identity stack to a new software can be hair raising, but luckily with the use of Okta at Somerford we were able to move our SSO and identity management to Okta easily without any friction and provide better functionality for our end users.
So – how did we do it?
Identify Your Users and Groups
This can be harder than expected unless you already have a well cleaned directory, as we are a Google for Business house we were able to leverage the existing groups we had, and map those into Okta groups to then use them for provisioning all of our applications and access.
Identify Your Apps and Access Controls
Some apps may be higher value than others, such as your CRM or Finance applications – by highlighting critical apps we could place extra security controls for that specific access, reducing friction for our end users, but also enabling security policies across the board. At this point we also mapped what groups needed access to which apps, and also highlighted anyone who fell out of the norm, such as contractors or vendors we might provide temporary access to. For these users we could make specific groups for their needs, and prevent any unnecessary access.
Connect to Existing Directory
Being a Google for Business house often can make it difficult for technologies that rely on “expected” technology such as Active Directory or other legacy tools much more tricky. As Okta is totally vendor agnostic, we were easily able to keep our Google for Business groups and already existing permissions, but map those into Okta to further utilise them. This also meant we did not have to replicate work we had already done in Google. With Okta you can integrate without enabling the SSO, so no end users were prevented from accessing their day to day apps whilst we were completing the initial identity phase.
Implement Groups and Security Policies
Once we had our directory connected we were at a stage where we could start creating access policies for sign on to Okta and any critical apps identified in our earlier stages. Okta has many granular ways to set security policies and prompt for extra factors based on behaviour, such as when we are working from a customer site or remote working.
Start Configuring Apps
Currently we are using 181 apps with Okta, and all of these needed configuring up front for our SSO access by using SAML, SWA or federated authentication. This was made much easier by using Oktas Integration Network, which has most of the integration prewritten for you, where you can just fill in the details specific to your instance of the application, whether it’s on premise, hybrid, or cloud.
Testing Apps with Users
At this stage, we were able to start testing sign on into a small selection of apps with a subset of users to make sure everything was configured correctly, and that our end users did not notice too much of a change in the way they use their apps on a day to day basis.
The Big Bang!
Once testing was successful, we were able to quickly deploy access to all of our users, and also sent out FAQ guides and brief training via video, we would recommend doing this for all of your users if you are looking to implement any Identity Platform as it allows your end users to understand how to use it and also who to contact if they do have any questions.
Longer term we have leveraged Okta’s automated provisioning and deprovisioning to reduce the administration of users, this has reduced the time it takes to create a user from around 1 hour to less than 10 minutes. Moreover, Okta Workflows will now provide us automated deprovisioning of applications that do not currently support SCIM or SAML and send us an email once they have been deprovisioned.
If you want to discuss how Okta could provide your users or customers with seamless sign on into their applications, and reduce the time spent by your administrators then please do not hesitate to get in touch, and we will happily organise a one-on-one call or demonstration.