delegation in IDP3

[Robert A Basch]

I made a little progress changing it to p:delegationPredicate-ref=...,
but ran into other issues.

First of all, I found that this setting apparently needs to be included
in Liberty.SSOS override for the second-tier SP, instead of (or maybe in
addition to?) that of the first-tier SP.

Second, while it is now properly referencing the predicate bean, it is
not evaluating it in the way I expected, i.e. where its parent is
"shibboleth.Conditions.RelyingPartyId" and it contains (in the override
for the second-tier SP) a list of the first-tier SPs allowed to present
requests.  But, changing this bean to the "alwaysTrue" predicate does
make it get past the evaluation successfully, so there must still be
something about this predicate (or perhaps another setting) I am not
getting.

Putting this problem aside for the moment, I ran into another issue
in the handling of the SOAP request itself, while testing with the
"alwaysTrue" predicate; these seem to be the relevant log entries:

INFO [net.shibboleth.idp.saml.nameid.impl.BaseTransientDecoder:96] -
 Transient Decoder 'net.shibboleth.idp.saml.nameid.impl.TransientNameIDDecoder#<number>':
 Could not find transient identifier

INFO [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:62] -
 Profile Action SelectSubjectCanonicalizationFlow: Moving incomplete flow
 c14n/SAML2Transient to intermediate set, reselecting a different one

WARN [net.shibboleth.idp.saml.nameid.impl.BaseCryptoTransientDecoder:117] -
 Crypto Transient Decoder 'net.shibboleth.idp.saml.nameid.impl.CryptoTransientNameIDDecoder#<number>':
 Transient identifier issued to <SP1> but requested by <SP2>

INFO [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:62] -
 Profile Action SelectSubjectCanonicalizationFlow: Moving incomplete flow
 c14n/SAML2CryptoTransient to intermediate set, reselecting a different one

ERROR [net.shibboleth.idp.authn.impl.SelectSubjectCanonicalizationFlow:78] -
 Profile Action SelectSubjectCanonicalizationFlow: No potential flows left to
 choose from, canonicalization will fail

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

(where <SP1> is the first-tier SP and <SP2> the second-tier SP).

The result was an "UnknownPrincipal" error returned in the response.

I believe we are using the standard v3 transient ID generation.

Any ideas on what the problem is here, or what additional config we
may be missing?

Thanks,
Bob


> On Jul 22, 2016, at 12:31 AM, Robert A Basch <rbasch at mit.edu> wrote:
> 
> Ah, I can't test this right now, but I bet that's it.  It
> being by-reference actually occurred to me before, but I
> confusedly tried changing it to p:delegationPredicateRef,
> which caused an exception.
> 
> I will try this change soon, and report back.
> 
> Thanks,
> Bob
> 
> 
> On Jul 21, 2016, at 8:30 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> 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
>> 
>> 
>> -- 
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net