<div dir="ltr"><div><div><div><div><div>Hi All:<br><br></div>We have to register attribute consent -- for legal reasons. And have to store the eduPersonTargettedId for Help Desk look up.<br><br></div>Based on this thread:<br><br></div>-- we can leverage memcache for HA (although we also have a load balancer -- but may have to restart servers occationally)<br>-- JPAStorageService for database storage of 'attribute consent' agreements & eduPersonTargettedId<br><br></div>Although would be great to have no DB dependency - but the call came from high on up.<br><br></div>Given the above -- are we on an implementation track that is workable?<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 9, 2016 at 12:14 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> If I understood  correctly - it will be better to go with JPAStorage - this will<br>
> take care of both the 'Consent'  and eduPersonTargettedId?<br>
<br>
</span>Persistent ID storage is a dedicated piece of code and doesn't use the same code as the JPAStorage plugin. You can use the same database for both I would assume.<br>
<br>
I'm not advocating either. Databases are almost always a single point of failure, and I don't use one with my IdP. The IdP comes with the configuration I advocate. The fact that it doesn't support consent other than per-device is because I value statelessness over virtually every other consideration and think it is the best choice for the majority of sites.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>