intercept/attribute-release flow with attribute queries in v3

Cantor, Scott cantor.2 at osu.edu
Fri Dec 12 10:47:51 EST 2014


On 12/12/14, 3:43 PM, "Kaspar Brand" <kaspar.brand at switch.ch> wrote:


>
>It's not an issue with the standard uApprove version, since it doesn't
>support an individual selection of the to-be-released attributes. As
>long as the user doesn't approve the release at least once, there's no
>chance for an SP to query the IdP (even for queries based on targeted
>IDs). uApprove JP (which supports per-attribute selection) apparently
>uses a custom query handler for v2, as I just learned from
>https://issues.shibboleth.net/jira/browse/IDP-465.

Ah, true. But it's not that simple, there are certainly ways to query 
(using non-transients) without SSO first. And certainly with targetedIDs, 
at least stored ones. I'll think about it. I checked in a simple change to 
turn off the flow for non-push, I'll see if I can relax it to be specific 
to the per-attribute case, should be easy enough.

>Ah yes, forgot to mention that I'm using server-side storage
>(JPAStorageService, to be precise). I'm not sure that client-side
>storage for user consent settings is really useful.

It's not only useful, it's the only way to make this matter for most all 
of us except a few tiny pockets. Without it, I would still view consent 
work as a waste of time for the core team, when 90% of our users would 
never turn it on. Now it will be on by default, which could never happen 
if a database was required. It's a game changer.

-- Scott



More information about the dev mailing list