Security defaults

[Brent Putman]

On 5/11/14 8:36 PM, Cantor, Scott wrote:
>
> To get the signing actions to work, I had to actually populate signing,
> digest, and c14n algorithms in the config file, there don't appear to be
> any defaults coming from OpenSAML at this point. I don't know if that's
> the eventual state of things or not.

Right, they aren't being populated yet but they will be.  The skeleton
for that is in DefaultSecurityBootstrap (from memory, may have that name
slightly off), where it was also in v2, but I TODO'ed some of that
because the config interfaces weren't finalized at the time. 

The main question at this point is to decide what the OpenSAML-level
defaults should actually be, e.g. do we favor SHA-256 over SHA-1 at this
level, etc.  I think I also TODO'ed populating any whitelist/blacklist
values, e.g. should we blacklist MD5 algos by default? (Remember that
higher order precedence configs may or may not be merged with lower
order ones, based on a config flag.)  Maybe we can discuss in this
thread, or in another one.



>
> The encryption parameter resolver isn't working for me yet either, but I
> haven't dug into that fully yet.

As I mentioned Friday, that is the one that I haven't tested yet. :-) I
plan to work on testing that today, and also some internal refactoring
(if other work doesn't get in the way, I seem to have some semi-crisis
emails in my inbox.  Love Mondays....). 

I'll answer your other non-list note here since it's relevant:


Scott said:
> Subject: Do I pull encryption keys from the metadata, or does the
> EncryptionParamResolver?
> See subject. I was assuming I'd pass the metadata/role in via
> RoleDescriptorCriterion and it would pull the key(s) to use from the
> metadata and pass them back, but it looks like it's expecting me to
> populate the KeyEncryptionCredential slot in the configuration.
>
> Is that just TBD, or is that by design and I need to add that code to the
> IdP?
>
>

First off, are you looking at and using the SAML-aware subclass?  It's
in saml-impl IIRC, I believe in the saml.security package.  That uses a
MetadataCredentialResolver to actually resolve the credentials, based on
the traditional entityID, etc.  So you'd pass in an EntityIDCriterion.

The thing that we discussed briefly a few calls ago was whether that
could be enhanced to also support a mode where it takes a
RoleDescriptorCriterion instead and just extracts the creds from it
directly.  I'll look at that in the next day or two as well.  If that
works, then you could just pass the role in by value, rather than
passing the entityID and having the MCR lookup the creds as in the past.

And so no, you are not required to populate anything there in the config
slots.  That support is just there to support the non-SAML cases (or at
least non-SAML-metadata cases).

Btw, same goes for signing: there is a SAML-aware signing params
resolver which uses the algorithm support extensions to augment the
signing and digest algorithm selection.  Make sure you are using that
one since that's where we get the metadata-driven algorithm agility.


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