Consent with CAS

[Cantor, Scott]

On 6/15/15, 1:48 PM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:

>I'm doing recon for getting the CAS flows updated to support the consent work, and there's an immediate obstacle: the AttributeContext needed as a precondition is not available in the CAS login flow. It's not there since it's not needed; attributes are resolved on the back channel ticket validation step that follows login. 

The SAML flows don't run the consent flow unless attributes are going to be included in the response. This is because currently the query flows don't evaluate the consent data to decide what to release, so it's not presented so as to avoid giving a false impression.

The attribute resolution *does* run either way because it may be necessary to do that to populate the subject of an assertion even if the rest aren't being included.

>It's straightforward to add an optional attribute resolution step in the login flow to support the consent flows, but I'm curious whether that will work in any or all cases.

It's necessary but not sufficient.

> The fundamental problem is that the conversation where attributes are approved (login) is distinct from the conversation where user preferences are applied (ticket validation). I see there's a previousConsents attribute on ConsentContext that is populated from persistent storage, which afaict is what I'll need to rely on to get this to work. Unfortunately, the Web storage facility will not be available on the back-channel step, so even if the consent data is persisted successfully, I won't be able to get to it when I need
> it. Can I get around that by requiring a server-side consent store like JPA or memcached? Is that supported yet?

Memcache is not an appropriate choice, but yes, any is supported. The SAML flows will have the same limitation, if we implement support in the queries, it will have to be server side.

-- Scott