Pros and cons of various Consent storage methods

[Mark McCoy]

I too hesitate to add another service behind the IdP that has to be maintained, clustered, monitored, etc, but I guess that may be the only option.

Have there been any thoughts around adding a write-back capability to the LDAP attribute store so that the consent records could be stored in an LDAP in a single multivalued attribute?

Respectfully,
Mark

Mark McCoy
OIT Manager, Platform Application Services
Office of Information Technology
The University of Texas at San Antonio
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Friday, April 19, 2019 15:50
To: Shib Users
Subject: RE: Pros and cons of various Consent storage methods

> Can anyone speak to the pros and cons of each of the three methods for storing
> the consent records (client-storage, memcached, database)? What are people
> using and what experiences have you had?

I would think "real" use of consent means having a database, non-persistent consent doesn't really make much sense. Memcache doesn't seem relevant to this feature at all. That renders consent a non-starter to me, but that's for others to say. I won't put a database behind my IdP sooner than a day from my retirement.

The point of client-side is that it's possible to do terms-of-user style "blanket" approvals via the basic feature design that could be used as a per-device "remember my choice" sort of thing that is at least a form of consent but doesn't need a database. I was planning to do something like that at OSU for FERPA overrides but our registrar overruled me and we left it at nothing, we just block release. Not my call, but I think it would have worked reasonably.

Using it for "full" consent is more a toy and a way to test out the feature than a practical idea. It is a feat of technical engineering that I made it work with no impact on the code at all and I'm pleased that it did, but it isn't practical.

-- Scott

--
For Consortium Member technical support, see https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=02%7C01%7Cmark.mccoy%40utsa.edu%7Cf751c899a8f3405a803c08d6c508a2e2%7C3a228dfbc64744cb88357b20617fc906%7C0%7C0%7C636913038227037050&sdata=Gus97n9Tc6Xp7GpJtkYmPxF4pw6uZAGByjMxyuihB18%3D&reserved=0
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190426/e504541d/attachment.html>