(For those not familiar, "DAC" is Discretionary Access Control and "MAC" is Mandatory Access Control. We're using those terms somewhat loosely, but you get the idea. Here are some discussions: DAC <https://en.wikipedia.org/wiki/Discretionary_access_control> MAC <https://en.wikipedia.org/wiki/Mandatory_access_control>) This is some great, careful parsing of the language, and brings us firmly into the BLT challenge -- whether on the federated authorization or the individual consent/delegation side of the world. You're right that the Delegate-Protection clause, as currently stated, is very "all or nothing", and doesn't match the more careful and new circumscribing in the Respect Permissions clause. (The latter's name, btw, is still old; it comes from when the text was still itself all or nothing. Depending on which way we go, maybe we should rename it.) In V1.0.1 Core Sec 3.3.3 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#give-access>, as already noted, we clarified that the RS always has the right to refuse access, the way an RP does. But we had been assuming that if the UMA flow is being used, then Alice's word goes when it comes to denial of access; you can see it in this wording in the same section: "The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization." This has been in the text for a long time. The equivalent in V1.0 (Core Sec 3.1.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0.html#rfc.section.3.1.2>) was "The resource server MUST NOT give access where the token's status is not associated with sufficient authorization data for the attempted scope of access." The thinking has been that if the RS is consulting the AS at all, then the process has to count for something. There are plenty of ways for the RS not to consult the AS and do what it wants -- and that's where MAC can come in. But I can think of at least a couple of sticky wickets here. - An RS can perform any "local" authorization procedures it wants, before and/or after doing the UMA dance, i.e., getting a token from the client, introspecting it, etc. Are we saying that the moment an RS, say, accepts the client's token -- or introspects it (what's the relevant state change?) -- it's suddenly impossible to grant access if the associated authorization data said no? The state change we pick will strongly affect what optimizations RS's will pick. - If UMA ultimately gets commonly used for MAC-ish use cases separately from DAC-ish use cases -- iow, it's used in separate circumstances possibly by different IT stakeholders for both ordinary "do what Alice says" stuff and "override her wishes" stuff -- then what the heck is the interaction between *not* consulting Alice's AS but going off and consulting the enterprise's AS at some point?? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Dec 21, 2015 at 7:38 PM, Allan Foster <allan.foster@forgerock.com> wrote:
Folks, I am concerned about putting specific obligations on the RS and thus subjagating it to the AS.
Specifically to allow for Enterprise MAC with UMA participation, where the End user is a participant in the access control decision, but not the only participant.
1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md>-Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md>: Delegate-Protection* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> and Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md> have mutually agreed to serve in these respective roles for each other , theResource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> gains an obligation to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md> to delegate protection services to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> for the set of protectable resources for which it represents this capability to the Authorizing Party <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorizing_Party_0.md>, and to respect the authorization data that the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_0.md> has associated with an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> when the Resource Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_0.md> subsequently allows or disallows access by the Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Client_0.md> that presented that RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> .
My concern here is that it delegates "Protection services" to the AS, and this feels a little like an all or nothing. This might not be true in the case where the RO is only one party in the Access control decision.
1. *Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md>-Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md>: Respect-Permissions* For the period that the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> and Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> have mutually agreed to serve in these respective roles for each other , the Resource Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Resource_Server_Operator_0.md> gains an obligation to the Authorization Server Operator <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_Operator_0.md> to disallow access by a Client <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Client_0.md> presenting an RPT <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Abbreviation/RPT_0.md> in all cases where the authorization data associated by the Authorization Server <http://www.commonaccord.org/index.php?action=source&file=GH/KantaraInitiative/UMA-Text/Terminology/Term/Authorization_Server_0.md> is insufficient for the access attempt..
The RS is obligated to dissallow access in the AS cannot provide sufficient rights - in all cases.
This has several implications. If the RS has additional business rules whereby a party might get access even tho they are not UMA authorized, (break glass?) (Admin or Help Desk) The RS HAS to determine if a user is a special user BEFORE making the request to the AS. Since once it has an answer, it is obligated to deny. This implies that the RS cannot opt out once the request to the AS is made.
It feels a little bit like don't ask don't tell!
My Concern is that the RS is ALWAYS the final arbitrator of access control, whether UMA, DAC or MAC. It should be able to modify its behavior based on local business rules and exceptions.
Allan
-- Simplify Email: Email Charter <http://emailcharter.org/>
[image: ForgeRock Logo] *Allan Foster - ForgeRock * *VP Strategic Partner Enablement* *Location:*San Francisco *p:* +1.214.755.9218 *email:* <allan.foster@forgerock.com>allan.foster@forgerock.com *blogs:* blogs.forgerock.com/GuruAllan *Skype:* Call GuruAllan <http://is.gd/lWVfMG> *www:* www.forgerock.com *www:* www.forgerock.org
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma