Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Alice will access the remote application using a link on the intranet, a bookmark or similar and the application will load. Let's assume the URL is https://mail.google.com/a/my-university.nl
  2. The application identifies the user’s origin by the application subdomain, user IP address or similar and redirects the user back to the identity provider, asking for authentication. When connected to SURFconext, SURFconext is the Identity Provider to the service. This is the authentication request and the SP will generate a SAML Request.
  3. The SP will instruct the browser to redirect the user to SURFconext with a request to authenticate the user..
  4. When Alice's browser arrives at the SURFconext she must select her IdP for authentication. This is done using the so-called WAYF (Were Are You From) page. Alice chooses the institution she has an account with. The message to SURFconext may look like this (abbreviated):
    1. https://idp.unimy-university.nl/sso?SAMLRequest=fVLLTuswEN0j8Q...c%3D
  5. Embedded in the redirection is a SAML Authentication Request. This message is compressed to save space in the URL and encoded because some characters are not allowed in URL's. The IdP authenticates the user, usually by asking to enter his credentials. Taken away the encoding and compression, the SAML message could look like this:

    Code Block
    languagexml
    titleSAML Authentication request
    linenumberstrue
    <AuthnRequest ID="kfcn...lfki"
     Version="2.0"
     IssueInstant="2013-02-05T08:28:50Z"
     ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     ProviderName="google.com"
     AssertionConsumerServiceURL="https://www.google.com/a/uniidp.my-university.nl/acs"
    >
     <Issuer>google.com</Issuer>
     <NameIDPolicy AllowCreate="true"
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
     />
    </AuthnRequest>

    Simply said, this message is: "This is a request from the SP with EntityID 'https://mail.google.com/a/my-university.nl'. Please authenticate the user and send the result back to me." For detailed information about the authentication request read our page about authentication requests.

  6. After successful authentication, the IdP builds the authentication response in the form of an XML-document, signs it using an X.509 certificate, and posts this information to the service provider, which is SURFconext for the IdP.  This is the SAML Response and this message also contains the attributes from the user..
  7. The IdP sends sends the Encoded SAML Response to Alice' browser. Basically this says “This is a message from from 'idp.unimy-university.nl', I have successfully authenticated a user. Take note that this message will expire in a couple of minutes”. The message contains an XML digital signature, proving that the message was sent by by 'idp.unimy-university.nl'. The signature was made using a public key algorithm, the public key being embedded in a certificate known to the SP. Decoded, the message looks like this:

    Code Block
    languagexml
    titleSAML response to browser
    linenumberstrue
    <Response
     Version="2.0"
     IssueInstant="2013-02-05T08:29:00Z"
     Destination="https://www.google.com/a/idp.my-university.uni.nl/acs"
     InResponseTo="kfcn...lfki">
     <Issuer>https://idp.uni.nl/</Issuer>
     <Status>
     <StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
     </Status>
     <Assertion Version="2.0" IssueInstant="2013-02-05T08:29:00Z">
     <Issuer>https://idp.unimy-university.nl/</Issuer>
     <Subject>
     <NameID>alice</NameID>
     <SubjectConfirmation ...>
     <SubjectConfirmationData
     NotOnOrAfter="2013-02-05T08:34:00Z"
     Recipient="https://www.google.com/a/idp.my.uni-university.nl/acs"
     InResponseTo="kfcn...lfki"/>
     </SubjectConfirmation>
     </Subject>
     <Conditions
     NotBefore="2013-02-05T08:28:30Z"
     NotOnOrAfter="2013-02-05T08:34:00Z">
     </Conditions>
     <AuthnStatement
     AuthnInstant="2013-02-05T08:29:00Z"
     SessionNotOnOrAfter="2013-02-05T16:29:00Z >
     </AuthnStatement>
     </Assertion>
    </Response>
  8. SURFconext validates the response message and if OK makes some alterations, e.g. rewriting the user's identifier and adding or modifying attributes. According to the attribute release policy applied, SURFconext determines the attributes that are allowed through to the Service Provider. The SAML Response instructs the browser of Alice to send the response to the Assertion Consumer Service (ACS) URL of the SP. An Assertion is a set of security statements about a subject created by an Asserting Party, being an IdP.
  9. The SP verifies the XML signature, checks if the authentication was successful and if the message is not expired. Then it extracts the user’s identifier and attributes as known to SP. If this step is OK, Alice is logged on, her mailbox is retrieved and she can read her mail.

...