What Shibboleth is not!

What Shibboleth is not

• An all-in-one federated identity-management solution:

  The Shibboleth reference software forms just one part of a federated access-management system; it is not a standalone application, but is designed to be combined with other components to form a federated identity-management solution.

  Shibboleth simply provides the mechanism for the exchange of attribute information between an Identity Provider and a Service Provider. The Identity Provider component facilitates the transfer of attributes, and the Service Provider component requests attributes, receives them and makes access decisions based on them.
  

  Other components that are required to implement a complete, federated identity-management solution include an authentication/Single Sign-On (SSO) system, a database of user attributes, a web server and an application server.
  

• An authentication/SSO system:

  The Shibboleth Identity Provider software does not include an authentication system. It requires an external authentication system to be used in conjunction with the web/application server. This could be as simple as the basic authentication provided by a web server or a more complex solution based on an existing web portal. The authentication system needs to be able to map an identity to the database of user attributes.
  

• An attribute store:

  The Shibboleth Identity Provider software does not store or manage user attributes. To use it effectively, an attribute store such as an LDAP directory or database is required. Understandably, user attributes do not appear when Shibboleth is installed, so the user data has to be either already available, or some means of populating the data store is needed. The use of attributes is in its infancy but names and values of attributes will evolve as Service Providers require them. eduPerson from Internet2 is a schema that is being used in this area.
  

• An architecture that defines relationships:

  Federations can set out rules, define common languages and broker trust, but they do not manage relationships between members. For example, some Service Providers may expect your users to arrive with a persistent user identifier, while others may allow anonymous access. It is essential, therefore, that Identity Providers form both business and technical relationships with Service Providers, and vice versa.
  

• An application that is simple to set up:

  As with any substantial IT integration or enterprise IT project, installing Shibboleth requires careful planning, thought and a level of technical and management expertise beyond 'point and click' or running an install script. It can involve compiling from source code, installing dependencies, modifying XML files by hand, installing and configuring web servers, generating digital certificates, debugging SSL connections and much more.

External links

You may find the following document useful in helping you understand SAML:
Debunking SAML myths and misunderstandings:
(http://www-128.ibm.com/developerworks/xml/library/x-samlmyth.html.)