From my previous blog we saw that implementing Corporate SSO is one of the most cost effective ways to enable cloud-based employee services and tools. Integration to each cloud services has a small to medium start up effort but then immediately starts paying benefits in terms of reduced cost of internal application maintenance and user management.
This blog will cover some of most common nuances and considerations to help you implement single sign-on in the most effective manner.
The three parts of Corporate SSO
Corporate SSO requires three pieces, two of which you provide, and one is provided by your cloud-based service provider.
The corporate directory
Corporate single sign-on solutions expect that you have a single employee directory that contains all of your employees along with their user ids and passwords. Popular directories are Active Directory by Microsoft and LDAP by many vendors/organizations. If you have such a directory, you are all set. If you do not have all of your users already assembled into one large directory, most solutions will tell you to create such a directory and use it as the main source (system of record) for all userids and passwords. This can be a tall order. Another options is to find an Identity provider (next section) that can work with multiple user directories and databases. Other SSO solutions in the cloud will allow you (or require you) to import all your user’s ids and passwords into their systems. Of course, this defeats one of the main reasons for getting an SSO system, keeping user passwords inside your own network.
The Identity Provider (IDP)
The identity provider is provided by you and performs your half of the single sign-on process. You can find/purchase and IDP yourself or find a cloud-based provider to host it for you. When your employee tries to connect to one of your corporate services, the IDP first makes sure they have are already signed-in to corporate network (if not, it signs them in right then and there). It then sends a single sign-on message called an Assertion or Claim, the service provider (next section) which then allows the user to access the service. We won’t get into the technical details of an SSO handshake here. The important thing to know is it is a secure transaction and the user’s password is never sent to your cloud-based service provider. There are a number of SSO protocols that your service provider might be using including SAML 1.1, SAML 2.0, WS-Federation, OpenID, OpenIDConnect, OAuth 1.0 and OAuth 2.0. Make sure your identity provider support them all. Your cloud service will almost always support only one.
If the IDP is cloud-based, pay attention to how it accesses your employee userids and passwords. Some systems want you to copy all your passwords to the cloud. Others want you to punch a hole through your firewalls and give their cloud systems direct access to your internal network and directory. Auditors tend to frown on both of these approaches.
The Service Provider (SP)
The service provider, also known as Relying Party (RP), is provided and managed by each cloud service that subscribe to. Most cloud-based service providers include a service provider that will usually implement one SSO protocol, with SAML version 2.0 being the most popular. Major cloud services such as Salesforce and Service now have well tested SP implementations, but minor providers often implement the bare minimum functionality. These “lite” versions may not implement the full protocol or may have strange interpretations of the SSO protocol. There is not much to be done about this but to be sure that your IDP is flexible in its ability to accept and produce all the variant assertions and claims that your cloud partner may require.
You, or your SSO provider will work with your cloud partner to setup the SSO session, this will work differently for every cloud-based service partner so check their web sites or call your service provider rep for instructions.
Another requirement is to load the cloud service with all of your employee info (excluding their passwords). This is usually done one of two ways. Either a feed containing user info such as a spreadsheet is upload to your cloud partner, or the partner service provider supports auto provisioning. With auto provisioning, users are created automatically the first time they connect via SSO. To support this, your identity provider (IDP) must send additional information in the SSO request (assertion or claim). This information usually includes the user’s first name, last name and email address, but may also include country, state, phone number etc. This information is provided by your IDP by connection to your central directory. This information may also need to be “massaged”. For example, you may have a phone number in your central directory of the form (212)-555-1234, but one of your service providers requires it in the form 212.555.1234. Some identity providers have transformation rules that allow this type of modification.
Although there may be some frustration and effort for the initial setups with your partners, SSO implementation pays off in a big way for users that don’t need to manage a bucket of passwords, IT managers who get the benefit of cloud services, security administrations with only one set of credentials to manage per user and happy auditors.