Understanding Spring Web-Flow in Apache Fediz - Part 2

After explaining in Part 1 of this topic how the Spring Web-Flow will be initiated I'm going to review the actual flow in some more detail in this post.

The flow registry knows three flows:

1. Federation Validate Request Flow
2. Federation Signin Request Flow
3. Federation Signin Response Flow

The first flow is linked to the fediz-idp/federation URL within the idp-servlet.xml file which is the usual entry point for the IDP. The two other flows are sub-flows which will be executed from within the first flow.

<webflow:flow-registry id="flowRegistry" flow-builder-services="builder">
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation" />
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation/up" />
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation/krb" />
    <webflow:flow-location path="/WEB-INF/flows/federation-validate-request.xml" id="federation/clientcert" />
    <webflow:flow-location path="/WEB-INF/flows/federation-signin-request.xml" id="signinRequest" />
    <webflow:flow-location path="/WEB-INF/flows/federation-signin-response.xml" id="signinResponse" />
</webflow:flow-registry>

Validate Request Flow

The main federation flow can be customized within the WEB-INF/flows/federation-validate-request.xml file. The standard flow looks like this:

Any given request send to the fediz-idp/federation URL will be processed by this flow.
If it is a logout action the logout process will be triggered. Otherwise it could be a WS-Federation signin action triggering the flow in the middle or a SAML Response from a 3rd Party IDP according to SAML Web Browser SSO Profile.

The bold line shows a common scenario when the user was redirected from a RP application with an existing session at the IDP and therefor reusing a cached SAML token to receive a new SAML token applicable for the RP.

Signin Request Flow

The signin request flow can be customized within the WEB-INF/flows/federation-signin-request.xml file. The standard flow looks like this:

At first the home realm discovery will take place. Then the IDP validates if he is responsible for the users home realm himself or if the user is managed by another 3rd party IDP. In any case it will be checked if the user has already a valid session token. If this is the case, the user can receive a new SAML token for the RP. If not, the user first needs to login to the local/remote IDP.

The HomeRealm Discovery is not a separate flow within the federation-singin-request flow, but shown here for a better understanding of how the discovery works. The result of the HRDS can be null. In that case the federation-singin-request flow will continue by providing a selection view for the user.

The above flow is used in Apache Fediz since version 1.3.0. Before that HRDS based on Spring EL was not implemented and the flow looked like the diagram below.

Signin Response Flow

The signin response flow can be customized within the WEB-INF/flows/federation-signin-response.xml file. The standard flow looks like this:

When receiving a token from a trusted 3rd party IDP, this token will be validated and possibly cached, before it will be used to receive a SAML token applicable to the RP.