| Table of Contents | ||
|---|---|---|
|
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).
...
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.
...
Use of Spring and Web Flow
...
Some general design principles:
Major services within the IdP typically will rely on a specific context type as the root of a subtree that is used for input to the service and for communicating results back out. For example, the attribute resolver component relies on an AttributeResolutionContext.
Most of the time, services only read or modify information within the subtree they are defined to operate on. The exceptions may be certain well-defined context types that are standardized across services. An example would be a SessionContext that makes a subject's session available. Otherwise, specialized actions exist to move information from service-specific subtrees into other subtrees or into more generic contexts.
Protocol-specific actions such as code that processes SAML messages will typically read and write contexts designed to carry information specific to a given protocol. When services must operate on information generically, actions are provided to translate the information into generic form so that the boundary between protocol-specific parts of a flow and generic parts is respected. This facilitates the use of "subflows" to capture reusable sets of actions across multiple protocols.