2013-04-21-22

Owned by Scott Cantor
Jul 15, 2013
3 min read

Summary Notes from Brent/Scott Meeting in DC

General Design

Discussion on how to deal with the use of generic contexts vs. protocol- or subsystem-specific contexts.

We should use actions in the SWF to bridge/translate between specific and generic or vice versa, so that it's explicit. This is a replacement for the "view" concept we discussed in Columbus. So there would be actions before and after invoking a subsystem to deal with the inputs and outputs of a process.

Subsystems should only write to contexts in their own subtree, unless we agree on common contexts at the top level.

Authentication / Session Design

Discussion based on strawman design in the wiki.

Refactor so that AuthenticationContext is only about the running authentication subsystem, and doesn't expose historical or emergent identity info.

Move identity information into a "SubjectContext".

Model workflow output as AuthenticationEvent (current class)

Session layer will store AuthenticationEvents

Expose identity and AuthenticationEvents via a top-level SubjectContext to be used by multiple subsystems

Session layer needs to support pluggable serialization for Java Subjects

Walkthrough of SWF for SAML 1/2 Browser SSO

We did a start to finish walk through the entire chain of processing for a request to map it to existing design elements, identify actions needed, and identify design gaps.

Inbound Message Processing

Action: InitializeProfileRequestContext (would be omitted if we use injection of profile context into actions)

Action: MessageDecoder

  • inject concrete Decoder class into action
  • inject HttpServletRequest into Decoder
  • action populates InboundMessageContext slot on PRC
  • extraction of message and population of BindingContext

Action: MessageHandler

  • chains of handlers are defined as beans
  • action step is resolving which chains to run, maybe turn this into a DynamicChainMessageHandler
  • runs Handler against InboundMessageContext slot on PRC

Handlers:

  • population of MessageContext subcontexts, SAML specific info
  • any actions that require only that info (plus maybe other shared components, like replay cache) should be handlers
  • includes establishing relying party identity
  • includes existing security policy rules

Try to reach state where webflows start with MessageDecoder, MessageHandler actions uniformly across flows.

Anything that can be a handler is a handler.

Profile Actions "Proper"

Action: Populate relying party config

  • can be byproduct of handler chain resolution and it can stuff it into the context tree by walking up from MessageContext to parent
  • populates if not already populated

Action: Establish self identity

Action: Endpoint Checking

  • store response endpoint info in EndpointContext under PRC

Action: NameIDPolicy checking

Action: Resolve SAML Subject in AuthnRequest into principal

  • AuthnRequestContext

Action: Resolve security configuration for profile

  • e.g. Encryption settings, encryption key to use
  • SAMLSigningContext
  • SAMLEncryptionContext
Session Behavior

Action: Retrieve user session and populate SessionContext

Action: Decide if session's active authentication events can fulfill request

  • If yes, skip authentication process, and populate SubjectContext with user identity and authentication information
  • If no, run action to decide workflow to execute:
    • potential workflows
    • request parameters
    • defaults based on relying party
    • possibly user identity (meaning a UI to collect it)

??? How do we actually cause the workflow with the selected ID to run via SWF?

Authentication Workflow

Stuff happens.

Report results back into CompletedWorkflowContext

  • errors would be signaled via Events per usual
  • need to make sure EventContext processing can handle richer data (e.g. map)
Profile

Action: Produce SubjectContext out of current state of PRC

  • includes producing normalized identifier

Action: Compare normalized ID against AuthnRequestContext identifier from Subject

Session Behavior

Action: Evaluate SubjectContext against SessionContext

  • detects user identity switch
  • allows for erroring out or flushing session or...

Action: Create or update Session based on PRC

Profile

Action: Resolve Attributes

  • maybe have the results attached to SubjectContext

Action: Filter Attributes

  • maybe have a FilteringContext, copy attributes from and to SubjectContext

Action: Build Subject / NameID

Action: Encrypt NameID

Action: Build SubjectConfirmation(s)

Action: Encode SAML Attributes

Action: Encrypt SAML Attributes

Action: Build AuthnStatement

Session Behavior

Action: Index session by NameID / SessionIndex

Profile

Action: Build AttributeStatement

Action: Build Conditions (probably multiple)

Action: Build Assertion

Action: Sign Assertion

Action: Encrypt Assertion

Action: Build Response

  • builds OutboundMessageContext

Action: Build context(s) for the output pipeline

  • BindingContext
  • bindingURI to use
  • RelayState
  • EndpointContext
  • ArtifactContext
  • SAMLSigningContext
Error Handling

Should Exceptions and Events have a rational difference/distinction in the web flows?

How would a generic SWF for handling errors know what flow action raised the error?

  • Have adaptor create PreviousEvent around RequestContext.getCurrentEvent() (if that works)

Action: Display page to user

Action: Build SAML Response with an error status

Redundant action that prepares outbound pipeline context(s) if not done

Message Pipeline

Action: Run another resolved handler chain

  • sets Destination
  • signs Response

Action: Run MessageEncoder (maybe have Spring wire it based on bindingURI in context)

  • maybe inject OutboundMessageContext