Page Comparison

...

1. An AuthenticationContext will exist and be populated (e.g. isPassive, isForceAuthn, etc.).
2. A RequestedPrincipalContext may exist and will be populated if present.
3. A called login flow will be present in the collection of available login flows (that is, if a flow is run, it can assume it was supposed to run).
4. If a pre-existing result of a called login flow is present as an active result, it could not have satisfied any RequestedPrincipalContext present, or forced authentication is required. This inference holds because otherwise the previously active result would be used for SSO.
5. There may be intermediate state present in the form of a previously produced AuthenticationResult if a flow is called as part of some higher level orchestration, but flows should generally assume that they are free to act as if no such state exists unless their logic is dependent on recognizing and acting on that state. In other words, if you don't care about intermediate results, you don't have to care about intermediate results.

...

1. If a login flow completes with a "proceed" event, then it MUST satisfy the following requirements:
   1. An AuthenticationResult that represents the desired outcome MUST be set in the AuthenticationContext. It is not strictly required that the result satisfy any RequestedPrincipalContext present, but failure to ensure this will result in an error later.
   2. A SubjectCanonicalizationContext MUST be present below the root context and MUST contain the Subject to canonicalize from the login process (generally this will be from the AuthenticationResult but does not strictly have to be).
   3. Starting with V3.3, the login flow SHOULD run the SubjectCanonicalization master subflow, but it MAY leave that for the authentication master flow. The signal for this is whether the principalName field in the SubjectCanonicalizationContext is populated after the flow completes.
2. If a login flow completes with any other event, it should assume that its outcome will be treated as unsuccessful. Flows may signal specific behavior back to the authentication master flow:
   1. ReselectFlow – tells the master authentication flow to choose another eligible flow to run (i.e., fall through)
   2. Flow ID of another login flow – tells the master authentication flow to run that flow next (see the following section)
   3. Anything Else – authentication will fail and the event will be reflected back as the result of the authentication master flow, to be interpreted by the calling parent flow (signaling a custom event requires that conf/authn/authn-events-flow.xml be modified)

General Considerations for Custom Login Flows

...