SAML 1 /2 SSO

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

MessageDecoder action
	inject concrete Decoder class into action
		inject HttpServletRequest into Decoder
	action populates InboundMessageContext slot on PRC
	extraction of message and population of BindingContext
	
MessageHandler action
	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 handler
	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

------

First step of "actions" proper is to 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 to establish self identity

Endpoint checking
	- store response endpoint info in EndpointContext under PRC

NameIDPolicy checking

Action to resolve SAML Subject in AuthnRequest into principal
	- AuthnRequestContext

Resolve security configuration for profile
	- e.g. Encryption settings, encryption key to use
	- SAMLSigningContext
	- SAMLEncryptionContext


----- Session Behavior -----

Action to retrieve user session and populate SessionContext

Action to decide if session's active workflows 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?

------ 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)
------

Action to produce SubjectContext out of current state of PRC
	- includes producing normalized identifier

Action to compare normalized ID against AuthnRequestContext identifier from Subject

------ Session Behavior -------

Action to evaluate SubjectContext against SessionContext
	- allows for erroring out or flushing session or...

Action to create or update Session based on PRC

------

Action to resolve attributes
	- Maybe have the results attached to SubjectContext

Action to filter attributes
	- Maybe have a FilteringContext, copy attributes from and to SubjectContext

Action to build subject / NameID

Action to encrypt NameID

Action to build SubjectConfirmation(s)

Action to encode SAML Attributes

Action to encrypt SAML Attributes

Action to build authn statement

------ Session Behavior ------

Action to index session by NameID / SessionIndex

------

Action to build attribute statement

Action to build conditions (probably multiple)

Action to build assertion

Action to sign assertion

Action to encrypt assertion

Action to build response
	- builds OutboundMessageContext

Action to 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?

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

Action to display page to user

Action to build SAML response with an error status

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

-------

------- Message Pipeline -------

Action to run another resolved handler chain

	- sets Destination
	- signs Response

Action to run encoder (maybe have Spring wire it based on bindingURI in context)
	- maybe inject OutboundMessageContext