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