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