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