Actions

History

Shibboleth » History » Revision 28

« Previous | Revision 28/35 (diff) | Next »
Lutz Suhrbier, 09/12/2008 08:33 PM
Shibboleth Image link updated

Shibboleth is an Internet2 Middleware Initiative project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on SAML. Federated identity allows for information about users in one security domain to be provided to other organizations in a common federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain usernames and passwords. Identity providers (IdPs) supply user information, while service providers (SPs) consume this information and gate access to secure content.

_Shibboleth (IPA: [ËˆÊƒÉªbÉ™lÉ›Î¸]r1) is any language usage indicative of one's social or regional origin, or more broadly, any practice that identifies members of a group._


_In the Hebrew Bible, pronunciation of this word was used to distinguish members of a group (like Ephraim) whose dialect lacked a /Êƒ/ sound (as in shoe) from members of a group (like Gilead) whose dialect included such a sound._


_"The Gileadites captured the fords of the Jordan leading to Ephraim, and whenever a survivour of Ephraim said, "Let me go over," the men of Gilead asked him, "Are you an Ephraimite?" If he replied, "No," they said, "All right, say 'Shibboleth'." If he said, "Sibboleth," because he could not pronounce the word correctly, they seized him and killed him at the fords of the Jordan. Forty-two thousand Ephraimites were killed at that time." (Judges 12:5-6, NIV)_

Shibboleth¶

Shibboleth Overview¶

Shibboleth is an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on SAML. Federated identity allows for information about users in one security domain to be provided to other organizations in a common federation. This allows for cross-domain single sign-on and removes the need for content providers to maintain usernames and passwords. Identity providers (IdPs) supply user information, while service providers (SPs) consume this information and gate access to secure content.

Shibboleth provides a secure framework for one organization to transmit any attributes about a web-browsing individual across security domains to another institution. In the primary usage case, when a user attempts to access a resource at a remote domain, the user's own home security domain can send certain information about that user to the service provider site in a trusted exchange. These attributes can then be used by that service to help determine whether to grant the user access to it's resource. The user may have the ability to decide whether to release specific attributes to certain sites by specifying personal Attribute Release Policies (ARP's), effectively preserving privacy while still granting access based on trusted information.

It is an Middleware Initiative":http://middleware.internet2.edu/Internet2 project and has been under development since 2001. As a stable tool build on accepted security standards such as SAML, it has been promoted by the National Science Foundation's Middleware Initiative (NMI), the Middleware Architecture Committee for Education (MACE) and the "Higher Education Funding Council for England together with JISC Shibboleth is particularly popular within the higher education community which should facilitate the acceptance of it with many academic partners in EDIT.

Shibboleth Identity Provider (IdP)¶

At the heart of Shibboleth lies the Identity Provider. It knows how to authenticate a user (but doesn't do this by itself) and supplies service providers with attributes about a user through its Attribute Authority component. An IdP can expose identities through OpenID as well, enabling a shibboleth user to interoperate with many lightweight web 2.0 applications.

Shibboleth does not include a bundled authentication system as of 1.3. One that supports some form of single sign-on and is capable of populating REMOTE_USER must be used to protect the SSO handler. Everything from Apache's included mod_auth to sophisticated SSO systems such as Pubcookie and CAS will work. Shibboleth 2.0 will provide authentication functionality as well as an API for use of other authentication mechanisms. But Shibboleth is also able to interface with a directory exporting an LDAP interface containing user attributes, a relational database with a JDBC connection, and is designed such that interfaces to other repositories may be implemented.

EDIT IdP¶

The EDIT provided IdP uses an Apache based authentication accessing the Drupal based ExpertsDatabase that manages credentials and user attributes like a persons name, email, taxonomic interest, geographic focus and the like. See wiki:Shibboleth#User%20Attributes for more details on shared user metadata in EDIT.

Shibboleth Service Provider (SP)¶

A service provider is an entity that provides a web-based service, application, or resource subject to access control by Shibboleth.

Shibboleth "applications" are the primary unit of SP configuration. An individual application represents a set of web resources that operates using the same attribute handling and trust configuration and shares a common session with the browser user. As a user navigates between resources on a server that cross an application boundary, a new session is established, though user interaction may not be required. As a consequence of the relationship between applications and sessions (which are tracked with a cookie), an application usually does not span more than one virtual host. Apart from cookie-based constraints, web resources can be aggregated into applications in arbitrary ways.

Much of the SP implementation is concerned with establishing, and subsequently maintaining, sessions with the browser user on behalf of the applications at the SP. A session consists of a cookie passed between the browser and web server, associated with a security context. The context contains the user's authentication information, and generally a set of attributes that make up the user's identity. Each application maintains distinct sessions with the browser by means of separate cookies. It is important to note that all such sessions are independent and distinct: any session can exist with or without any other session, and the expiration of any one session does not imply the expiration of any other session. Shibboleth also does not support any logout functionality beyond the termination of individual application sessions by deletion of respective cookies; also, there is no way for the SP to cause IdP-side sessions, such as a user's SSO login, to expire.

EDIT Federation¶

A Shibboleth federation provides part of the underlying trust required for function of the Shibboleth architecture. A federation is a group of organizations (universities, corporations, content providers, etc.) who agree to exchange user attributes using the SAML/Shibboleth protocols and abide by a common set of policies and practices. In so doing, they must implicitly or explicitly agree to a common set of guidelines.

A federation can be created in a variety of formats and trust models, but must provide a certain set of services to federation members. It needs to supply a registry to process applications to the federation and distribute membership information to the IdP and SP sites. This must include distribution of the PKI components necessary for trust between IdP's and SPs. There also needs to be a set of agreements and best practices defined by the federation governing the exchange, use, and population of attributes before and after transit, and there should be a way to find information on local authentication and authorization practices for federation members.

Initially the EDIT platform will work with a single IdP only. But as the institutional integration proceeds a true distributed institute can be realised by setting up further Identity Providers in larger institutions. Those IdPs can authorise and provide data on their users with their own local user management, i.e. they can expose their local user management if they want to. The setup of a true Shibboleth federation should be discussed with the ISTC as it provides a great potential of integrating IT resources.

User Attributes¶

Shibboleth's access control is performed by matching attributes supplied by IdPs against rules defined by SPs. An attribute is any atom of information about a user, such as "member of this community", "Alice Smith", or "licensed under contract A". User identity is considered an attribute, and is only passed when explicitly required, which preserves user privacy. Attributes can be written in Java or pulled from directories and databases. Standard X.520 attributes are most commonly used, but new attributes can be arbitrarily defined as long as they are understood and interpreted similarly by the IdP and SP in a transaction.

EduPerson¶

For resources that are being shared to a large community, it is also to the benefit of the resource provider to have a set of common attributes that can be easily categorized and distinguished. Among the Shibboleth participants, the most popular attribute scheme is EduPerson which is the default scheme in Shibboleth. It defines a series of fields that are most relevant to the academic environment. Some of the fields that are relevant for authorization purpose in EDIT are:

eduPersonPrimaryAffiliation::

This field provides the name of the identity provider that the user is associated with.

eduPersonScopedAffiliation::

This field identifies the role of the user within the identity provider. Such role can be staff, student, or administrators, etc.

eduPersonEntitlement::

This field contains the access-control attributes. As described in EduPerson specification, this field accepts attributes with multiple values. Consequently, attributes to describe different levels of access control can be applied.

eduPersonTargetedId::

This field contains a unique ID that represents the user, instead of the normal login name. This is to satisfy the requirement of protecting the identity of the user, yet provide means for the service provider to backtrack and report to the identity provider in the case of malicious usage. Usually, this ID can be an encrypted combination of several attributes of the user.

EDIT Specific¶

Depending on the institutions, more fields can be added to further describe the personal attributes of the users. However, the more information is required from the users, the better the security and privacy policy has to be in order to prevent legal complications. For EDIT it might useful to consider the following additional attributes:

editNomenclaturalCode::

Primary nomenclatural code used: ICBN (botany), ICZN (zoology), ICNCP (cultivated plants), ICNB (bacteria), ICTV (viruses)

editTaxonomicFocus::

A higher taxonomic group the user's work is focussed on.

editGeographicFocus::

A geographic region the user's work is focussed on.

Shibbolethising Services¶

In order to make use of the EDIT Shibboleth federation, a shibboleth service provider (SP) needs to be installed. Currently the SP runs under Apache and IIS, so any resource that is available through one of the two web servers can be protected by Shibboleth and applications can read user information (attributes) from the web server environment. As most services can at least run behind Apache somehow (e.g. Tomcat, Axis, CherryPy, PHP), most services can easily be "shibbolethized" by simply reading user metadata from the web server environment and writing appropriate configuration files for the Shibboleth SP.

Integration with non EDIT services¶

Shibboleth is supported by a range of other [mostly academic networks](https://spaces.internet2.edu/display/SHIB/ShibbolethFederations, especially in the library community. [JSTOR":http://www.jstor.org/about/technical/shibboleth_auth.html) , ArtSTOR and OCLC have support for Shibboleth already. "Many applications":https://wiki.internet2.edu/confluence/display/seas/Home like "DSpace and Fedora support Shibboleth out of the box. A simple benefit for all EDIT users would be access to JSTOR, no matter where they are.

ALUKA has been contacted to see whether they support Shibboleth too.

Installation¶

General information is available in

Identity Provider (IdP) Installation¶

IdP Installation for EDIT¶

Shibboleth Identity Provider (IdP) Installation on Debian Etch

General IdP Installation descriptions¶

Service Provider (SP) Installation¶

SP Installation for EDIT¶

General SP Installation descriptions¶

Using Shibboleth¶

Drupal¶

Drupal authentication can be used with Shibboleth based on web server environment variables, particularly REMOTE_USER.

Initially, you just have to protect the path to your Drupal installation on your Shibboleth Service Provider, according to one of these installation descriptions

Next, you can simply install the Webserver Auth Module":http://drupal.org/project/webserver_auth. Currently, this module is not compatible with Drupal 5. But, the version presented "here is working.

In order to shibbolize your Drupal5 installation, just do the following steps:

Download the Webserver Auth module
Extract it into your Drupal5 installation into the modules subdirectory.
Create a file named webserver_auth.info within the Drupal5 subdirectory of the Webserver Auth module (e.g. /var/www/drupal-5.2/modules/webserver_auth/ with a content similar to this:

; $Id: webserver_auth-notes.txt,v 1.1 2007/04/11 21:40:14 wnorthway Exp $
name = Webserver Authentication
description = Allows Drupal to honor the webserver's authentication.
version = "4-7.x-modified"

Modify the file webserver_auth.module within the Drupal5 subdirectory of the Webserver Auth module (e.g. /var/www/drupal-5.2/modules/webserver_auth/webserver_auth.module) as follows:

<?php
// $Id: webserver_auth.module,v 1.13.2.3 2006/03/03 05:08:12 weitzman Exp $

function webserver_auth_init() {
  global $user, $account;

  if ($user->uid) {
    //do nothing because user is already logged into Drupal
  }
  else {
    if ($name = $_SERVER["REMOTE_USER"]) {
      // user is logged into webserver.
      $account->name = $name;
      //modules get to change the user bits before saving. use a global $account to do so.
      // only loaded modules will see this hook
      module_invoke_all("webserver_auth");
      // if we are in bootstrap, load user.module ourselves
      if (!module_exists('user')) {
       drupal_load('module', 'user');
      }
      $shib_mail = $_SERVER["HTTP_SHIB_MAIL"];
      $user_shib = array("name" => $account->name, "pass" => "nopass", "mail" => $shib_mail, "status" => 1);
      // try to log into Drupal. if unsuccessful, use anonymous
      if ($user = user_load($array = $account)) {
          watchdog("user", "Session opened for $user->name.", WATCHDOG_NOTICE);
      $user = user_save($user, array_merge((array)$user, $user_shib));
          watchdog("user", "$user->name($user->mail) updated from Shibboleth attributes.", WATCHDOG_NOTICE);
      user_multiple_role_edit(array($user->uid), 'add_role', 3);
          watchdog("user", "$user->name($user->mail) added to role admin.", WATCHDOG_NOTICE);
      }
      else {
        $user = user_save($account, $user_shib);
        watchdog("user", "new user: $user->name.", WATCHDOG_NOTICE);
        user_multiple_role_edit(array($user->uid), 'add_role', 3);
        watchdog("user", "$user->name($user->mail) added to role admin.", WATCHDOG_NOTICE);
      }
    }
    else {
      // do nothing. user isn't logged into web server
//          $user = drupal_anonymous_user();
//          watchdog("user", "Session opened for Anonymous.", WATCHDOG_NOTICE);
    }
  }
}
?>

Now, we have a basic authentication skeleton for Drupal. Currently, authenticated users must be entered in the Drupal user database by the site administrator. The original Webserver Auth module also supports automatic user registration also. This is currently work in progress, but should be done quite easily.

To shibbolize Drupal and to adopt Drupal to our needs, we will extend this basic authentication module considering the following issues:

automatic Drupal registration of users authenticated with Shibboleth (Done)
- includes automatic mapping of Shibboleth attribute to Drupals user database (Done for name and mail)
automatic update of Drupal's user database entry according to attribute changes on the Shibboleth IdP (Done)
- This should be done on each login at least. (Done)
get the Drupal logout work properly
- actually, users will automatically re-login after being logged out due to the reloading and simultaneous activation of the Webserver Auth module of the Drupal main page.

Trac¶

Trac authentication can be used as well with Shibboleth using the web server environment variable REMOTE_USER.

Initially, you just have to protect the path to your Trac installation on your Shibboleth Service Provider, according to one of these installation descriptions

Client Proxy¶

The idea behind the client proxy is to enable Shibboleth unaware desktop applications to use the Shibboleth security framework as well.

This should be possible installing a local proxy on the Desktop PC, managing the necessary Https-based Shibboleth protocol for that application, and proxying the Http-Protocol through that connection. Thus, the Desktop Application needs to running with the HTTP-protocol (e.g. subversion)

Files (0)

Updated by Lutz Suhrbier almost 16 years ago · 28 revisions

Project

General

Profile

EDIT

Wiki