I have heard of a method for implementing a single sign-on approach to access management for SaaS that supposedly locks an employee’s password internally, so access is automatically linked through a portal based on specific information entered at the start. This would be a great solution to the problem of employees having to remember a number of different passwords for several software programs. Is this a safe alternative to current multi-password access approaches?
Ask a question
Randall Gamby, SearchSecurity.com's resident expert on identity management and access control, is standing by to answer your toughest enterprise IAM questions. Send in your questions today! (All questions are anonymous.)
With the Internet firmly engrained into every contemporary business model, and with most companies taking advantage of the cloud computing boom and outsourcing many internal functions to cloud application providers, organizations need a way to provide single sign-on (SSO) that stretches beyond their boundaries.
However, Software as a Service (SaaS) vendors are not generally tied into enterprises' identity management services. This means that as a company’s workers go about their duties, the end-user experience varies based on where applications and information is located. A worker may work from a dashboard where the information seems to be locally hosted, when in fact in the background data has been converted to a standard format and displayed from applications within the organization, as well as SaaS-supported applications.
Nevertheless, as the data a user goes after is retrieved, because SSO is not supported in the cloud, the user may be prompted many times for credentials and not necessarily the same credentials. This ordeal not only confuses employees, but requires them to maintain a key ring of credentials. Besides the issue of these credentials being different, they are on different expiry schedules with different creation rules that must be remembered or written down, a process that invariably leads to more help desk calls due to forgotten passwords.
This issue has not gone unnoticed. In order to address externalizing SSO services, OASIS created the Security Assertion Markup Language (SAML) protocol. SAML allows an organization to incorporate a user’s authorization information, including additional information such as the user’s role and identity within an external application’s data request package. Up until the last year or so, SAML was individually maintained by a host company in a star configuration, a setup where an organization maintained individual point-to-point SAML connections with its suppliers and business partners. Although this worked, this simple architecture wasn’t flexible enough to accommodate the business model for most companies. With that in mind, how does an enterprise send SAML information to a sub-contractor of the vendor it maintains a SAML connection with? Furthermore, what are the legal instruments a company needs to do this?
In keeping with a SaaS model, some vendors have begun to offer “SAML as a Service.” These offerings were created to help companies address the need for a flexible SAML model. To date, there are several SAML Internet application providers, including Ping Identity, Layer 7, SecureAuth, OKTA and others. These companies’ offerings basically provide a gateway to a Web of companies who participate with the SAML SaaS provider. The business model is simple; the host company creates a SAML connection to the SaaS provider while in turn establishing connections with many other companies. When a user needs access to data and applications hosted by other SaaS providers, they log into the SAML provider’s application and a user’s SAML assertions are routed to one or more application providers as information is retrieved. While this approach is not SSO in its purest sense, as the end user needs to log into an external SAML SAAS application to be able to move freely between the Internet-based applications, it does succeed in eliminating numerous logins. Furthermore, assuming this authentication can be done as the user initially accesses the data, preferably at the beginning of the work day, based on the company’s security policies the end user will not experience a constant disruption of authentication requests while performing their tasks.
While this is a great model to solve multi-authentication issues for SaaS-based applications and information, it can still be complicated. Negotiating what information needs to be forwarded to the individual SaaS vendors, ensuring the application SaaS vendor has a relationship with the SAML vendor, tracking end-user access around the Internet for regulatory and audit purposes, integrating the end-user application with SAML, and a myriad of other company-specific technical and business issues must still be addressed. This is contingent upon the assumption that an organization’s legal and procurement groups know what business agreements need to be in place. Nevertheless, in the end, SAML SaaS services greatly reduce the overhead an individual organization would have incurred if they undertook sole management of these services.
So where will this all go in the future? The Kantara Initiative’s User Managed Access Group (UMG) is defining models for Internet identity providers. Eventually individuals will be able to create an identity in the cloud. These cloud identities will be managed by an identity provider who will push individual identities to other companies. Even the individuals who work for the host company will be able to use their identity provider to broker their information to the company for work-created identities as well as for personal use, which could mean the end of enterprise provisioning systems.
This conjecture may seem like “blue sky” speculation, but PayPal, Google, Apple and others have begun the process of creating Internet identities, many of which are tied to SaaS offerings. Someday these companies will merge with the SAML SaaS providers to evolve into Internet identity providers who manage authentication and authorization information for everyone, not just for business-to-business connections.
This was first published in March 2012