Development Progress
DRAFT
Page to keep tabs on the work that’s been done pending using Jira to start tracking individual work items.
SP project converted to an IdP plugin runnable in the testbed, also a SAML plugin adding the SAML protocol support.
A functional “probably not too far off the final proposal” AgentResolver service is built with some config samples for wiring up Agents, Applications, and the RelyingParty/Profile beans into them.
An abstract SP flow is built that handles secret-based agent authentication via HTTP Basic-Auth supporting secrets attached via Spring and our various password CredentialValidators, mostly untested except for the Spring case.
Java session is used to cache record of authentication for fast reuse.
Agents can specify “basic” or null authentication methods, the latter skipping all of the auth logic but still doing address check.
Decoding and Encoding of request and response DDF objects is done, bypassing the MessageContext model in order to prevent the overlap later to use those for SSO protocol messages.
Some error handling mocked up and tested that returns any error event in a simple DDF structure to the agent in a “result“ member.
A ping flow (inheriting from the abstract SP flow) with a dummy action that adds the epoch to a long field in the output.
curl -i -k -b ~/Desktop/cookiejar.txt -c ~/Desktop/cookiejar.txt -u sp.example.org:foo https://localhost/idp/profile/sp/ping
A parse-request-map flow to parse the RequestMap element for an agent. An updated schema and namespace that covers most, but not all, of the old RequestMap syntax is being used. Once the specific supported options settle we’ll change that to reflect current practice.
curl -k -X POST -H "Content-Type: text/plain" --data-binary @sp-server-impl/src/test/resources/net/shibboleth/sp/config/impl/example-map.ddf -u sp.example.org:foo https://localhost/idp/profile/sp/parse-request-map
Notably I don’t know how sensitive this will be to non-binary commands. ASCII probably works since the input data is all ASCII already.
The XML itself should be ok in any valid XML encoding, ASCII or UTF-8 of course being the norm.
A storage flow to perform remoted StorageService operations on behalf of the agent. Contexts are auto-qualified by the agent ID to prevent overlap.
A sealer flow to peform encrypt/decrypt operations using a DataSealer. Data is auto-qualified by the agent ID to prevent misuse of data.
A session initiator flow to drive an extensible set of subflows in Application-controlled order to generate a login request for an agent to send back to the user agent.
A SAML 2.0 POC session-initiator subflow reusing “most” of the logic from the IdP’s proxying support and generic function for signing, encryption, and message encoding. Only one minor OpenSAML addition required so far to allow metadata to be sourced via the active Application interface instead of statically injected.