Page tree
Skip to end of metadata
Go to start of metadata

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. InitializeRelyingPartyContextFromSAMLPeer
  3. CheckMandatoryIssuer
    • do we need this? thinking this just falls out of RelyingParty resolution/selection
  4. SelectRelyingPartyConfiguration
  5. SelectProfileConfiguration
  6. 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. 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
  2. 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
  3. 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
  2. InitializeRequestedPrincipalContext

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

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
  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. EncodeMessage
    • encode the outbound Response
    • encoder obtained from factory that uses injected binding descriptors to lookup bean ID based on binding in outbound context

 

  • No labels