[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    Re: Call discussion of subject c14n use of attribute resolver
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2013-08-10 19:59:58
Message-ID: BA63CEAE152A7742B854C678D9491383AD1425E7 () CIO-KRC-D1MBX01 ! osuad ! osu ! edu
[Download RAW message or body]

On 8/10/13 4:21 AM, "Rod Widdowson" <rdw@steadingsoftware.com> wrote:

>I hadn't thought about that part of it, but now you mention it, it makes
>perfect sense.  It also probably makes for easier reconfiguration - this
>is
>"just the same" as other configuration, rather than being "you have to
>implement this API"...

Well, either way it's Java code potentially, but I think it depends on
whether the integration "fits" with the use of a flow action.

This is a pretty explicit operation that happens at specific times in a
profile, and not often, so I think it works ok as a flow action. I'm
working through the problem of how to deal with enforcing
RequestedAuthnContext, and it's not working so well that way.

I have to have a component that can evaluate several different types of
objects (an authn flow, an active result, a credential validator action)
against the request content and a set of matching rules (e.g. "two-factor"
is > "password"). It has to potentially run in a lot of different spots
and potentially several times in sequence. I think it works a lot better
as just a bean that is defined in one place and injected into any actions
that need it.

-- Scott


--
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]