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 by adding to POM (more modules will be needed later as things get built out):

    <!-- For SP testing. --> <dependency> <groupId>net.shibboleth.sp</groupId> <artifactId>sp-conf-impl</artifactId> <version>0.0.1-SNAPSHOT</version> <scope>runtime</scope> </dependency> <dependency> <groupId>net.shibboleth.sp</groupId> <artifactId>sp-server-api</artifactId> <version>0.0.1-SNAPSHOT</version> <scope>runtime</scope> </dependency> <dependency> <groupId>net.shibboleth.sp</groupId> <artifactId>sp-server-impl</artifactId> <version>0.0.1-SNAPSHOT</version> <scope>runtime</scope> </dependency>
  • 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.

  • 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.