Single-Sign-On (SSO) Implementation Requirements

Single-Sign-On (SSO) Implementation Requirements – Best Practices

  1. SSO solution should be able to integrate with existing Digital Key Management and Cryptoprocessing Modules such as Hardware Security Modules (HSM).
  1. SSO solution should be able to perform “authentication after authentication”, where the User is prompted for the Second Factor Authentication Input (SMS/Token), when required to do so.
  1. The SSO solution should be able to support different authentication policies for different User Groups (Password Requirements, Password Expiry, Session Expiry due to Inactivity, Session Absolute Expiry, Account Lockouts, etc).
  1. Password Hashing Algorithm which is used to store passwords in the backend database should be compliant with Industry Best Practices.
  1. Logging should be enabled to capture User Events, Admin Events and System Events – Timestamp, User ID, User IP Address, Failed Login Attempts, Account Lockouts, Successful Logins, Applications Being Accessed, Roles Being Accessed, Session Expiry Time/Logout Time, SSO Admin Activity, Critical System Errors, Connectivity Issues, etc.
  1. Logs should be pushed to the central SIEM infrastructure as soon as they are generated.  Logs should also be retained in the SSO system for troubleshooting/review, closer to the time of occurrence.
  1. All SSO related Administration and Service Accounts should be managed through the Privileged Account Management Solution.
  1. The SSO Solution should cater for selectively turning On/Off SSO for individual applications (example: through the provision of alternate login URLs for direct authentication into an application).
  1. If SSO infrastructure fails, it is ideal to have an alternate mechanism for Users to use to login into the individual applications.
  1. The SSO User ID format should be pre-defined and it should indicate the Group of the User.
  1. SSO solution should cater for Password Reset mechanisms which can be managed by the User after the User has authenticated himself.  The SSO solution should also be integrated with the Helpdesk/Service Desk teams so that they could reset password through their pre-defined process.
  1. SSO solution should provide High-Availability (99.99% uptime) and should have a Disaster Recovery setup.
  1. The connectivity channel offered to users and between SSO components should be secured with industry standard TLS protocol which relies on Digital Certificates and not relying on passwords pre-determined by the installer or shared secrets set by the administrators.
  1. All sensitive details in browser cookies should be encrypted using industry standard algorithms (This should be in-addition to the encryption provided by TLS).  Furthermore, cookie Secure flag and HTTPOnly flag should be set.
  1. The Product Vendor’s SLA and the Solution Implementation Vendor’s SLA should be clearly defined and communication channels should be clearly documented.  The Criticality Level definitions should match with the Company’s Internal Definitions.  The channels through which security patches will be communicated to the Company and made available should be documented.
  1. Administration functions and Admin Interfaces in the SSO solution should be clearly defined, documented and implemented.
  1. The maximum capacity and idle load (number of concurrent user sessions, response times, etc) should be clearly documented.  Additional costs (licensing, hardware, implementation, maintenance, effort, lead time, etc) and restrictions/limitations for scaling-up the capacity should be clearly documented.
  1. SSO solution configurations/implementations in an Environment (Development, SIT, UAT, and Production) should be easily deployable to another environment.   [Migration should be as automated as possible and reduce manual work/effort]
  1. SAML messages should be over TLS and they should be digitally signed.


An example of SSO Solution – IBM TIM and TAM

IBM Tivoli Access Manager (TAM): Is an SSO solution that authorizes and authenticates user access to Web and other hosted applications.

IBM Tivoli Identity Manager (TIM): Is a policy-based identity and access governance solution that helps automate lifecycle management of user roles, identities and access rights.  Through the use of roles, accounts, and access permissions, Tivoli Identity Manager helps automate the creation, modification, and termination of user privileges throughout the entire user lifecycle.

IBM TIM can be used with any application that requires a User ID.  Creates physical User IDs for target applications (Multiple User IDs will be created per User for the different applications).  The implementation is adapter based.

IBM TAM is used for implementing SSO for Web based applications.  It creates an SSO User ID for all applications (One User ID per TAM user).  The implementation of the solution is Reverse Proxy based.



Single-Sign-On (SSO) Implementation Requirements

Leave a Reply

Your email address will not be published. Required fields are marked *