delegation in IDP3

[Robert A Basch]

We have converted to the new relying-party format, and finally got
around to testing delegation with it.  I do not seem to be able to
configure it correctly, though, as all requests to the SSOS endpoint
result in an error returned to the SP.  The salient messages in the
log seem to be (edited for readability):

WARN [net.shibboleth.idp.saml.saml2.profile.delegation.impl.EvaluateDelegationPolicy:238]
  - Delegation predicate eval indicates delegated token use NOT allowed

WARN [org.opensaml.profile.action.impl.LogEvent:76]
  - An error event occurred while processing the request: InvalidSecurityConfiguration

I assume the problem is with the delegationPredicate setting in the
Liberty.SSOS override for the first-tier SP.  I also assume this is
the analogous syntax for the <samldel:DelegationRestriction> elements
we had added to the samldel:LibertyIDWSFSSOSProfile configuration in
v2, i.e. where we enumerated the second-tier SPs for which the SP
was allowed to present requests.

So, in our test case, the first-tier SP's override contains:

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

And testPredicate looks like:

  <bean id="testPredicate" parent="shibboleth.Conditions.RelyingPartyId">
      <constructor-arg>
          <list>
              <value>WSP_EntityID</value>
          </list>
      /constructor-arg>
  </bean>

where WSP_EntityID is the entity ID of the second-tier SP.  But I must
be missing something basic here, because this failed in the same way even
when I tried defining the predicate to always be true, e.g.:

  <bean id="testPredicate"
      class="com.google.common.base.Predicates"
      factory-method="alwaysTrue" />

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?

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.

Thanks,
Bob


> On Jun 10, 2016, at 11:24 AM, Rod Widdowson <rdw at steadingsoftware.com> wrote:
> 
> I've reproduced the OP's problem.
> 
> I'm not sure what's going on yet, the details are historical and hideous,
> but we'll fix it for IDP-997 (there's an easy immediate fix, but the
> systemic problem needs fixed too).
> 
> In the meantime the only solution to using this profile is to use the Spring
> Syntax.  To reiterate what Scott says, it's kinda scary to start with but
> it’s a shedload less cumbersome once you have grocked it.
> 
> Rod
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net