Revoking consent when proxying auth to other IDP
Description
Environment
Activity
Updated attribute-release flow to support revoking consent based on cookie.
Updated user/prefs flow to support setting the cookie.
That’s the part I don’t care about that much right now. It’s the signaling standardization (and checking for it) I think we should try and include if we can.
As far as workable model, I think user-prefs.js needs some abstraction :
function load(id) {
var checkbox = document.getElementById(id);
if (checkbox != null) {
var spnego = readCookie(checkbox.name);
checkbox.checked = (spnego == "1");
}
}Probably can replace spnego with id but not exactly sure atm.
If we have a workable model for it to put into 5.1, we can try and include it, but if it’s not ready to merge in, probably will have to wait.
I do think we need a standard model to signal this, that’s almost more the issue for me than what we might actually use to enable the signal in any particular case.
In other words, I don’t care so much if we get the userprefs flow updated, but if we get the mechanism defined then at least people have the means to use it.
Nope. Should I do that ?
Users that wish to revoke their attribute consent can do so by ticking the checkbox
Clear prior granting of permission for release of your information to this service.on the log-in page. However, when not using the Password AuthN flow, e.g. when proxying to another IdP, this page is never seen by the user. The issue has been brought up here: 'revoking consent when proxying auth to other IDP' - MARCInstead of creating a newly developed “Your Attribute Consents Overview” page with its own difficulties (e.g. how to display attribute values when only the comparison hash is stored), I suggest two quite easy mechanisms to solve this.
a) Some page similar to
https://idp.example.org/idp/profile/user/prefsthat does nothing more than setting a “shib_idp_revoke_consent” cookie, with a labelClear prior granting of permission for release of your information upon next log-in.b) An enhancement to the
intercept/attribute-releaseflow that does not just react upon the checkox value from the log-in page, but will now react upon the new “shib_idp_revoke_consent” cookie: it will clear all stored consent for all services, and then will remove the cookie. In effect, when users will log in the next time for any service, they will see the attribute consent page again.