Shibboleth... a new way of thinking

The new technology of Shibboleth will involve a new way of thinking for webapplication developers and webserver administrators. In this document we want to emphasise this new way of thinking.

When you shibbolize an application, the centrally managed Shibboleth component (Identity Provider) will take care of the authentication of the user (authN). At the applicationserver, the administrators and webmasters can configure the locally managed Shibboleth component to take care of authorization (authZ). This means you don't need to create code anymore to do these things in each of your applications.
The entire process of authentication is performed requiring only little user interaction (providing his/her credentials and possibly selecting his/her home organisation at first). However a lot of things happen in the background at the same time. The user might notice some of the redirects in the process. When the user returns to the application, it is sure that he or she is authenticated securely. After that, access will be decided by rules that are defined at each application individually. In Shibboleth terms this means that the authorization is done at the Service provider (application's webserver).

So basically the centrally managed component provides identity and every application decides about access. For that purpose, every application receives a set of attributes that it can also use freely after access is granted.

Shibboleth can provide a lot of attributes which can be used to authorize a user. Because these attributes can be provided by Shibboleth, we do not expect a Shibbolized application to fetch any of those attributes from another datasource, like LDAP. Since attributes will be available in the request headers automagically, it is possible to use them in any webapplication that can access those headers.
However this "providing" of attributes only applies to data about the current, authenticated user, not to data concerning any other users. For data belonging to other users (eg for lists) the application still needs to connect to another datasource.

Examples on how to use the provided attributes in your application are provided in the download section: http://shib.kuleuven.be/download/sp/test_scripts/

1. The webserver receives a first HTTP request to a protected resource (https is highly recommended)
2. If not authenticated, the webserver sends out a redirect to a WAYF or IdP to request authentication.
3. when using SAML/POST browser profile:
   The user returns to the webserver while POSTing a SAML statement that carries authentication information.
   when using SAML/Artifact browser profile (preferred by K.U.Leuven):
   The user returns to the webserver while doing a GET operation that carries a reference to a SAML statement as a parameter.
4. The webserver talks RPC to the Shibboleth daemon, a background process, to fetch additional SAML statements if needed.
5. The daemon will identify itself to the IdP using its certificate (connects to AA or Artifact servlet at port 8443) and...
   when using SAML/POST browser profile with attribute query:
   ...fetch attributes for the current user.
   when using SAML/Artifact browser profile (=attribute push; preferred by K.U.Leuven):
   ...fetch the SAML authentication statement and attributes for the current user by dereferencing the Artifact.
   
6. The received attributes (and authentication information) are cached and fed back into the webserver, more special to its Shib module.
   The Shib module optionally compares attribute values and authorization rules to decide about access.
   When access is granted, it first clears all possible Shibboleth HTTP-headers and then fills them with received values.