Summing up discussions, action items, decisions, open issues, etc. This is a heavily edited summary of the key takeaways.
| Table of Contents |
|---|
Messaging
Messaging Abstractions Discussion Document
Layering Between IdP and OpenSAML
Chad had been favoring a reduction in OpenSAML responsibility with more in the IdP. General sense of team is to reverse that and consider whether even some profile behavior could be encapsulated in OpenSAML, probably requiring Webflow wrappers to expose lower-layer Java objects as actions. We know this would be valuable to other projects, but we can't afford to do so at the cost of delaying our work.
...
Open: Is factoring down profile behavior feasible if we use Webflow?
Identification of Actors and Context Hierarchy
Extensive discussion of the issues in the V2 code around identifying parties, naming them, and the deep hierarchies.
...
Action: Brent was to investigate the trade-offs between using handlers only, or leaving the decoder and encoder stages as the ends of the flow definition.
Sessions and Identity Normalization
Session Management Discussion Document
Normalizing Identity
The focus of this conversation was around how a logged in user would be identified to different subsystems, and the implications of mixing different authentication mechanisms and potentially reauthentication into the problem.
...
Open: The Canonicalizer interface and the existing PrincipalConnector notion are clearly related, probably becoming one notion.
SSO
Another part of the conversation addressed the relationship between sessions and SSO.
...
Decision: Clearly isolate session read/write operations to flow actions whose only job is to preserve information in sessions, or validate them to populate a specific message context type. SSO would be a matter of enabling flow actions that relied on an identity from a session to populate an authenticated identity context. Non-SSO authentication would create the same context.
Persistence
Persistence (Historical Design Notes / Comments)
This was mostly a summary of the material prepared for the meeting. Most time was spent on the implications of cookie size limits, and then on exhaustive discussion of annotations and Optional<T>, covered in a later topic heading.
...
Decision: Plan for a session cache design that supports separating storage of basic session data from per-SP information required solely for logout, with the hope that logout-omission will enable client-side storage.
Coding Conventions
This side trip was triggered by reviewing some of the storage code prototyped by Scott for the meeting, which he intentionally wrote with extensive use of annotations and the Guava Optional<T> feature to provoke comment.
...
Action: Scott will create a version of the existing code without use of Optional for comparison.
Metadata
SAML Metadata Resolver and Provider Discussion Document, MDA IdP V3 Design Notes
General Design and Credential Caching
We discussed the general question of whether to change the overarching design of the metadata APIs, and how to address the primary deficiencies of the current code.
...
Decision: Preservation of EntitiesDescriptor hierarchy is a non-goal, apart from preserving the functionality of group-based policies via other means.
Resource Abstraction
Some additional time was spent exploring the issues associated with the Resource abstraction in our code vs. the Spring Resource API.
...
Open: Why was the original Resource-based metadata provider deprecated?
Possible Use of Aggregator
The question of whether we can replace existing filtering behavior with a pipeline built with the Metadata Aggregator product was explored. Ian gave an overview of the design and we discussed the implications of a DOM vs. XMLObject model within the code.
...
Decision: The aggregator would need a more comprehensive set of verification features for signature keys to match the IdP's capabilities. [MDA-78]
Open: Scott was concerned about the duplication of code related to signature verification given the dangers in that area.
Security Settings
Security Settings Discussion Document
...
Action: Determine if Bouncy Castle can support AES-GCM encryption interoperably with the SP.
Spring Webflow
We dug into the general structure and configuration of a webflow, how it instantiates the action beans we have to create, and the makeup of the actions and their documentation. The possible uses of annotations were discussed.
...
Action: Look into Eclipse tooling support and visual flow editing.
Spring Configuration
We discussed opinions on current and future configuration strategies related to Spring components, the backward compatibility goal, and what changes might be feasible. Tom outlined his thinking about how to simplify the code supporting the current configuration files.
...
Decision: We need a way to reference standard bean definitions from inside some of the existing resolver plugins, principally the LDAP connector. In general, favor this approach over trying to expose complex features using a custom schema.
...