Software generally requires IT support. While most educational and manufacturing companies have their own IT department, others may contract a third-party company for IT support. One feature that needs support of a SaaS model is Single Sign-On (SSO) support.
I am not going to explain what SSO is and how to set it up in this article but do want to talk about typical “misses” or pitfalls that lead to errors in authentication to the application.
Typically, if the basic SSO configuration steps are followed, user authentication is almost always successful. The implementation team generally provides an SSO configuration document for most Identity Providers (IdP) to the client. A client IT admin can follow the appropriate section corresponding to their IdP and create an entry for the EHS application.
SafetyStratus provides the Service Provider (sp) metadata file/url which the IT admin adds to the EHS application. The client then provides their metadata file/url which SafetyStratus incorporates to their SSO configuration. A test link is provided which the client validates. A landing page is then provided to the client for adding new users.
If the IT admin does not follow the supplied document and not map the attributes such as email address or first name, last name or employee ID, then the IdP transfers parameters with null values for these fields which lead to a failed login.
If the users don’t click on the landing page url and try to login directly to the application login url, their login will fail because they have not yet been created as a valid user in the application. If a separate user integration process is used, then the client sends a list of active users who are added to the site users and they can login directly to the application login url. This integration process will ensure better management of the user base for new users or terminated users.
It is not just the client side “oops” that can cause issues. One other piece of Service Provider authentication is adding the client to the authorization database which keeps track of all SSO clients. If that database is not updated with the schema name given at client “site” creation, then also the user authentication fails.
Another inherent miss is the expiration of the sign-on certificate in the metadata file. Most IdPs provide a three-year certificate expiration. When a certificate is due, the client typically provides the new certificate which can then be added to the Service Providers metadata. Depending on the IdP, there could be only one metadata file “active” at a given time or multiple files be “active”. For those that can have only one “active”, the client has to generate the new certificate prior to the expiration but not activate it until the service provider has updated their metadata with the new certificate. Not doing so, will break the authentication. For those that can run simultaneously, as long as the service provider also updates their metadata file, the old and new sign-on certificates can co-exist for a “no outage” transition.
In some rare cases, some clients use an expiration date for the entire metadata file. This is generally for those IdPs that can have multiple metadata files active simultaneously. For this, the service provider must replace the entire metadata file prior to the expiration of the previous one.
All of these activities are better scheduled through the support organization on either side and resources available from appropriate departments (IT and users) for immediate validation.
AUTHOR BIO:-
KC (Kalyan Madhunapantula) has over 15 years of systems administration majority of which is on Unix/Linux. He holds an MS in Environmental Engineering. His thesis on watershed modeling using a program in Fortran inspired his foray into computers. Joining an IT team of a leading multi-media company, he progressed through DBA, system administration and management.
He was the lead administrator for overseeing IT SOX compliance for 20+ applications including HR and Financials. With the advent of Cloud Services, KC embraced AWS and today serves to ensure IT security and compliancy with frameworks such as SOC2, GDPR, HIPAA and PIPEDA at SafetyStratus.
