Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Shibboleth Goals

The goals of the Shibboleth software are:

  • Allow an organization use their existing user authentication mechanism to access web-based resources even if the resource is not operated by the orgnization. This has the benefits that:
    • A user only needs their "normal" log on credentials, not one per resource.
    • Access resources do not need to manage user credentials.
  • Allow the user's information maintained by their organization to be provided to the resource. This has the benefits that:
    • When a user updates information with their organization all resources receives this new information when the user visits them.
    • Resources do not need to store and maintain data known by the user's organization.
  • Allow the user, or their organization, to control the release of the user's information. This has the benefits that:
    • The user, or their organization, is in control of what information gets released.
    • Resources maintainers do not need to worry about receiving and protecting data they do not require.

Shibboleth Requirements

The Shibboleth Service Provider is a web server module. The supported web servers are Apache's HTTPD, Microsoft's IIS, and Sun's Java System Web Server. Additionally if the resource to be protected is a web application it must be able to receive user data by means of the CGI interface (i.e. HTTP headers).

This Shibboleth Identity Provider is a Java web application and must be deployed in a standard web application container like Apache's Tomcat, Mortbay's Jetty, or JBoss's JBoss Application Server. Additionally the deploying organization must already have an existing way of authenticating users.

  • No labels