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:

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:

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:

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):