...
Contains a reference to the active RelyingPartyConfiguration and ProfileConfiguration, as outlined by ProfileHandling. This is mostly relevant for the user interface, but does allow behavior during authentication to be otherwise tailored by relying party if necessary. The identifier for the RP is directly accessible on the RelyingPartyContext.
...
A login flow is a subflow that is assigned a flow ID that starts with "authn/" and is further defined to the system with a bean of type net.shibboleth.idp.authn.AuthenticationFlowDescriptor, generally by inheriting from shibboleth.AuthenticationFlow.
| Localtabgroup | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| active | true
| -live | ||
|---|---|---|
|
The bean must be added by the deployer to the list in conf/authn/general-authn.xml.
| Note |
|---|
While you may deliver a custom flow in a relatively "drop-in", self-contained jar, you MAY NOT manipulate the state of the IdP at runtime to install the necessary descriptor bean because it is impossible to guarantee that your modification will take place early enough to be seen by other objects in the system. There is no publically supported mechanism prior to V4.1 to extend any of the beans defined inside the "root" web app context, and so you MUST rely on the deployer making the necessary adjustments to define custom flows to the system via the associated type of FlowDescriptor. |
| Localtab-live | ||||
|---|---|---|---|---|
|
Beans of this type are now 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 (see also the V4.0 tab). Simple defining a bean like so in conf/global.xml should work:
| Code Block |
|---|
<bean p:id="authn/MyAuthn" parent="shibboleth.AuthenticationFlow"
p:nonBrowserSupported="true"
p:passiveAuthenticationSupported="true"
p:forcedAuthenticationSupported="true"
p:lifetime="%{idp.authn.defaultLifetime:PT1H}"
p:inactivityTimeout="%{idp.authn.defaultTimeout:PT30M}" /> |
Be sure to use the p:id syntax for identifying the bean, as that is necessary for the auto-wiring to work properly. The example is obviously just that; specific settings will depend on the use case and the behavior of the mechanism. Correct IdP operation depends greatly on some of these flags being set to appropriate values.
It must generally be, further, enabled via the idp.authn.flows property.
...
Flows that need to populate specialized Java Principal types into their resulting Subject may do so but will also need to supply instructions on how to serialize the results into a String for preservation by the session layer.
| Localtabgroup | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| active | true
| -live | ||
|---|---|---|
|
The mechanism described in the V3 AuthenticationConfiguration page for registering custom serializers is supported but was discontinued in V4.1 in favor of a more plugin-friendly design.
| Localtab-live | ||||
|---|---|---|---|---|
|
Custom principal support in V4.1+ requires implementing the PrincipalService interface. Any bean declaration (e.g., in conf/global.xml) that supports this interface will be auto-registered with the system. In most simple cases, if your custom Principal is just a wrapper around a simple String, you can wire up this support as follows:
| Code Block |
|---|
<bean p:id="myprincipal" class="net.shibboleth.idp.authn.principal.GenericPrincipalService"
c:claz="org.example.MyPrincipal">
<constructor-arg name="serializer">
<bean class="net.shibboleth.idp.authn.principal.SimplePrincipalSerializer"
c:claz="org.example.MyPrincipal" c:name="MY" />
</constructor-arg>
</bean> |
For more complex data, more custom code may be needed in place of the simpler serializer, but the GenericPrincipalService class is usually sufficient to define it to the system.
Programming Guide to Using Authentication
...