SAML 1.1 Browser SSO
This is the legacy Shibboleth authentication profile consisting of a proprietary request using an HTTP redirect, and a standard SAML 1.1 Response via POST or Artifact.
Profile Workflow
Preamble / Decode / Configuration Lookup
TBD: This should be largely common to most profiles. Probably will factor this into a parent flow.
InitializeProfileRequestContext
 bootstraps and assign the profile ID to the flow
parse the incoming trigger message
WebFlowMessageHandlerAdaptor to run a predefined MessageHandlerChain to process the inbound MessageContext:
preliminary message handlers applying fixed message policy and performing SAML metadata lookup
InitializeRelyingPartyContextFromSAMLPeer
create a RelyingPartyContext and reference the identity of the SP from the inbound MessageContext via the SAMLPeerEntityContext
CheckMandatoryIssuer
do we need this? thinking this just falls out of RelyingParty resolution/selection
SelectRelyingPartyConfiguration
determine the active RelyingPartyConfiguration for the request and store it in the RelyingPartyContext
check for an enabled ProfileConfiguration in the RelyingPartyConfiguration corresponding to the active profile ID, and store it in the RelyingPartyContext
ResolveInboundSecurityParameters
TBD, action to resolve protocol signature validation and decryption parameters
Request Checking and Preliminaries
TBD: Message oriented policy likely in the handler chain in the preable/decode step
The SAML 1.1 flow doesn't have much actual request content to check.
WebFlowMessageHandlerAdaptor to run a dynamically determined MessageHandlerChain to process the inbound MessageContext:
handlers run potentially based on RP-specific policy configuration
InitializeOutboundMessageContext
creates the outbound message context tree by copying SAML peer information via an indirection through the RelyingPartyContext
includes basic peer identity and metadata looked up earlier
PopulateBindingAndEndpointContexts
creates binding/endpoint contexts in outbound message context tree by feeding the request into endpoint resolution components
this is where metadata and the request and the supported outgoing bindings mix into the endpoint calculation or the dreaded "no peer endpoint available" condition
ResolveOutboundSecurityParameters
TBD, action to resolve outbound protocol signing and encryption parameters
Authentication Handoff
The details of this process are described on the Authentication page, mainly creation of an AuthenticationContext child context.
InitializeAuthenticationContext
creates AuthenticationContext child context, which is left defaulted for SAML 1 requests
InitializeRequestedPrincipalContext
specifies how to do authentication in the default case by creating a RequestedPrincipalContext
handles any profiles that rely on authentication via AuthenticationProfileConfiguration interface
This is followed by the authentication subflow, which handles everything to do with sessions and authentication.
Attribute Resolution
runs the AttributeResolver
note we typically have to do this even if we're not pushing attributes with SSO, because this is where the NameIdentifier for the SAML response will often come from (not sure if we can bypass this, or how we'd know to do that, probably could be a deployer flag)
run the AttributeFilter against the AttributeContext produced in the previous step
results are put back into AttributeContext
Response Generation
The design requires that we build from the outside in (starting with the Response) because the message "in progress" is being stored in the outbound message context.
builds the Response with Success status and adds it to outbound message context
currently also creates BasicMessageMetadataContext by copying data from the response, thinking this belongs in a handler unless something before the outbound chain needs it
correlates Reponse to request if applicable
Assertion Generation
Actual creation of the assertion(s) is handled by a helper method on a support class.
The vast majority of cases we have a single assertion. The actions right now support that feature but it doesn't necessarily need to be exposed.
AddAuthenticationStatementToAssertion
adds AuthenticationStatement using the information from the AuthenticationContext
by default, the method is derived from the first AuthenticationMethodPrincipal in the authenticated Subject
AddAttributeStatementToAssertion
adds the AttributeStatement by encoding everything possible from the AttributeContext
resolves a NameIdentifier to include, creating Subject if necessary
format selection is via a strategy that by default combines SP metadata with profile configuration
AddSubjectConfirmationToSubjects
adds SubjectConfirmation of the specified type, creating Subject if necessary
auto-converts bearer confirmation to the V1 artifact method based on outbound context
AddNotBeforeConditionToAssertions
adds Conditions element via helper or reuses existing element
adds NotBefore restriction unless instructed not to by strategy function injected that reads profile config
AddNotOnOrAfterConditionToAssertions
adds Conditions element via helper or reuses existing element
adds NotOnOrAfter restriction, in SAML 1.1 this is the short lived bearer window for SSO
AddAudienceRestrictionToAssertions
adds Conditions element via helper or reuses existing element
can add to existing restriction or create a new one
audience set is supplied via strategy, computed from profile config plus relying party identity
ResolveProfileSecurityParameters
TBD, action to resolve "body" signing and encryption parameters
probably can create a helper if there's not already one to share code between response signing on outbound handler and this action
Session Update
mostly superfluous (no logout in SAML 1.1) but for completeness
adds an SPSession instance to the active IdPSession if there's one available via a SessionContext
doesn't abort profile on an error
use of action with SAML 1 is generic, no SAML-specific inputs
Post Processing / Encode
TBD: This should be largely common to most profiles. Probably will factor this into a parent flow.
WebFlowMessageHandlerAdaptor to run a MessageHandlerChain to process the outbound MessageContext:
does some post-processing on Response, including setting Recipient attribute and signing
encode the outbound Response
encoder obtained from factory that uses injected binding descriptors to lookup bean ID based on binding in outbound context