Site Options:


Keylogging Ontology

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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

Replay Attack
A Replay Attack occurs when an intruder hijacks a SAML token and replays or re-uses it to gain access.

DNS Spoofing
DNS spoofing occurs when an intruder intercepts a SAML token and sends a false DNS address.

HTTP Referrer Attack
HTTP Referrer Attack occurs when an intruder re-uses an HTTP referrer tag.

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

  1. Show the OpenID authentication form.
  2. 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).
  3. Verify the response from the OpenID provider.

OpenID Connect

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:

Access Internal Hosts
The end-user could force the OpenID provider's server to contact internal hosts or servers inside the external firewall.

Access External Hosts
If the end-user found a security flaw in a server outside the external firewall, this flaw could possibly be accessed remotely by the OpenID provider's server, which could place the blame on the OpenID provider. For an intruder, having a target to take blame for an attack on another target can be crucial.

Data Flooding
An end-user could potentially use their OpenID URL to flood the OpenID provider's server with large amounts of data.

Denial-of-Service Attacks (DoS)
A DoS attack occurs when a server is flooded by more requests than it can handle and thus becomes unavailable. In this scenario, the end-user would flood the OpenID provider's server with authentication requests.

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.

Related Information:
Keylogging Ontology
Problem & Solution
MobileTrust: FAQs

Related Reference: