Security parsing - signing and defaults

[Brent Putman]

On 4/25/14 12:18 PM, Rod Widdowson wrote:
>
> •  Thus it becomes acceptable for
> ProfileConfiguration#getSecurityConfiguration() to return null meaning “use
> the default”.

Yes, although it's perhaps more relevant to say that it's (also)
acceptable for any (non-null) SecurityConfiguration returned by that
call to return null on any of the 4 get*Configuration() methods.  It's
not required that, if someone does define a profile
SecurityConfiguration bean, that they have to define all 4 of the
security -Configuration instances in it.  (And of course any of the
properties of those -Configuration) instances may also be null, or empty
for the collections).



> •  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.

Yes.

There is the (slightly non-sensical but possible) case where there is
both a non-null legacy signing credential ref AND a non-null/non-empty:

ProfileConfiguration#getSecurityConfiguration()#getSignatureSigningConfiguration()#getSigningCredentials()


(non-sensical b/c there's really no point in explicitly defining both). 

But if that were the case... You'd probably want to munge the
List<Credential> returned there to include the legacy Credential ref at
the head of the list.  That list itself is immutable, so you'd have to
construct a new list based off of the ref and the immutable list, and
set that back in via the BasicSignatureSigningConfiguration's
setSigningCredentials(...), or whatever.

Or not, and we could just declare that you can't have both. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140425/eaa745c1/attachment.html