New relying party config

[Cantor, Scott]

On 7/21/15, 7:30 PM, "users on behalf of Michael A Grady" <users-bounces at shibboleth.net on behalf of mgrady at unicon.net> wrote:



>I've been looking more closely at the new v3 relying party config. And I want to be sure I understand the distinction between the settings that the System Profile Defaults section in:
>
>  https://wiki.shibboleth.net/confluence/display/IDP30/RelyingPartyConfiguration
>
>have with the added 'Predicate' string and an 'alwaysFalse' or 'alwaysTrue' type value versus those settings that are just true/false. E.g 
>   signAssertionsPredicate = alwaysFalse  
>     versus something like
>   includeConditionsNotBefore = true

If it says "alwaysTrue/False", it's because the property data type is a Predicate<ProfileRequestContext>, and if it just says true/false, the property type is just a Boolean.

I suppose we could have made all of them predicates for generality, but at some point it starts to be overkill and the relying party overrides themselves trigger based on predicates, so there are a lot of layers at which you can do the same kind of conditional logic.

The ProfileConfiguration interfaces are all public APIs with javadocs. The top of a large hierarchy:


http://shibboleth.net/cgi-bin/java-idp.cgi/net.shibboleth.idp.profile.config.ProfileConfiguration

>I've seen examples just showing p:signAssertions="false", what's the difference between the latter and the form with the Predicate?

I can see that would be confusing, sorry. I included a Spring converter that auto-wires true/false in any Predicate property into Predicates.alwaysTrue() or Predicates.alwaysFalse(). So you can treat any of them as booleans if that's the only requirement, but some of them are technically not and can take more complex beans. Javadoc is really the definitive reference for what you can set.

> And what is the potential value set for those with Predicate, because there is even the example in that section of:
>
>   signResponsesPredicate = if TLS isn't used or port 443 is used

Anything that's predicate-based has a value set of anything that implements Predicate<ProfileRequestContext>.

The ones that say that specifically are defaulting to a class called org.opensaml.profile.logic.NoIntegrityMessageChannelPredicate which you can probably get the jist of by the name. There's a similar one for Confidentiality. That implements a slightly cleaned up version of what V2 used to call "conditional". I don't expect it to be used by anybody explicitly, but it's the default where it's appropriate.

>I'd also like to confirm if I'm reading this documentation correctly. In Shib v2 (at least for SAML2SSO), signResponses was never and signAssertions was always, but it appears that the defaults in v3 have signResponses as true and signAssertions as false. Is that correct?

I was certain we had changed the defaults in V2 to sign responses. I'm fairly confused, I'm going to have to go back and look. Either way, the V3 defaults are the correct ones. XML Encryption's break demands that one never encrypts without signing the ciphertext, so it's not good to sign the assertion only. Doesn't help unless the SP is configured to enforce that, and nobody's is, but regardless that's the right default.

I thought we fixed V2 back to make it do the right thing here, I guess not.


Technically, the defaults in V2 were actually "conditional" in various places for the SSO profiles when in practice that always meant "always". I changed those in V3 to default to the "alwaysTrue" constant because it was pointless to run an extra function that was just going to return true all the time anyway.

I left it conditional in the SOAP cases where it actually is trying to make it conditional.

>Finally, if one had a profile with 'signResponses="conditional"' before, what is the equivalent in v3 -- just setting that to 'true', since in most cases, conditional was effectively true before?

If you want signing to be what used to be "conditional" that's
<bean class="org.opensaml.profile.logic.NoIntegrityMessageChannelPredicate" />

That's what the backward compatibility code injects for "conditional". I would not expect anybody to do that. If you want that, just leave the defaults on. Which is what everybody should do anyway. That's why they're not visible anymore.

-- Scott