Búsqueda según base de datos

This part describes how Shibboleth works, how components cooperate each other to achieve the single sign on process. According to Cantor, S (2005) and Shibboleth (2013), the following sequence illustrates the steps and interactions that occur within a typical Shibboleth-based single sign on scenario. The main actors in that processes are the components described above. This scenario assumes that a user wants to get access to a secured resource for the first time and successfully.

1) HTTP request to SP: The user through an HTTP request attempts to access a protected resource hosted by the service provider. The resource manager checks whether the user gets an active session or not. Once noticing that the user does not have an active session, the user request is sent to the Service Provider aiming to begin the SSO operation.

2) Authentication Request issued by Service Provider to Identity Provider:

Once the SP has received the user request, an authentication request is prepared associated to the user request and redirected to the Identity Provider. It is worthwhile to note that the Service Provider application is usually deployed in the same server with the resource.

In the case there are many Identity Providers, the authentication request and the user request are first sent intermediately to the Discovery Service (DS)/WAYF in order for the SP to determine and select an IdP to which belongs the user before all is sent to the appropriate IdP. Shibboleth provides two services/applications to deal with this case: The Centralized Discovery Service and the Embedded Discovery Service, however, Shibboleth Responsible highly encourages the second one to service providers developers as it offers more user experience.

3) Identification and Authentication of the user by the IdP: When the request from the SP arrives at the IdP, it checks whether the user has an existing session or not, if it is the case, the step 4 is proceeded, if not, the user is prompted to provide their access parameters (e.g., a username and a password) and the user is proceeded to the next step (4).

4) IdP issues Authentication Response to SP (<samlp:Response> or SAML Artifact(s)): As the user parameters have been correct and therefore the user has been identified, the IdP generates a SAML response or more artefact(s) message(s) considered as an authentication response and sends it back with the user request to the service provider.

5) Service Provider checks the response: When the user request and the authentication response from the identity provider reach the service provider, the authentication response undergoes a validation and a user session is created by the SP that also provides some important information such as a user identifier to be used by the protected resource. Afterwards, the user is now directed to the target resource.

6) Resource returns its content: Finally, since the resource knows who the user is, the resource decides to provide the user with the requested service, application or data.

The sequence diagram of the above SSO steps is illustrated on the figure 8 as bellow shown.

Figure 8: SSO sequence diagram

Other elements and features intervening in Shibboleth SSO

By reading the above SSO steps, one may ask some questions about how are some steps or sub-steps achieved. Shibboleth (2013) explained as below described some important elements and features that also help Shibboleth to achieve the SSO mechanism and more about the way Shibboleth works.

- User attributes: One great benefit of using Shibboleth is the advanced capacity of a Shibboleth SP to easily receive data from a Shibboleth IdP and vice versa.

Without these data also called user attributes a user cannot be indentified and authenticated. Attributes can be email address, phone number, information about a group to which the user belong, its function in an organisation and so on.

User Agent Service Provider Discovery Service Identity Provider

1) HTTP request to SP

2) Authentication Request issued by SP to IdP

3) Identification and Authentication of the user by the IdP

4) IdP issues Authentication Response to SP

5),6) Validates the response & provides the resource to the User

- Shibboleth metadata: One may also ask how do IdP and SP communicate each other over HTTP, they way each entity knows each other URLs and more. This role is completed by “data about data or data for data” called metadata. A metadata document describes in detail different aspects related to an IdP or an SP. The SP metadata file should be loaded in the IdP and the IdP metadata should be loaded in the SP properly to allow communication between them.

A SP or IdP metadata generally comprises messages URLs, an entity ID as identifier, cryptographic information about messages creation and a human-readable name and description.

- Federated Single Sign On with Shibboleth: The above SSO steps are quite similar to most SSO systems. However, some of those systems are defined to operate only when the SP and the IdP are within the same organisation. The SSO implementation through Shibboleth performs regardless of whether the SP and the IdP are within the same network/organisation or not. This highly advantageous feature makes Shibboleth to be additionally defined as a federated SSO mechanism.

- Shibboleth profiles: Generally, SAML profiles specify the components of interoperability, that means if different products support a set of defined profiles, they can cooperated each other at a certain given level. The Shibboleth profiles specification defines a set of functions that can be performed. For example, the Shibboleth IdP does not support yet the Single Logout (out of scope of this project). The figure 9 below shows the profiles supported by Shibboleth SP and IdP.

SAML 1.1 Protocol

Profile Identity Provider Service Provider

• SSO Profile Yes Yes

• Shibboleth SSO Request Profile

Yes Yes

• Attribute Query Yes Yes

• Artifact Resolution Yes Yes

SAML 2.0 Protocol

Profile Identity Provider Service Provider

SSO Yes Yes

• Attribute Query Yes Yes

• Artifact Resolution Yes Yes

• Enhanced Client Yes Yes

• Single Logout No Yes

• Name ID management No Yes

• WS-Federation Passive (ADFS) No Yes

• US eAuth v1 No Yes

Figure 9: Shibboleth profiles

- Shibboleth Bindings: Bindings define and describe the way messages are carried from a sender to a recipient. Some binding’s examples include the POST binding that determines how to format, name and send messages to a recipient through a HTTP POST request. The Redirect binding determine the way to send a message through a URL of an HTTP redirect request.