Security defaults

[Cantor, Scott]

On 5/12/14, 12:52 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:

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

I was imagining we'd probably adopt the same blacklist we use in the SP
right now as a starting point, but it doesn't affect the code much so I
haven't worried about it.

I am assuming we would default to SHA-256 (with RSA and ECDSA) as the
primary algorithms for signing. That seems to be the consensus expectation.

The default I used on the encryption side were more for testing, I don't
obviously expect to use the non-widely supported stuff by default.

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

No, I wasn't, so that's my mistake. I'll revise. I was assuming I'd pass
in the role, but I can do either/both.

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

Yes, I can just do both in the action and then whether the resolver does
will be ok.

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

Right, I'll correct them today. If you want to use the testbed to evaluate
the resolvers in the face of actual config changes, you can do that once I
correct things with the unit tests or the testbed menu.

-- Scott