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. Example profiles would be SAML 1 attribute queries, SAML 2 SSO requests, etc.

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:

The profile configurations indicate whether a particular protocol/profile is enabled for use by the relying party, and any special configuration options for that profile. Profile configurations also carry a SecurityConfiguration that supplies relevant security settings such as algorithms, credentials, and so forth, though these are rarely used directly, but rather as input to a more complex derivation process (docs TBD).

By convention, the resolution of the appropriate RPC to use for a request is represented by attaching a net.shibboleth.idp.profile.context.RelyingPartyContext child context to the ProfileRequestContext. Both the RPC and the specific profile configuration in effect are captured by that context, along with information about the identity of the relying party and whether that identity was verified or not.

Relying Party Configuration Resolver

The IdP contains a service responsible for selecting the appropriate RPC for a given request, the RelyingPartyConfigurationResolver. Because it's a service, the underlying implementation is fully abstracted from the system and is pluggable.

The default implementation relies on a reloadable configuration resource and just iterates through an ordered list of registered RPC objects, 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 two special RPCs: a default "verified" one to apply in the absence of a more specific rule, and an "unverified" one to apply in the event that the identity of the relying party can't be verified, in a fashion that depends on the profile used (in the case of SAML, a RP can only be verified if metadata is provided for it).

Profile Intercepts

One of the challenges in implementing the profile behavior as webflows was in establishing a mechanism for extension that didn't require copying or editing the internal flow definition files, making upgrades a difficult proposition for anybody that had extended them. Any given change becomes rather simple and small in terms of effort, but incorporating the changes can be complex.

While not every change can be easily accomodated, a large number of use cases are enabled by providing a set of well-defined "hook points" for branching control to user-supplied subflows that can alter the state of the request, or prevent a request from completing outright. The hooking subflow is called an "intercept", and there are three main hook points during which any number of intercepts can be configured:

When feasible, all three hooks are provided in any given profile flow, although the middle hook only applies to more "traditional" SSO-oriented profiles that perform user authentication. Most often, it's that middle hook that is of interest to a deployer, and a number of useful example intercepts are provided, such as attribute release consent and usage terms, coarse-grained authorization, and expiring password notification.

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 as it's mostly internal documentation and is not required to extend the IdP in most cases.