==
» » » » » Single Sign-On

Single Sign-On

, , ,

Single Sign-On

Using authentication via Single Sign-On (SSO) has many advantages over simple Username/Password mechanisms. Whereas for the latter, the user has to remember multiple different Username/Password combinations, this overhead can be significantly reduced with SSO. Also, the security of Username/Password relies solely on the strength of the password provided by the user, but SSO allows for the adoption of several technical measures to further enhance the security of the login procedure.






In general, there are three participants in the SSO authentication scheme:

Service Provider (SP): Controls the resources accessed by the User.

User:  Is a normal user navigating his User Agent (UA), e.g. a browser, and requesting restricted resources on different SPs

Identity Provider (IdP): Manages the authentication of different users and generates authentication tokens for the SPs.

Advantages and Disadvantages of SSO

SSO offers many advantages:
  • Users do not have to remember multiple Username/Password combinations.
  • Security policies regarding the authentication, e.g. forcing the user to select a different password  every four weeks, can be easily applied. The user only has to change one single password – the password on the IdP.
  • Enforcement of further authentication mechanisms, e.g. Two-Factor authentication, can be applied, without having to modify any of the SPs. By this means, the implementation and integration costs of new authentication mechanisms can be reduced significantly.

The disadvantages of SSO are:
  • Privacy: The IdP can record the activities of the users and create profiles.
  • Availability: The IdP is a Single-Point-Of-Failure component in the SSO scheme. If it is not available the authentication on the SPs and the usage of their services is not possible.
  • Security: If the IdP is insecurely implemented and attacks can be successfully started, the security of the entire infrastructure is at risk. 

The SSO protocol flow





The protocol flow  includes two phases: Trust establishment and Authentication flow.

In the Trust establishment phase the IdP and SP communicate directly with each other via a secure channel. The Trust establishment phase will be executed only once in order to establish a trust relationship between both parties. The following data will be exchanged:
  • ID: A unique identifier.
  • Cert_SP/IdP: Key material, e.g.. Certificates, which will be used to verify the digital signature(s) in the SSO messages.
  • URL_SP/IdP: The endpoints of the SSO interface. All SSO related messages will be sent to this URL.
During the Authentication flow the user will be authenticated on the IdP and afterwards on the SP.
  • Step 1: The user navigates his browser to a SP and requests some resources.
  • Step 2: Since the user is not authenticated yet, the SP generates a Token Request.
  • Step 3: The user will be forwarded together with the Token Request to the IdP.
  • Step 4: The user will be authenticated. The authentication can be done via Username/Password or other authentication mechanisms, e.g. Two-factor authentication. If the user is already authenticated on the IdP, this step will be skipped.
  • Step 5: After the successful authentication of the user, the authentication token will be generated.
  • Step 6: The token will be sent through the user's browser to the SP. Afterwards, it will be verified.
  • Step 7: If the token is valid, the SP grants access to the restricted resources.

SAML

The Security Assertion Markup Languange (SAML) is one of the most used standards for Identity Management. SAML is based on the eXtensible Markup Language (XML) and enables the secure exchange of XML-based authentication and authorization messages. In conjunction with SSO systems, SAML especially offers a standardized format for authentication tokens.

In the following section we will explain the structure of the SAML messages and their role in the SSO authentication scheme.

Token Request

The Token Request is sent by the SP to the IdP in order to trigger the user's authentication. The Token Request usually does not contain any sensitive information and thus is not protected by a signature.

SAML Token Request
The parameters that are usually contained in the Token Request are:
  • ID: A nonce, which guarantees that the Token Request is freshly generated.
  • IssueInstant: A timestamp.
  • AssertionConsumerServiceURL: A URL pointing to the SAML interface of the SP, where the IdP sends the authentication token.
  • Version: SAML Version.
  • Issuer: The identity of the SP.

SAML Token

The SAML Token is generated by the IdP and sent to the SP through the user's browser. The structure of the token as well as the relevant parameters will be discussed in this section.

SAML Token

Response
The Response-element is the root-element of every authentication token. It can be digitally signed. By this means, the entire authentication token will be protected by the digital signature. However, this feature is rarely used.

The Response contains the following parameters:
  • ID: A nonce, which guarantees that the Token is freshly generated
  • IssueInstant: A timestamp.
  • Version: SAML Version.
  • InResponseTo: An optional parameter containing the ID of the Token Request received by the IdP. By this means, the SP can assign the received token to the sent request.
  • Issuer: The identity of the IdP.
Please note, that all these values are not protected by the signature. Thus, they can be easily manipulated.

Assertion
The Assertion is the most important part of the token. It contains the following information:
  • ID: A nonce, which guarantees that the Token is freshly generated
  • Timestamps - Every authentication token contains time limitations according its validity.
 /saml2p:Response/saml2:Assertion:IssueInstant
/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmationData:NotOrAfter
 /saml2p:Response/saml2:Assertion/saml2:Conditions:NotOrAfter
  • Information about the issuer (the IdP). The value is usually identical with the Issuer in the Response.
    /saml2p:Response/saml2:Assertion/saml2:Issuer
  • Information about the authenticated subject, e.g. the user. Usually the identity of the user is stored in: 
 /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID. 
Additional user information can be provided in the AttributeStatement:  
/saml2p:Response/saml2:Assertion/saml2:AttributeStatement.
  • Information about the recipient of the token. This is in most cases the URL of the SP. By this means an authentication token is restricted to a specific audience. Parameters providing information about the recipient are:
/saml2p:Response:Destination
/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmationData:Recipient
/saml2p:Response/saml2:Assertion/saml2:Conditions/AudienceRestriction
  • The digital signature can contain information about:
    • The used algorithms
/saml2p:Response/saml2:Assertion/ds:Signature/ds:SignedInfo
    • The signed elements.
 /saml2p:Response/saml2:Assertion/ds:Signature/ds:SignedInfo/ds:Reference:URI
In this case the URI-attribute in the Reference-element points to the Assertion with ID "_a30d534...da5d".
    • The signature value
 /saml2p:Response/saml2:Assertion/ds:Signature/ds:SignatureValue
    • The used key
/saml2p:Response/saml2:Assertion/ds:Signature/ds:KeyInfo

    Digital Signature contained in the SAML Token

    Authors of this Post

    Vladislav Mladenov
    Christian Mainka (@CheariX)
    Florian Feldmann
    Admin

    Pro Teknologi dibuat pada 22 Februari 2017. Blog ini adalah harapan saya agar dapat membagi manfaat kepada orang lain,berupa tips-tips Seputar Blog,Internet,Komputer,dan Info-Info Menarik lainnya.

    0 Response to "Single Sign-On"

    Post a Comment

    Subscribe to: Post Comments (Atom)