The Shibboleth IdP V4 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP5 wiki space for current documentation on the supported version.
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