The OpenSAML V3 software has reached its End of Life and is no longer supported. This space is available for historical purposes only.

Going forward, a single wiki space will be maintained for future information about all versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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.

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) 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'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

Minor Work Items

 

 

 

  • No labels