Attendees: Bill Thompson, Brent, Daniel, Ian, Marvin Addison, Rod, Scott, Tom
Next call is next Friday.
60 to 90 minute call window.
Probably build on Linux VM.
Next release will ship without JSR-223 scripting engines due to lack of activity in those projects, we will now rely on built-in Java 6 support (Rhino).
Will finish v2 work, then circle back to v3 refactoring.
Taking longer than expected to port spring wiring for the LDAP DataConnector.
Yes, Velocity support is needed in the LDAP DC. Revisit Velocity instantiation later.
Will provide a second impl for template tests.
Release of xmlsectool is downstream of IdP 2.4.0.
AI : Look at JOST-191
IdP 2.4.0 release next Wednesday, coordinating with Brent.
Looking for feedback and decision regarding Spring neutral Web Flow adaptor.
Looking for feedback regarding recently checked-in storage service alternate coding style.
Some issues with v3 Attribute Resolver Action dependencies on relying party configurations, since Context hierarchy is not complete.
Continued work on v3 AACLI.
Spent time working on IdPv3 configuration, installation, jetty, etc.
Had trouble with setting initialization parameter via context deployment descriptor and jetty 8 and 9.
AI : commit maven-plugin version updates to parent poms after 2.4.0 release.
Marvin : shibboleth-idp-ext-cas
CAS work consists of two parts : (1) get a ticket and (2) validate a ticket. Initial work done on the first part, what next ? (Authn)
Authentication will be handled by a yet-to-be-determined subflow.
Integration looking good, persistence manager API satisfactory for ticket store.
How long lived are flows? Short (their output is long lived).
Question about Prinicipal Disambiguation. Scott explained the canonical problem (“one true principal”) and persistence (reversible identifiers in SAML, plus clustering).
What is the cardinality between a session and a principal ? One and only one canonical principal per session. When we see two prinicpals we are forced into doing something (kill the old session, fail the authn). This is a critical thing that V2 got wrong and there are a series of issues in there.
Should we talk about how we capture request state. Protocol neutral? Protocol dependant? Base hierarchy with Protocol specific concrete classes. Maybe Marvin start by defining the contexts he needs and see how that works. OK, but what does SAML need? SAML sample flows capture it, in an oblique way. Can we define base context classes with protocol neutral info (motivated by SAML/CAS)?
Understanding the context tree is the critical, and a lot of it ties back to OpenSAML (because of the profiles), not IdP. Equally Security.
Next step is to for Scott and Marvin to coordinate work on authentication.
AI for Marvin: document Context objects needed for authentication.
AI for Scott : Authentication Actions, Contexts, and flows.
AI for Tom : document current state of Action API, inputs and outputs.
Coding convention : getLdapUrl or getLDAPURL
Tabled for further discussion.