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.

1. InitializeProfileRequestContext
   
   •  bootstraps and assign the profile ID to the flow
2. DecodeMessage
   
   • parse the incoming trigger message
3. WebFlowMessageHandlerAdaptor to run a predefined MessageHandlerChain to process the inbound MessageContext:
   
   • preliminary message handlers applying fixed message policy and performing SAML metadata lookup
4. InitializeRelyingPartyContextFromSAMLPeer
   
   • create a RelyingPartyContext and reference the identity of the SP from the inbound MessageContext via the SAMLPeerEntityContext
5. CheckMandatoryIssuer
   
   • do we need this? thinking this just falls out of RelyingParty resolution/selection
6. SelectRelyingPartyConfiguration
   
   • determine the active RelyingPartyConfiguration for the request and store it in the RelyingPartyContext
7. SelectProfileConfiguration
   • check for an enabled ProfileConfiguration in the RelyingPartyConfiguration corresponding to the active profile ID, and store it in the RelyingPartyContext
8. 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.

1. WebFlowMessageHandlerAdaptor to run a dynamically determined MessageHandlerChain to process the inbound MessageContext:
   
   • handlers run potentially based on RP-specific policy configuration
2. 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
3. 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
4. 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.

1. InitializeAuthenticationContext
   
   • creates AuthenticationContext child context, which is left defaulted for SAML 1 requests
2. 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

1. ResolveAttributes
   
   • 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)
2. FilterAttributes
   
   • 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.

1. AddResponseShell
   
   • 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
2. AddInResponseToToResponse
   • 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, and I believe V2 dropped the old V1 option that controlled creation of a separate assertion for attributes. The actions right now support that feature but it doesn't necessarily need to be exposed.

1. AddAuthenticationStatementToAssertion
   
   • adds AuthenticationStatement using the information from the AuthenticationContext
   • by default, the method is derived from the first AuthenticationMethodPrincipal in the authenticated Subject
2. AddAttributeStatementToAssertion
   
   • adds the AttributeStatement by encoding everything possible from the AttributeContext
3. AddNameIdentifierToSubjects
   • resolves a NameIdentifier to include, creating Subject if necessary
   • format selection is via a strategy that by default combines SP metadata with profile configuration
4. AddSubjectConfirmationToSubjects
   • adds SubjectConfirmation of the specified type, creating Subject if necessary
   • auto-converts bearer confirmation to the V1 artifact method based on outbound context
5. 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
6. 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
7. 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
8. ResolveProfileSecurityParameters
   • TBD, action to resolve "body" signing and encryption parameters
9. SignAssertions
   
   • 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

1. UpdateSessionWithSPSession
   
   • 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.

1. WebFlowMessageHandlerAdaptor to run a MessageHandlerChain to process the outbound MessageContext:
   
   • does some post-processing on Response, including setting Recipient attribute and signing
2. EncodeMessage
   
   • encode the outbound Response
   • encoder obtained from factory that uses injected binding descriptors to lookup bean ID based on binding in outbound context