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