...
This particular use of subject canonicalization (or c14n) is referred to as post-login c14n and the input is an instance of a Java Subject, which is a fairly open-ended object that can contain any number of custom Principal objects and collections of public and/or private credentials. The IdP generally doesn't make much use of the credential collections, but does populate the Principal collection and uses that heavily.
...
Lastly, V4.1 and above include another hook that can be used to plug in Java code to perform customization of the Java Subject by a flow before the c14n step occurs. The advantage of this hook is that it's easier to write that bit of Java code and have it produce, for example, a UsernamePrincipal, than to create a new c14n flow from scratch. This hook is usable by defining a bean with the signature BiConsumer<ProfileRequestContext,Subject>, and identifying it in conf/authn/authn.properties with a property of the form idp.authn.<flow>.subjectDecorator
Advanced Topics
Expand | ||
---|---|---|
| ||
V4.3 includes a feature allowing revocation of existing authentication results, which is our implementation of “administrative logout”, the ability of somebody who isn’t the subject to “log a subject out of the IdP” for administrative reasons. See the AdministrativeLogoutConfiguration topic. |
Expand | ||
---|---|---|
| ||
The IdP includes support for login methods that rely on another IdP to actually authenticate the subject, with the results used to produce the eventual responses to the proxying IdP's own services. This is a common feature of most other SAML software but is newer to Shibboleth. There are a number of different low-level features included to better support this use case as well as to ensure that the default behavior aligns to the SAML 2.0 standard, which includes a number of precise rules for proxying and for limiting and even preventing proxying behavior.
As a rule, the IdP doesn't explicitly assume that a given login flow is or isn't a form of proxy authentication. It defaults to certain assumptions but relies on the deployer to tell it when proxying is involved by adjusting properties (in V4.1 via authn/authn.properties), or by editing XML (in V4.0 on the beans defined in authn//general-authn.xml). The topic of Proxying goes a fair bit beyond authentication considerations, but some of the considerations are summarized here. The rest are mostly in the areas of SubjectCanonicalizationConfiguration, AttributeResolverConfiguration, and AttributeFilterConfiguration. IdP DiscoveryWhen proxying, the IdP now supports calling out to a standardized discovery service. In V4.0, or upgraded systems that continue to rely on the legacy conf/authn/general-authn.xml file to configure login flow behavior, discovery can be enabled for login flows designed to allow for proxying by enabling the In V4.1+, discovery can be enabled for login flows designed to allow for proxying by enabling the corresponding flow-specific "discoveryRequired" property in conf/authn/authn.properties and setting the idp.authn.discoveryURL property to the location of the discovery service. A successful discovery result will make the value returned available via AuthenticationContext.getAuthenticatingAuthority() and will be automatically used by login flows designed to take advantage of it. ScopingAnother point of policy is honoring the Forced AuthenticationAnother assumption the system makes is that a request asking for forced authentication (the Authentication Type MappingFinally, a potentially complex issue arises when it comes to passing SAML
In both cases:
This is hopefully sufficient for most basic proxying scenarios, and is adapatable to all supported protocols now and in the future. Note that this does not currently extend to the practice of expressing this information using SAML Attributes. This overlaps with the function of the |
...
Expand | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
Beans related to general authentication configuration follow:
|
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
The following beans are used to configure IdP Discovery when proxying.
|
Expand | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
The following beans are used to configure comparison rules for custom Principals to support rules for login flow selection when requests specify particular methods, as described in AuthenticationFlowSelection.
|
...