Expert Demo - Demo Home Organization - Testing - APIs & Technical Guides - for Universities - Switch edu-ID

Expert Demo

To be better able to understand this technical introduction, we strongly recommend you to read the simple demo and the medium demo first.
The content of this introduction is aimed at technicians and therefore quite detailed.

Overview

Figure 1: Situation overview

As shown in Fig. 1 the scenario is the same as in the simple demo and the medium demo but background processes and interacting components are also considered in this introduction.

In the following, it is distinguished between the data sent from the user's web browser to the web server (GET requests and POST requests) and the data received by the user from the web server (redirect responses and data responses).
Some detail information is emphasized using a [DETAIL POPUP] link. For better readability the data is shown in URL decoded form, e.g. a '://' would be '%3A%2F%2F' in the real data.

Phase 1 - First access to the Service Provider and Identity Provider discovery

Figure 2: Discovery

Step 1 (User ⇔ Browser ⇔ Service Provider):

The user opens a web browser and accesses the Service Provider located at https://aai-demo.switch.ch/secure. His web browser sends the following request:

GET https://aai-demo.switch.ch/secure

Because https://aai-demo.switch.ch/secure is protected by the Shibboleth Service Provider, it is checked if the user already has a Shibboleth session and therefore was authenticated already. If the user is not authenticated, the web server answers with an HTTP Redirect to the Discovery Service located at wayf-test.switch.ch. Since the Discovery Service server needs to know where to return the user's Home Organization selection to, the relevant information is provided as GET parameter:

302 FOUND (REDIRECT)
  Set-Cookie: _shibstate_64656661756c7468747470733a2f2...
    value=https://aai-demo.switch.ch/secure
    path=/

  Location: https://wayf-test.switch.ch/SWITCHaai/WAYF
   ?entityID=https://aai-demo.switch.ch/shibboleth
   &return=https://aai-demo.switch.ch/Shibboleth.sso/Login?SAMLDS=1&target=ss:mem

Step 2: (Browser ⇔ Discovery Service)

Consequently, the web browser sends a new request to the Discovery Service:

GET https://wayf-test.switch.ch/SWITCHaai/WAYF
      ?entityID=https://aai-demo.switch.ch/shibboleth
      &return=https://aai-demo.switch.ch/Shibboleth.sso/Login?SAMLDS=1&target=ss:mem

The Discovery Service answers with the web page that allows the user to select an Identity Provider:

200 OK
  [WAYF DROPDOWN HTML PAGE]

Step 3: (User ⇔ Browser ⇔ Discovery Service)

On the Discovery Service page, the user submits the Identity Provider selection:

POST https://wayf-test.switch.ch/aaitest/WAYF?entityID=https://aai-demo.switch.ch/shibboleth&return=https://aai-demo.switch.ch/Shibboleth.sso/Login?SAMLDS=1&target=ss:mem

  POSTDATA
    user_idp=https://aai-demo-idp.switch.ch/idp/shibboleth

The Discovery Service sends a redirect to the return destination including the IdP selection:

302 FOUND (REDIRECT)
  Location: https://aai-demo.switch.ch/Shibboleth.sso/Login
    ?SAMLDS=1
    &target=ss:mem
    &entityID=https://aai-demo-idp.switch.ch/idp/shibboleth

Phase 2 - Session initiation and authentication request

Figure 3: Session initiation and authentication request

Step 4 (Browser ⇔ Service Provider):

Due to the previous redirect response, the browser sends the following request:

GET https://aai-demo.switch.ch/Shibboleth.sso/Login
      ?SAMLDS=1
      &target=ss:mem
      &entityID=https://aai-demo-idp.switch.ch/idp/shibboleth

The session initiator creates an authentication request and returns it within an auto-submit-post-form:

200 OK
  [AUTHN REQUEST POST FORM HTML PAGE]

Step 5 (Browser ⇔ Identity Provider):

The browser posts the following request with use of Javascript automatically:

POST https://aai-demo-idp.switch.ch/idp/profile/SAML2/POST/SSO
  POSTDATA
    RelayState=ss:mem:23e3a3b1268acd89dc226bb1ce0d0c6ba7ecf773
    SAMLRequest=PHNhbWxwOkF1dGhuUmVxdWVzdCB4bWxuczp...

The Identity Provider checks the authentication request, because the user is not authenticated, it sends a redirect to the appropiate login handler (here: Username/Password):

302 MOVED TEMPORARILY (REDIRECT)
  Set-Cookie: _idp_authn_lc_key
    value=C22C16A197CB9606067A1A577EF5D996
    Path=/idp
    Secure

  Location: https://aai-demo-idp.switch.ch:443/idp/AuthnEngine

Step 6 (Browser ⇔ Identity Provider):

The web browser is redirected to the username/password login handler:

GET https://aai-demo-idp.switch.ch/idp/AuthnEngine
  Cookie: _idp_authn_lc_key
    value=C22C16A197CB9606067A1A577EF5D996

The Identity Provider redirects then to the specific username/password web page:

302 MOVED TEMPORARILY (REDIRECT)
Location: https://aai-demo-idp.switch.ch:443/idp/Authn/UserPassword

Step 7 (Browser ⇔ Identity Provider):

The browser sends subsequently a GET request for the username/password web page:

GET https://aai-demo-idp.switch.ch/idp/Authn/UserPassword    
  Cookie: _idp_authn_lc_key
    value=C22C16A197CB9606067A1A577EF5D996

The web server responds with the username/password page:

200 OK
  [USERNAME PASSWORD LOGIN FORM HTML PAGE]

Phase 3 - Authentication, attribute statement and access

Figure 4: Authentication, attribute statement and access

Step 8 (User ⇔ Browser ⇔ Identity Provider):

The user types his username and password credentials and submits them to the Identity Provider:

POST https://aai-demo-idp.switch.ch/idp/Authn/UserPassword
  POSTDATA
    j_username=demouser
    j_password=demo

  Cookie: _idp_authn_lc_key
    value=C22C16A197CB9606067A1A577EF5D996

The Identity Provider's authentication engine verifies the credentials. After the user/principal was sucessfully authenticated, the attribute authority will perform the attribute resolving and attribute filtering. Then an HTML page is generated which includes a SAML assertion. Because this assertion contains not only an authentication statement but also an attribute statement with the user's attributes, this way of sending the attributes is called "Attribute Push". The assertion is transmitted using an auto-submit-post-form:

200 OK
  Set-Cookie: _idp_session
    value=4m2ETlKYtvbNEmBzVNo3UHLuKSdo3HqTUqAmeZiar94=
    Path=/idp
    
  [ASSERTION POST FORM HTML PAGE]

Step 9 (Browser ⇔ Service Provider):

The web browser posts the following request immediately:

POST https://aai-demo.switch.ch/Shibboleth.sso/SAML2/POST
  POSTDATA
    RelayState=cookie
    SAMLResponse=PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGl...

  Cookie: _shibstate_64656661756c7468747470733a2f2...
    value=https%3A%2F%2Faai-demo.switch.ch%2Fsecure

The Service Provider processes the SAML assertion including the authentication and attribute statements. Finally it sends a redirect to the prior requested ressource, whose URL was stored in the _shibstate cookie:

302 FOUND (REDIRECT)
  Set-Cookie: _shibstate_64656661756c7468747470733a2f2...
    value=
    path=/

  Set-Cookie: _shibsession_64656661756c7468747470733a2f2...
    value=_0b6d4e89d2e9c4481738094f2a2c9de0
    path=/

  Location: https://aai-demo.switch.ch/secure

Step 10 (Browser ⇔ Service Provider):

As in step 1, the browser requests again the protected resource at https://aai-demo.switch.ch/secure:

GET https://aai-demo.switch.ch/secure
  
  Cookie: _shibsession_64656661756c7468747470733a2f2...
    value=_0b6d4e89d2e9c4481738094f2a2c9de0

This time however, the user is authenticated. To decide whether a user is allowed to access a protected resource, the mod_shib module embedded in the Apache web server examines the Shibboleth access rules and tries to match them using the user's attributes. In this demo, the following access rules is used (any authenticated user is able to access):

# content of secure/.htaccess
AuthType shibboleth
ShibRequireSession On
require valid-user

The Service Provider returns the content of accessed page:

200 OK
  [RESOURCE HTML PAGE]

Summary - Shibboleth Login Procedure

Figure 5: The whole login procedure

Subsequent accesses to the Service Provider are granted directly until the Shibboleth session timeout requires a fresh authentication.

Expert Session Add-On

Take a look at the expert session add-on if you would like to see the flows when SP or IdP session is already existent.

Medium Demo

Take a look at the medium demo if you would like to see this login procedure in action.