Subject canonicalization flow selection strategy

[Misagh Moayyed]

Excellent. I don’t know why I didn’t think of attribute-release, etc!

So let's see if understand interceptors: A master list is available that 
defines the flows, and each RP may inject itself into that flow by modifying 
the postAuthentationFlows property. Given that the property is a list, I 
suppose flow ids will be called in sequence (or alternative, I might even 
call into a subflow from an interceptor flow).

I can see quite a large number of predicates available which is great. Is 
there one that can examine the RequestedAuthnContext? I can't see one in the 
hierarchy.

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, May 6, 2015 7:43 AM
To: Shib Users
Subject: Re: Subject canonicalization flow selection strategy

On 5/6/15, 12:30 PM, "Misagh Moayyed" <mmoayyed at unicon.net> wrote:



>I wasn’t sure if this should be posted to shib-dev, but here it goes:

If it involves writing code, yes, if not, probably not. Discussion of 
advanced use cases here is fine.

>
>I am working on implementing a use case with idp v3.1.1 where I need to
>obtain a user attribute post authentication and compare it with a
>predefined value/pattern. If a match is allowed, the flow can proceed.
>Otherwise, flow would be cancelled and an error message sent back to
>the SP.

That's not c14n, that's intercept. We already have a flow for this called 
the context-check intercept flow, and one of the basic use cases for that is 
evaluating an attribute.

There are intercepts that run post-login (really post-attribute-lookup) and 
that's where consent, terms of use, and other kinds of interupting logic 
run.

>
>I think the c14n flow that kick in after authentication, and
>particularly the one that is attribute based would be useful here.

It could, but it's needlessly complex to use that.

>Would that be doable? It does feel strange because no canonicalization
>is in fact taking place. The alternative would be to write extensions.

No need, it's built in. I included some sample XML for how one might do it 
in the context-check-intercept-config file that configures that particular 
intercept flow.

Note that you'd never have found this, we haven't documented the intercepts 
much at all yet.

The context-check flow can in theory be configured to do any arbitrary 
evaluation of the context tree to decide the result, I just provided some 
classes and sample XML that do the attribute use case for you. It's 
predicate-based, so I just wrote a particular example predicate. You could 
use a script in fact if you wanted.

>
>Also what I am not clear on is the canonicalization flow selection
>strategy. I can see that each strategy tried to figure if it’s
>applicable but I am not sure in what order these strategies are
>defined. If I enable attribute-based canonicalization, is there some
>sort of ranking I need to define to make sure it kicks in before the simple 
>flow?

It's ordered, and tries them in whatever order the descriptors are defined.

-- Scott

--
To unsubscribe from this list send an email to 
users-unsubscribe at shibboleth.net