Page Comparison

...

1. Retrieve and validate a subject's session, if any (if configured to do so), to establish any active flows.

2. Filter potential/configured flows by any passive/forced requirements, as well as browser/non-browser compatibility, as required.

3. Is specific custom Principal support requested or indicated as a default?

   1. If yes, choose the first potential flow compatible with the request and execute it (or if it's already active, reuse it). An option is provided to prioritize active results over inactive flows (it should be noted that this behavior is not SAML compliant).

   2. If no, check for a currently active result and reuse it. Otherwise select a potential flow and execute it.

4. To reuse a result, its last activity time is updated and the result is recorded/copied to the AuthenticationContext. No "attempted flow" is recorded.

5. To execute a flow:

   1. Record it as the attempted flow within the AuthenticationContext.

   2. Branch to it.

   3. On success:

      1. An AuthenticationResult is produced and set into the AuthenticationContext.

      2. A SubjectCanonicalizationContext is created containing the Subject from the AuthenticationResult, and control passes to a SubjectCanonicalization subflow. Failure here would lead to an overall failure of the authentication flow (as in d. below).

      3. If the identity has switched (as compared to the active session), any existing session is invalidated and the AuthenticationContext and SessionContext objects are cleaned up to reflect this.

      4. Assuming success, the canonical principal name is copied into the AuthenticationResult.

   4. On failure, return an error. This error may or may not eventually be sent back to the relying party, that's outside the scope of the authentication process.

6. To complete the authentication process successfully, a SubjectContext is created around information copied from the AuthenticationContext.

7. Optionally a session is created or updated with the modified or new AuthenticationResult to enable future SSO.

...

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.

    <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}" />

...

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.

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

...

The following events worthy of special note may occur as a result of invoking the subsystem:

Various other events signifying more low-level error conditions may also occur.

...