Security parsing - signing and defaults
Rod Widdowson
rdw at steadingsoftware.com
Fri Apr 25 12:18:16 EDT 2014
Summary from the chat that Scott, Brent and I had.
• We will introduce a bean file with the IdP Global security
configurations, one per profile)
- This will probably also define the defaults for the ArtifactProfile.
• We will add an interface which extends RelyingPartyConfigurationResolver
with a mechanism which allows lookup of these beans by name.
• This new interface will be what is exported by the
ReloadingRelyingPartyConfigurationResolver – this will allow the IdP code to
collect both the specific RP Security Config and the default and feed that
into OpenSAML
• Thus it becomes acceptable for
ProfileConfiguration#getSecurityConfiguration() to return null meaning “use
the default”.
• The defaultSigning key will be used to set up a SecuirtyConfiguration
with *only* a SignatureSigningConfiguration set in it. This
SignatureSigningConfiguration will *only* have the credential set. The rest
of the code knows/will know how to handle defaults from further on down.
• We will extend the schema to allow:
- Per profile setting of artefact information (attribute)
- Per profile setting of inboundFlowId & outboundFlowId (attributes)
- Inline (or references) Spring Bean syntax injection of a
net.shibboleth.idp.profile.config. SecurityConfiguration
• We will look for and warn on old style configuration (securityPolicyRef…),
just as we currently do for attributeAuthority.
• We will look for and warn on <security:SecurityPolicy> statements.
• I need to track the potential need to have a Role Resolver as well as the
MetadatResolver.
/Rod
More information about the dev
mailing list