force consent for subject when consent is disabled otherwise
I had recently asked about disabling consent at the IDP for SPs
matching certain criteria, which resulted in a rather simple
configuration that disables an otherwise globally active consent
module for REFEDS R&S and GEANT CoCo SPs.
So consent would be enabled globally, but disabled for certain relying
parties matching selected entity attributes.
As part of possible improvements (with or without quotes) for GDPR I'm
now pondering whether to offer an "opt-out" of these rules as an
additional "safeguard" (legal term) as part of a "balancing test"
(legal term) of the subject's rights vs the legitimate interest of the
IDP and SP to process the data. (Cf.  for more, if you care.)
So I'm wondering about possible ways to either stop the subject at the
IDP (/iff/ the subject has opt'ed out somehow /and/ the SP matches one
of the configured entity categories). Or maybe force re-enabling of
the consent intercept for this subject even though consent is
generally disabled for these relying parties.
(The later makes things rather complicated though, as you'd have the
entity attribute to signal "no consent" for the SP, and another signal
for "still force consent for subject" and possibly the subject
actually consents at the IDP, in which case you'd have an external
flag saying "opt-ed out from R&S" and a consent storage record that
says "don't ask me again for this SP" or for R&S as such, if I create
a duplicate from consent as "information screen". And rather than have
these conflicting signals and methods the external flag signalling
this special treatment of the subject should be removed, of course.)
I guess if one is willing to define a local IDM process and define,
say, an LDAP attribute to signal this fact ("block subject from R&S";
as per above "force consent for R&S" seems to make things overly
complicated) this should all be easily possible with the IDP -- and
I'll happily accept pointers.
Maybe I'm looking for "inverse consent", i.e., a table with subject
identifiers that do need to consent (when the SP is R&S), with the
upside being that if they actually consented at some point it would
simply remove their entry from the table again (self-service
(Even further tangent: In the above fictional inverse consent
schenario the legal confusion would then be that for this subject the
legal basis for sending the data on to the SP would have changed from
"legitimate interests" to "consent" but the IDP would have no current
record of that (empty table), as it would treat the subject likey any
other, meaning an R&S SP avoids consent, signifying leg-int as
basis. We'd have logs and transactional data, though. Or the record in
the inverse-consent table could be deactivated, not deleted.)
Anyway. This all sounds rather convoluted for an optional "safeguard"
that merely achieves the following: To allow a subject lock themselfs
out of all R&S SPs when they do try to access them.
> So I'm wondering about possible ways to either stop the subject at the
> IDP (/iff/ the subject has opt'ed out somehow /and/ the SP matches one
> of the configured entity categories). Or maybe force re-enabling of
> the consent intercept for this subject even though consent is
> generally disabled for these relying parties.
> (The later makes things rather complicated though, as you'd have the
> entity attribute to signal "no consent" for the SP, and another signal
> for "still force consent for subject" and possibly the subject
> actually consents at the IDP, in which case you'd have an external
> flag saying "opt-ed out from R&S" and a consent storage record that
> says "don't ask me again for this SP" or for R&S as such, if I create
> a duplicate from consent as "information screen". And rather than have
> these conflicting signals and methods the external flag signalling
> this special treatment of the subject should be removed, of course.)
Maybe it's not that bad. The above can be rephrased such that the
external flag (say, an LDAP attribute) simply switches off the special
treatment I've configured for R&S SPs (consisting in not asking
consent when it's otherwise globally active) and the subject then uses
R&S SPs under the same terms as any other subject uses non-R&S SPs --
by going through the consent intercept (and producing consent storage
records as evidence).
The external flag is probably never going to be cleared up, though.
If it is (local process) it likely makes sense to remove all existing
consent records for the subject administratively, though. (Requires
server-side storage of consent, but I guess at least some will prefer
that over hunting through consent audit logs in case they ever have to
provide evicence of consent given.)
So I guess the question of how to re-enable (otherwise disabled)
consent for a subject based on an LDAP attribute is still valid.
(Not a high priority for me now, so I'll save this until I will do
that deep dive into the documentation to finally understand intercepts
and flows and predicates and beans and everything, right after I'll
get a round tuit. ;))
>> So I guess the question of how to re-enable (otherwise disabled)
>> consent for a subject based on an LDAP attribute is still valid.
> And Keith's example will likely answer all that, too, once I make the
> effort of trying to actually digest it.
In that example, I will guess that "FERPASuppressedUser" and
"NoConsentNeeded" etc. are attribute checking activation
conditions. Seems like those are the building blocks of the logic
(activation condition for a profile intercept flow) you want to
I do not see documentation on how to add an activation condition to a
profile intercept[or] flow. Based on the given example, probably by
In addition to controlling whether or not the consent
(attribute-release or terms-of-use) flows are run (via an activation
condition), you can also control on a per-subject basis via an
activation condition / predicate, which defaults to the
IsConsentRequiredPredicate. But that is deeper in the flow and you
probably do not want to go there.