...
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.
...
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.
...
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's.
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:
...
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.
...
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.