Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Overview

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:

  • 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
  • the identity the IdP should assume in its communication with the RP
  • a collection of of profile configurations implementing the ProfileConfiguration interface

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 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.

  • No labels