Single Sign-On (SSO)
SSO is an authentication process for entering a single user name and password to access multiple applications or systems within a single organization.
SSO can be considered a subset of the larger concept of a Federated Identity. A Federated Identity Management System provides single access to multiple applications or systems across different enterprises.
SSO is primarily about technological approaches for solving the problem of individual users managing different identities for different applications, in contrast to the architectural concepts of a single identity for related enterprises in a Federated 'Circle of Trust'.
Security Assertion Markup Language (SAML)
SAML is an open standard for SSO, and is an XML (eXtensible Markup Language) data format for exchanging authentication and authorization data between parties. It relies on Centralized Identity Management which permits one OpenID provider.
SAML Authentication - Procedure
- User login. The user uses a SOAP (Simple Object Access Protocol to login. SOAP is a protocol for accessing web services) client to login with a user name and password. The client passes the login information (and possibly other security factors) to the LDAP (Lightweight Directory Access Protocol. LDAP validates the user and returns the information to the SOAP client.
- SAML token is created. The SOAP client passes the LDAP information and other user information it received to the SAML client. The SAML client is a service that packages the information in the correct format as a SAML token. The SAML client returns the token to the SOAP client. The SOAP client wraps the SAML token and the user request into a SOAP request.
- SAML session begins. The SOAP client starts a timed SAML session and sends the SOAP request to the appropriate web service to fulfill the user requirement. The web service parses the SAML token and verifies the authentication information via LDAP. In this way, the user only logs in once: Each web service can serve as a surrogate user (user with authority to work on behalf of another user) and is trusted by the data resource because the web service verifies request information.
- Authorization. After authentication, the web service sends a request to the SAML server running the rules engine (validates business rules). SAML is not necessarily required, but is helpful. The rules engine evaluates user parameters and determines the authorized level of access for the user, based on predefined access policies. Level of access verification is returned to the web service.
- Request fulfilment. The web service requests data from the data resource, packages it as a SOAP response, and sends it back to the SOAP client. The SOAP client presents the data to the user and terminates the SAML session. The SAML token expires and can not be re-used.
SAML Main Security Risks
These risks can be mitigated so that SAML is secure.
OpenID is an open standard for SSO authentication. It relies on Decentralized Identity Management which permits more than one OpenID provider.
OpenID Motto: "Make simple things simple and make complicated things possible."
OpenID Authentication - Procedure
- Show the OpenID authentication form.
- Accept the OpenID Identity (Unique URL that you directly control, eg. your own web page, or online address provided to you by an OpenID Provider), and pass it to the OpenID Provider or OP (central authority for user logins, that authenticates the user).
- Verify the response from the OpenID provider.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol (OAuth is an open standard for authorization. It is a complementary service to, and is distinct from OpenID. OAuth is also distinct from OATH which is an open standard for authentication.) Connect allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user. For more information, go to Related Information - OpenID Connect Identity Protocol, YouTube video.
OpenID Main Security Risk
There is a vulnerability in the end-user's OpenID URL used for login (URL which points to the end-user's website or online address designated by the OpenID provider's server to identify the end-user). Conceivably the end-user can force the OpenID provider’s server to contact a URL specified by them. The following could happen:
SAML or OpenID: One SSO Standard to Rule Them All ?
SAML is often criticized for its complexity and OpenID praised for its simplicity. However OpenID is slower. SAML is positioned more for enterprise Single Sign-On, whereas OpenID is best suited for the consumer.