How To Implement Single Sign-On(SSO)?

Here are ten concrete steps for a successful single sign-on implementation:

1) Create Application Matrix

• As part of assessing the need for SSO, you might have done this already. For a successful implementation, it’s very important to identify all the applications that you want to roll out in different phases. Think about quick but real wins. What apps do you want to integrate with your identity provider first? Sometimes, if employees do not have two-factor enabled for an app and there’s enough non-compliance, you should consider those apps first and enforce 2FA behind the identity provider (ex: Okta or OneLogin). This must be the first and foremost step for a successful SSO implementation.

2) Architecture

• As an example, do you want AD or Google apps to be the delegated master? For instance, if you decide on Active Directory as the master, identity provider will be delegating all authentication requests to your Active directory allowing users to sign in with their AD credentials. The IAM solution should automatically import the existing group hierarchy from Active Directory, simplifying the deployment.
• There are DaaS solutions available if you do not have LDAP or Active Directory. DaaS solutions connect users to a wide variety of IT resources, including Mac, Windows, and Linux devices as well as applications located both on-premises and in the cloud. If you do not have any of these solutions, design your architecture so that your identity provider will be the master who can authenticate and authorize based on local groups and roles.

3) Scope of the Roll-Out:

• Which apps in the organization are SWA (Secure Web Authentication) and which apps in the organization are SAML (applications that understand security assertion mark up language)?
• Licenses: For some applications, if you want to enable SAML or provisioning, you will need additional licenses. For example, unless you have Slack’s Enterprise plan, you cannot integrate SAML with Slack. Again, this should be carefully scoped out to fully account for the costs.
• Do you want provisioning to be enabled for the applications that support it? You need to be extremely careful with this. Some applications such as Dropbox and Google Apps provide these capabilities. If you remove/disassociate an application from a user, they will be automatically deprovisioned in the respective application as well. Same goes for provisioning. Deprovisioning accounts for inactive users bolsters security and aids in preparing for audits and compliance reporting.
• Do you want to enable both organization-managed apps and user-managed apps? Some orgs just want to expose only the company-approved enterprise applications.

4) Multi-Factor Authentication

• You want to audit your existing applications on what value this single sign on tool provides. Do you already have most of your critical apps behind two-factor? Is it enabled for all critical apps currently? Will this implementation/roll-out provide significant security advantage or more of a user-convenience? This helps you prioritize this project accordingly.
• As MFA provides more security, it’s also important on the risk appetite for your organization. Do you want to enforce MFA for people logging in within the office/corporate network? If so, plan accordingly so you want to whitelist your corporate network IP’s.

5) SLA, Response Times, and Availability

• As part of the evaluation of the SSO tool, you might have already researched about the cost of downtime, service level outages, and any system failures seen with the identity provider. If the identity provider network goes down, all the apps that have SAML enabled (Big Bang) cannot be accessible unless you change the configuration.
• Ensure that the IAM solution can integrate with multiple Active Directory domains/forests and/or LDAP directories so that even if one domain controller is down, your users can still authenticate to the other controller via delegated authentication.
• The identity providers offer local agents to sync passwords, import user repositories, and keep a constant sync of your identity store. As part of the plan, make sure to deploy multiple agents and install them on your servers.

6) Shared Accounts

• If there are shared accounts employees use, you need to identify the owners and plan this ahead of the single sign-on roll-out. Whether you use Office 365 or Google Apps, make sure you have a list of these shared accounts and provide the ability for these owners to log into these shared accounts. Mail delegation is one solution how those owners can login to those accounts after the SAML integration.

7) Implementation Window

• Since the SAML implementation for some applications is “all or nothing,” this can affect the way people access applications. There can be a significant downtime depending on the application.
• Remember that you need to involve all the other service providers (ex: Quip, Pagerduty, Amazon, Salesforce, Slack) and can make the necessary changes on their end during the same time. For example, they would need to know all employee email IDs and meta-data from your identity provider and enable the application configuration (SAML) at the same time to minimize the downtime.

8) Integrate the Tool/Logs as Part of Your Logging and Continuous Monitoring

• Single sign-on logs should be integrated into your log aggregation and monitoring solution. Log critical events (login name, source address, geo-location, application access date and time, success or failure, User-Agent, etc.) and forward it to your local log collector and integrate this process as part of your security operations. Make sure your security operations team is trained completely to analyze and respond to intrusions and suspicious events.
• As part of your data retention policies, ensure that the SSO logs are retained appropriately with your data retention practices.

9) Contractors and Temp Employees

• Contractors and temp employees usually are not part of all groups and channels employees belong to. On rare occasions, if your contractors access your corporate apps/tools, you want to make sure they are aware about the roll-out and clear instructions are provided. This is important especially if you do not have a strict delineation thereby forcing SSO layer to all the apps they access.

10) Testing Group and Feedback

• This is a very critical component of a successful single sign-on roll-out. You are changing the way that people sign into different applications. Even though there is a huge user convenience aspect to this, everyone does not see this the same way. Include all teams (including few senior management folks) as part of beta testing for your single sign-on solution. Ensure that every piece of feedback is properly addressed.

Feel free to contact E-SPIN for the various technology solution that can facilitate your single sing-on(SSO)  infrastructure availability and security monitoring.

Related article:

1. 1. What the advantages and disadvantages using SSO?
   2. The Benefits Single Sign-On(SSO)
   3. What is Single Sign-On(SSO) meaning?
   4. How does Single Sign-On actually work?