The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

IdPHLA

Owned by Former user (Deleted)
Last updated: Jan 23, 2009 by Former user (Deleted)Version comment
3 min read

High Level Identity Provider Architecture

Overview

The Shibboleth Identity Provider, version 2, is a Java web application composed of fairly loosely coupled components. The components are loaded, managed, and inter-connected by Spring. The highest, most coarse grained, components within the IdP are referred to as services. Services are then built up of smaller components. Services may use each other. Components within a service may use each other but may not use components from another service. The following diagram attempts to show this.

Services

Services within the IdP are defined in the service.xml file. Each service has its own Spring application context. This means that all Spring beans, referred to as components in the block diagram above, are isolated from the beans load by another service. In addition, most of the services shipping with the IdP allow for configuration reloading. This is done by creating a new application context, loading the new configuration in, and then swapping out the old config for the new config.

Attribute Resolver Service

This service is responsible for retrieving attributes from a data store and then combining, transforming, or otherwise mutating that data into a set of attributes about a user. The usual intent is that all or some of these attributes would be sent back to the IdP client.
Read more >>

Attribute Filter Service

This service filters a collected set of attributes based on a loaded set of policies. These policies reflect which attributes and attribute values a client may retrieve.
Read more >>

SAML 1 Attribute Authority Service

This service, which relies on an attribute resolver service and optionally a filter service, takes a collection of attributes and encodes them into a SAML 1 attribute statement. In addition, if the requester's SAML metadata contains information about which attributes it needs or wants, the service will also perform a filtering function so that only those attributes are released. If either the filter service or the attribute information in the metadata is not given, then those filtering steps are simply skipped.
Read more >>

SAML 2 Attribute Authority Service

This service is nearly identical to the SAML 1 Attribute Authority, except that it produces SAML 2 attribute statements and also offers a third filtering pass based on attributes requested within the SAML 2 attribute request.
Read more >>

Relying Party Configuration Service

This service is responsible for managing the configurations for various relying parties or groups of relying parties. This includes the default and anonymous relying party configurations. The relying party configurations also include the configurations for the communication profiles supported by the IdP.
Read more >>

Handler Manager Service

This service manages the various IdP endpoints that may receive messages. There is one endpoint per incoming binding. Each endpoint may support multiple outgoing bindings. This service also holds the configuration for the error and login handler endpoints which are used internally by the IdP.
Read more >>

Servlet Context Attribute Exporter Service

This service does not have an associated Spring application context or any associated components. Instead it simply binds other services into the Servlet context so that they may be retrieved from Servlets, filters, and JSP pages.