The primary "API" of the IdP is the support for various standard (or standardized) federation protocols like SAML and CAS. Most interactions with the IdP are in the form of requests using those protocols or request to a few internal administrative functions. A summary of the supported protocol interfaces can be found here.
The profile workflows are built using Spring Web Flow, so it's important to understand that technology to make sense out of most of the code. All of the "top level" flows in the system implement one of the supported protocol interfaces, which are referred to as "profiles", a term used in SAML for a unit of interoperability that supports a particular function.
Within the top level profile flows, various subflows are run that carry out reusable sequences of tasks like authentication. These subflows are generally described in their own sections of the top level design and are designed to be composable with any profile flows that need to use them, by defining their own conventions for inputs and outputs.
Relying Party and Profile Configuration
As described in the GeneralArchitecture topic, the root of the context tree for any of the profile flows is the ProfileRequestContext class. Beyond that commonality, all of the "typical" federation profiles have a common approach to their configuration and how its exposed in the context tree.
For consistency with V2, and also because it works reasonably well as a configuration model, V3 maintains the idea of a "relying party" configuration as a container for one or more "profile configurations".
A RelyingPartyConfiguration (RPC) is a set of configuration options that apply to a given relying party. Every RPC contains, at least:
- a unique identifier that is used mostly for logging purposes; it doesn't necessarily correspond to any actual "name" of the RP
- a predicate that determines if the RPC applies for a given request
- a set of profile configurations
The profile configurations indicate whether a particular communication profile is enabled for use with the relying party and any special configuration options for that profile. Example communication profiles would be SAML 1 attribute queries, SAML 2 SSO requests, etc.
Profile configurations also carry a SecurityConfiguration that supply relevent security settings such as algorithms, credentials, and so forth.
Relying Party Configuration Resolver
The IdP component responsible for keeping track of, and selecting the appropriate, RPC for a given request is the Relying Party Configuration Resolver.
The RPC for a request is selected by iterating through an ordered list of registered RPCs and evaluating the current ProfileRequestContext against the RPC's predicate. The first RPC with a predicate to return an affirmative result is the RPC that's used for the request.
In addition, the resolver stores a special RPC that is used when the IdP deems a particular requester to be "anonymous". This usually occurs when the request does not identify the requester or the identity can not be verified.
Profile Design Documentation
The following describes the flow for each profile including the steps that make it up and what they do. Most of it is empty or out of date at this point.