The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
GeneralArchitecture
Overall Architecture
The overall architecture of the IdP is relatively straightforward. An HTTP request comes in to a Request Dispatcher. The dispatcher inspects the request and, based on the request's properties, sends it along to a Profile Handler. A Profile Handler, as its name implies, is designed to handle a particular protocol profile request (e.g., SAML 1 Attribute Query, SAML 2 Single SignOn).
In our particular design, the functions of request dispatch and profile handling are actually implemented by Spring Web Flow, which itself sits on top of the Spring MVC layer. Each request is mapped to a profile flow, which are the top level units of processing in the software.
Each profile flow is composed of a set of actions which perform some part of the overall processing necessary to generate the appropriate response. Requests pass from action to action until the response is complete and returned to the requester. While at the high level, there are "actions" to perform user authentication, attribute resolution, and response signing, the actual implementation of each action is much more fine grained.
When an action is performing its work, it may in turn make calls to one or more of the IdP's services.
Components And Services
The IdP is mostly just a collection of individual bits of code wired together with Spring. Each discrete bit of code is termed a Component. Most components have a unique identifier (mostly used in logging and by Spring). A Component might be something small, like the LDAP authentication action, or something larger, such as the whole attribute resolver.
The example of the attribute resolver also demonstrates the ability for a bunch of smaller components to be composed in to a larger Component. A larger Component that hides the individual components that make it up and also contains configuration logic is known as a Service. Note that components in different services should never communicate with each other. However, components within the same service often communicate, as may two different services. Typically when services need other, one is injected into the other in a declarative fashion using Spring.