| Table of Contents | ||
|---|---|---|
|
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.
...
Configuration is based around 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.
...
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.
...
Authoring and Enabling Intercepts
...
An interceptor is an arbitrary subflow that is assigned a flow ID that starts with "intercept/" and is
...
defined to the system with a bean of type net.shibboleth.idp.profile.interceptor.ProfileInterceptorFlowDescriptor
...
.
...
| title | V4.1 |
|---|
...
Beans of this type are
...
auto-detected at startup and so do not require any special file or containing list to define them in, something that used to be required
...
. Simply defining a bean like so in conf/global.xml
...
will work:
| Code Block |
|---|
<bean p:id="intercept/myflow" parent="shibboleth.InterceptFlow" /> |
Make sure to inherit from this parent, and to use the p:id syntax to identify the bean (necessary for the auto-wiring process to work).
Interceptor webflow definitions must inherit from an abstract flow named "intercept.abstract" by specifying it in the <flow> element's parent attribute. Failure to do so will prevent the system's built-in event and error handling from functioning correctly.
To enable an interceptor, the flow ID suffix (the name after the "intercept/" prefix) must be added into the appropriate list property on the relevant ProfileConfiguration object in conf/relying-party.xml. The properties contain an ordered list of flow IDs representing the flows to execute in a sequence until one fails (results in a non-"proceed" event) or all have run.
...
There is no specific input contract, since profiles vary in their function, but as a general rule, inbound interceptors can assume that the ProfileRequestContext's inbound MessageContext tree is fully populated, and when possible a RelyingPartyContext child context will have been created, along with any contexts needed to drive functions like transport or message authentication.
...
| Digraph |
|---|
node [shape=record] Profile [label="ProfileRequestContext", URL="http://shibboleth.net/cgi-bin/java-opensaml.cgi/org/opensaml/profile/context/ProfileRequestContext"] RelyingParty [label="RelyingPartyContext", URL="http://shibboleth.net/cgi-bin/java-identity-providerprofile.cgi/net/shibboleth/idp/profile/context/RelyingPartyContext"] Attribute [label="AttributeContext", URL="http://shibboleth.net/cgi-bin/java-identity-providerattribute.cgi/net/shibboleth/idp/attribute/context/AttributeContext"] Session [label="SessionContext", URL="http://shibboleth.net/cgi-bin/java-identity-provideridp.cgi/net/shibboleth/idp/session/context/SessionContext"] Authentication [label="AuthenticationContext", URL="http://shibboleth.net/cgi-bin/java-identity-provideridp.cgi/net/shibboleth/idp/authn/context/AuthenticationContext"] Subject [label="SubjectContext", URL="http://shibboleth.net/cgi-bin/java-identity-provideridp.cgi/net/shibboleth/idp/authn/context/SubjectContext"] Profile -> RelyingParty Profile -> Session Profile -> Authentication Profile -> Subject RelyingParty -> Attribute |
...