SignAssertions action not needed ?

[Brent Putman]

On 2/5/14 10:08 PM, Cantor, Scott wrote:
> On 2/5/14, 9:58 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>
> Correct me...
>
> I think what you're saying is that the idea was that the
> SecurityConfiguration.get*Configuration() interfaces are supposed to be
> the static settings applied via the RelyingParty configuration (syntax
> TBD).

If I understand you: yes. The ones at that level essentially define the
RelyingParty/ProfileConfiguration-specific overrides of security-related
defaults defined elsewhere (defined at possibly at multiple levels) - 
unless it's data/component where a default doesn't make sense, in which
case it's just the effective thing for the RP/profile.


>
> Then some kind of Resolver thing takes that interface + metadata + ? and
> produces a -Parameters object that contains the effective settings, and
> that's what should be used to drive
> signing/encryption/validation/decryption.

Exactly. 

>
> If so, my concern is partly in not having to derive those mid-stream
> inside the profile actions (we should do it once, and then hang that off
> the context somewhere),

Yes, like I mentioned in the other note, same idea as we do for metadata
resolution.  Do it once and store.


>  and partly that the code looks kind of backwards
> to me. I would think you'd want the final Parameters exposed via
> interface, because then the resolver can produce an
> implementation-specific object to expose them to the runtime.

That I don't really see.  At that point a -Parameters is literally just
a bean of values.  I mean, it could be an interface, sure, but I don't
really see any use case for multiple impls of -Parameters. 
-Configuration on the other hand is totally unknown.  There could be
many of them throughout a system, and each could be
wired/configured/bootstrapped in a totally different way, hence the
possibility of multiple impls.


> Whereas a lot of the current ProfileConfiguration classes are pretty much
> just simple structure classes with get/set methods, which matches the
> current -Parameters classes.

The impls specifically on the ProfileConfiguration may in fact wind up
as just simple bean impls.  But they're not the only impls or use of
that interface.  I think the latter is the part that is throwing you
off.  A given -Resolver specific to the IdP might consume for example:
1) the RP-specific -Configuration from ProfileConfiguration 2) the
IdP-wide default -Configuration 3) the OpenSAML library default
-Configuration.  4) metadata 5) other stuff TBD.

Or another possible way to do it is that the ProfileConfiguration one is
not a simple bean; it incorporates knowledge of the others in some sort
of delegate-to-parent way and hands back the "closest" level that has a
value for a given property.  Then the -Resolver just combines that one
smart -Configuration with metadata to produce the effective -Parameters.

Or maybe there's another yet another way.  That uncertainty and range of
impl choices is the reason why it is an interface.


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