<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 5/11/14 8:36 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF958FB6.4E030%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
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. <br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:CF958FB6.4E030%25cantor.2@osu.edu" type="cite">
<pre wrap="">
The encryption parameter resolver isn't working for me yet either, but I
haven't dug into that fully yet.
</pre>
</blockquote>
<br>
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....). <br>
<br>
I'll answer your other non-list note here since it's relevant:<br>
<br>
<br>
Scott said:<br>
<blockquote type="cite">Subject: Do I pull encryption keys from the
metadata, or does the EncryptionParamResolver?<br>
</blockquote>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
<br>
</body>
</html>