Skip to Content

Traditionally, user authorisation and authentication within ICT applications has been via a userid and password. As such there is nothing against that as long as you have a minimal number of applications. The problems start when one user has several userid/password combinations for different types of applications which aren’t integrated.
As a typical SAP user, you might end up with a userid/password combination for

  • Starting your computer and logging into the network
  • Reading mail
  • Starting SAP via the gui
  • The Portal
  • SDN
  • Service Market Place

That is what I would consider to be the minimum. I’m sure that you have plenty more applications that need user authentication. You can of course use the same password and even userid (if allowed) for all these applications, but one can scarcely call this a safe situation. Things are rather visible within a company that isn’t that big.

The K.U.Leuven cooperates with other educational institutes and research centres. This resulted in a growing number of users caused not only by the number of users (physical persons) but also by all the different userids that they had for each application that they used. This resulted in one big tangle of userids and passwords which became more and more unmaintainable.
Thus, there was a need for a central user management system. The ICTS board at the K.U. Leuven chose Shibboleth as its central authentication- and authorisation infrastructure (AAI)

Shibboleth is an Internet2 middleware project with the following as some of its more important features:

  • federal user management
  • multiple federations are possible
  • access control to applications is based on user attributes
  • strong emphasis on protection of confidential private information concerning the user
  • based on open standards


How does it work?

When you shibbolize an application, the centrally managed Shibboleth component (Identity Provider) will take care of the authentication of the user (authN). At the application server, the administrators and webmasters can configure the locally managed Shibboleth component to take care of authorization (authZ). This means that you don’t need to create code anymore to do these things in each and every one of your applications.
The entire process of authentication is performed with only minimal user interaction (providing his/her credentials and possibly selecting his/her home organisation 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 certain that he or she has been securely authenticated. After that, access will be decided by rules that are defined by 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 has been 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 automatically, it is possible to use them in any web application 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.


All of this is maybe a bit too high level, so let’s take a look at things in detail.


This picture explains the entire login process from an application point of view (start at the top):

  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, and to its Shib module in particular.
    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.

All of this was implemented in November 2006. Strong authentication via digipass or eID will be done in another phase.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Eddy De Clercq Post author

      I’m not a security expert, but these are my initial thoughts. At first sight, the main idea is somewhat the same. The (technical) implementation is rather different.
      The keywords differences:
      – openid: decentralized, XRI, non trusted
      – shib : federated, SAML, trusted

      I didn’t read things in depth, but I don’t see real use for SSO, ticketing, etc.

      The fact that openid is non trusted and thus no proof that you’re really the person you claim to be is a major flaw.


      1. Former Member
        OpenID sends you back to a website guaranteeing you are who you said you are via the URL.  So, the authorization has occurred.  If you get re-directed to other sites you can authenticate to those also automatically via a re-direct.  There is also an option of hosting your own OpenID server ( the ruby implementation is open source ) so, you can even customize how it looks and where passwords are stored.  I will have to read more about shib to understand the differences.
        Thanks for highlighting the technology!

Leave a Reply