Summary Notes from Brent/Scott Meeting in DC
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)
- inject concrete Decoder class into action
- inject HttpServletRequest into Decoder
- action populates InboundMessageContext slot on PRC
- extraction of message and population of BindingContext
- 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
- 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
Action: Resolve security configuration for profile
- e.g. Encryption settings, encryption key to use
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?
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)
Action: Produce SubjectContext out of current state of PRC
- includes producing normalized identifier
Action: Compare normalized ID against AuthnRequestContext identifier from Subject
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
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
Action: Index session by NameID / SessionIndex
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
- bindingURI to use
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
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