Summing up discussions, action items, decisions, open issues, etc. This is a heavily edited summary of the key takeaways.
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.
Decision: Lean toward the original model pushing down everything possible, but not at the cost of a lot of time or complexity.
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.
Decision: Use "Peer" and "Self" to refer to the typical two-party protocol peers. Avoid use of "relying party" term unless the semantics are clear, and don't use it to refer to configuration settings obtained from the current "relying-party" file. Favor behavior-oriented labels, such as "Attribute Recipient" where appropriate.
Decision: Stick with indexing child contexts by the actual Class type for now, rather than creating multi-indexed lookup that would include base or intermediate class types. This means avoiding much inheritance of context types.
Decision: Assume for now that we'll create protocol-specific context types rather than trying to factor out commonality such as "issuer", "issue instance", etc. We may have to duplicate some lower layer components, particularly security processing code, to operate on more than one context type as a result. Favor clarity and explicit coupling of contexts and actions over code reuse for now.
Decision: Avoid outright use of "views" as contexts for the time being in favor of profile actions or message handlers that explicitly copy information to avoid unnecessary dependencies between context types.
Decision: Eliminate any use of IdP metadata within the IdP code (relevant to messaging insofar as we make use of the "LocalEntityMetadata" construct in V2).
Open: How do we best deal with transiting between inbound and outbound message context information? Should the message encoding/decoding layer be operating in the operational contexts rather than the individual message contexts? Can we generalize the encoder/decoder notion into just MessageHandlers that operate on contexts created by the Webflows? Scott still wonders about the creation of transport specific encoder/decoder subtypes.
Open: Not clear yet how best to handle context lookup (via lookup strategy functors, simple class-based lookups, something else?).
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.
Decision: Abandon the current approach in V2 and build a new "disambiguation" component, possibly called a Canonicalizer. This interface would turn a mechanism-specific user identity into a normalized value that can disambiguate different identities within the IdP.
Decision: Non-normalized name forms will be accessible to components with advanced needs, but ordinary access to "the principal name" will be to the normalized form.
Decision: We will need various context types representing different aspects of user identity, such as "an asserted but not authenticated username", an identity found in a valid session, mechanism specific names, the normalized name, and the names to be asserted in federated protocols.
Decision: Behavior of flows if a newly logged in user identity differs from session identity should be configurable.
Open: The exact contexts we need and what to call them is TBD.
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: Avoid any direct dependency on sessions in code that is processing a given request/response. That is, never rely on the session existing in order to complete a flow conversation. (Counterexample: the profile handlers today fetch the authenticated user identity from the session and not from the filled in login context.)
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
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: Move forward with a non-genericized storage API using strings. The exact API may undergo some adjustment to reduce the use of optional parameters and to accomodate specialized data serialization strategies.
Decision: Move to a dedicated storage module (or -api/-impl pair).
Action: Brent/Tom were to finalize and check-in scripts for creating new modules.
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.
Decision: Use of annotations should be limited to documentation aids rather than impacting the code.
Decision: Combining nullability annotations with the Optional syntax seems awkward and duplicative, and we should pick one or the other.
Decision: Adding explicit null checking for non-Optional parameters defeats the purpose of the feature.
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: Stick with a single API abstraction for metadata rather than separate "resolver" and "provider" behavior.
Decision: Convert the existing resolver API to a specialization of the Criterion-based Resolver API.
Decision: Move discovery-centric features like getMetadata() to a specialized subinterface to address the lack of support in some implementations.
Decision: Move caching of credentials resolved from metadata to some form of annotation on the XMLObjects. Unclear at this stage how general to make this, but the notion of attaching arbitrary metadata "notes" to any object was appealing.
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.
Decision: Barring a very surprising conclusion about the HTTP and TLS capabilities of the Spring HTTP resource implementation, we still need our own.
Open: Can we adapt our Resource abstraction to meet Spring's needs? How can we do that without embedding Spring into lower layers of the code? If we isolate the dependency to a dedicated module, is that a problem?
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: We shouldn't architecturally preclude the aggregator notion, but staying with the existing filter design is probably less work right now.
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
We discussed the disposition of particular algorithms and the implications on V3 defaults and features.
Decision: Move to SHA-256 by default for signature digests.
Decision: Add blacklist/whitelist capability.This may entail doing so for the JCE algorithms, Santuario directly, and our own code.
Decision: Add support for blocking small key sizes (e.g., RSA < 2048)
Open: Do we need a context-sensitive blacklisting capability to allow for blocking SHA-1 for signing but not for OEAP Mask Generation use?
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.
Decision: Stick with the built-in webflow configuration language rather than creating a custom syntax.
Decision: Use annotations where possible to document actions.
Action: Scott to look into creating a CSS for turning the annotations into usable information in the javadoc.
Decision: Use a consistent naming convention between our action class and bean definition names.
Open: Are the actions going to be singleton or prototype beans? This has implications on whether context information would be extracted into bean state or acquired within the execution method.
Open: Lot of discussion around the relative size of boilerplate code, lookup of data, checking message context state, etc. vs. actual size of business logic. Unclear to most how we can encapsulate extraction of action inputs apart from inline in the execution method. Not clear how much checking of true preconditions to bake in.
Action: Scott to attempt a decomposition of a profile, probably SAML 1 SSO, into actions complete with annotations and documentation.
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: Strive for compatibility as much as possible (duh).
Decision: Eliminate use of factory beans as much as possible in favor of direct bean configuration via bean definition parsers.
Action: Tom will explore the possible creation of generic bean definition parsers that would handle multiple object types at once. The utopian goal is to have one.
Decision: Avoid creation of new custom schemas until we have a better sense of the necessity (e.g., the built-in property setting syntax is pretty simple).
Open: Need to revise our namespace handling code and entity resolution to fix the mistake we made between namespace and schema location.
Action: Scott to look into revising schemas backward-compatibly to relax ordering constraints in sequences where possible.
Decision: AACLI tool using new resolver and filter is our initial target deliverable.
Action: Tom, Rod to start ASAP.
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.