This page serves as a working space for communicating and hashing out details of ongoing and remaining work related to OpenSAML v3 development.

Major Work Items

Messaging-related Components

Changes in how message processing state - shift from old static context hierarchies to new "emergent" flexible context hierarchy trees - require all code that generates or processes message state to be refactored.

The basic functionality of the SAML encoders and decoders has been refactored at this point. There remain a few minor internal details and rough edges to be finished off.

Remaining work is mostly around refactoring the former SecurityPolicyRule components into the new more general MessageHandler abstraction. This work is fairly mechanical.

There are however some conceptual issues to be worked out as to exactly how and what to represent in the message state. We formerly had overlapping and confusing concepts such as "message issuer", "peer entity" and "relying party", which need to be cleaned up in the new design. Chad had already implemented some changes in this regard in the IdP work. However, we need to reconcile what is there now with what needs to be in the OpenSAML layer for the more general message processing cases. We may need to re-think some of what is there.

I'll also note that Chad believed that some of what was formerly in OpenSAML re: reusable message processing components (e.g. replay detection, message issuance instanct detection), should just be implemented in the IdP and not in OpenSAML, which I don't completely agree with. There is currently some WebFlow actions in the IdP that do these things. My thinking is that perhaps these things should be in OpenSAML and there should in the IdP be a generic Action impl that takes an OpenSAML MessageHandler or MessageHandlerChain. Certainly I think that things like protocol message signature validation should still be implemented in OpenSAML.

The end-goal is basically to get rid of all references and usage of the old org.opensaml.ws.message.MessageContext subclass hierarchies and then delete all these classes.

Metadata Providers

The new metadata support design as discussed with Chad was to split the current monolithic MetadatProvider interface into a 2-part design. As currently defined (subject to revision of course), the primary interface is just a trivial sub-interface of the generic Resolver interface. The current sub-interface is org.opensaml.saml.metadata.MetadataResolver (saml-api module), that takes a CriteriaSet as input and produces EntityDescriptor as output.. There is some informative Javadoc there. This interface makes no assumptions about the source of metadata. Impls that consume a defined "metadata source" (e.g. an XML file retrieved from somewhere defined and known in advance) would take an instance of org.opensaml.saml.metadata.MetadataProvider, which exposes an iteration of EnittyDescriptor.

Support for dynamic or on-demand metadata (not from a pre-defined XML file) would likely be an impl of the MetadataResolver that does not take a MetadataProvider.

There is currently no implementation of any of this. The remaining work is to validate this design and work out the probably many implementation details that will arise. We have also had little discussion on how metadata filtering would work in this design, other than Chad's proposal that filters operate on the DOM level rather than XMLObject.

Possible issues are:

do we use source-specific impls of MetadataProvider as in v2 (e.g. File, HTTP, FileBackedHTTP, etc) and go with a general Resource-based provider? The latter seems best, but also need to work out component responsibilities for things like caching, and reloading behavior

Security Configuration Components

The original v3 thinking was that some component (likely an impl of the Resolver interface) would at some point in a message processing flow produce and store in the context hierarchy instances of classes that held the security-related config info needed for each of the 4 common crypto use cases when processing the message. In xmlsec-api module, package org.opensaml.xmlsec, see interfaces:

DecryptionConfiguration
EncryptionConfiguration
SignatureSigningConfiguration
SignatureValidationConfiguration

I think these are still largely correct as far as content, subject to minor tinkering with crypto detail things.

However, the later thinking re: security config was that we really have 2 sets of security config-related components: 1) one set which is as described above, i.e. the effective properties that will be used at runtime during processing of a given message and 2) configuration components (which may have similar properties as #1) that are used as inputs to the process of producing the effective instances in #1. The process of producing the #1 type components from a combination of the #2 components, along with other inputs such as metadata, would likely be one or possibly many impls of the Resolver interface.

Note: the net.shibboleth.idp.profile.config.SecurityConfiguration currently uses the above interfaces directly, which may or may not be correct. The current interfaces were intended to be more of the #1 effective runtime info components (despite the -Configuration naming convention). At the very least we need to reconcile the "dynamic effective runtime" component notion with the "static configuration" component notion.

There is currently no implementation of any of this, just interfaces. A lot of the remaining work, aside from the split/clone into 2 sets of interfaces, is considering the details of the actual resolution process and the security config resolver impl(s), esp in the IdP, where inputs and selection can be influenced by many things:

OpenSAML and/or IdP defaults
Profile defaults
Relying party-specific defaults
Metadata crypto selection extentions
Statically configured whitelist and/or blacklist

Also need to work out how much of this can and should be pushed down into OpenSAML, and what is really exclusively IdP-layer stuff. In OpenSAML we at a minimum probably need basic impls of one form or another of all these interfaces.

Minor Work Items

Metadata Crypto Extension Support

We need to implement XMLObject providers for supporting the crypto selection extension(s) in SAML metadata.

XMLObject provider cleanup

Unmarshalling
- switch to QName-based handling for attribute names
Namespace support:
- implement deprecations, switch to NamespaceManager for everything

SOAP Client

We need one that works with the new message processing stuff, and that doesn't suck like the old one.

Artifact Resolution

Depends on having the new SOAP client. We never implemented in v2 message decoders that accepted and resolved inbound artifacts, b/c we needed a SOAP client that supported what we needed.