delegation in IDP3

Cantor, Scott cantor.2 at osu.edu
Thu Jul 21 20:30:47 EDT 2016


Brent may have to look at this, but just in case it's pedantic, see below...

On 7/21/16, 7:34 PM, "users on behalf of Robert A Basch" <users-bounces at shibboleth.net on behalf of rbasch at mit.edu> wrote:

      <bean parent="Liberty.SSOS" p:allowDelegation="true"
              p:maximumTokenDelegationChainLength="1"
              p:delegationPredicate="testPredicate" />
    
>    And testPredicate looks like:

Is that really p:delegationPredicate? May be the Spring converters doing nasty things again. You want p:delegationPredicate-ref="testPredicate" if you're referencing another bean. Otherwise it's by-value.

If that's the trick, we have an over-aggressive String-to-Predicate converter that's turning that bean name into "false".

> Am I misunderstanding how the predicate should be set up, or is there
> perhaps some other configuration that is missing that would result in
> this failure?

With luck, it's as simple as my suggestion. Changing the predicate bean wouldn't mean anything if that's the problem, since it's never being referenced.

>    Also, we have found one apparent difference with the v2 implementation.
>    In our initial testing, the IdP did not decorate the SSO assertion for
>    use as a delegation token.  By turning on debug logging, we figured out
>    that the IdP now requires either that delegation be requested explicitly
>    in the authentication request, or an <AttributeConsumingService> element
>    to be in the SP's metadata containing a <RequestedAttribute> element for
>    the "urn:liberty:ssos:2006-08" attribute.  This was not the case in v2;
>    we got past this problem by updating the SP's metadata accordingly.

I'm reading code I don't know, but my impression is that there is a sort of global on/off switch to do that, but it's not wired up, and it would be global rather than a more expected setting in the SSO profile config.

-- Scott




More information about the users mailing list