...

Security Configuration Components

The original 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.  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.

Minor Work Items