Re: [scim] Revisiting SCIM roles and entitlements extension draft

Phillip Hunt <phil.hunt@independentid.com> Mon, 20 June 2022 21:55 UTC

Return-Path: <phil.hunt@independentid.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91020C15D487 for <scim@ietfa.amsl.com>; Mon, 20 Jun 2022 14:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=independentid-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEWlSzTM2lh9 for <scim@ietfa.amsl.com>; Mon, 20 Jun 2022 14:55:45 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C411FC14F746 for <scim@ietf.org>; Mon, 20 Jun 2022 14:55:45 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id 184so11356139pga.12 for <scim@ietf.org>; Mon, 20 Jun 2022 14:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=independentid-com.20210112.gappssmtp.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iawRQMV6u6zpaVDMS1RRL8k1GhuR7Bf9qnPdVgiWxkI=; b=wVZID5slDNvs8cM+qelaHKkKcYNcQBLxVEd9KVh9AoJTqaGT29LaGRqOWSC7dJqz2i f/ZwVbwjGnI5qHGPAYtWcFt6efO8k9sAiNnHfeEE0qOtlMhXpqlFIqoT5Q+6Uj4dR491 ohd0iU/Tpn6G6XL1dTxQnq3eBmObSjaKkUboqMT8/TVTbM9GHzX7qT+hVU95nV/VA4uR vOLhvh1RoNSbrIs9hvONKNmwHEeMqxJuesIeOBPjxlIfmSGIDtxNUQ0clz38PnRY0xyK vEM7Jhxbe5qU6AhJ4Ov08u5OuYDljlQLqIFnDmOzGEYVNMjd3tL3X7Tf29DGzovIdBow JkOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iawRQMV6u6zpaVDMS1RRL8k1GhuR7Bf9qnPdVgiWxkI=; b=LXZLZNJqMR9oy7fuGtOaID1aNnls8W5bbnzr7kcy2afWnXyufy3rQlhI/oRL/er4sZ nURDObR7C7goX7WyOdXSf2CS0U1YzDK6im7XBIMhC5XwcTeO6u8LNzctH0LZxI/Nnmal k42slpazGm4y4FRbBqtb+lhNfCHHRO45UMzlbFyZwUkwDcBRIckAudftjc/6URbQiqV7 M3JSaOizeE/p5hvuwtk2XLdIv4Wak9JQ8fmzwwZNWyPKF1o1s8/DIHoTcAsDZjrHSCIr E0I5xzzctmUWLKgG8IBpQo73RSSLca52SD17TNpSeWbZYQvp+YmtiqC8g0+MqjXasJc7 0NdQ==
X-Gm-Message-State: AJIora/0AqXLBy6gvwbZ5Wpqa3FoVGGdW+S+P/xs+KhBTXpVRsiULA1g rRLgWREOIULu8GSS1brn6e3wZ3YLM6lJXQ==
X-Google-Smtp-Source: AGRyM1voql58Uu+hFswWVXOoUWDNPtb0sZoW4XqsOsT7CNy7hl1VFmPThixELq35YBmSwctbsnGdLQ==
X-Received: by 2002:a62:6411:0:b0:50a:81df:bfa6 with SMTP id y17-20020a626411000000b0050a81dfbfa6mr27064090pfb.26.1655762144705; Mon, 20 Jun 2022 14:55:44 -0700 (PDT)
Received: from smtpclient.apple (node-1w7jr9qjhqzxqd7p9cml3p7xx.ipv6.telus.net. [2001:569:7316:ae00:e888:dbea:c561:ab75]) by smtp.gmail.com with ESMTPSA id c73-20020a624e4c000000b0052513c1c4bbsm5012733pfb.38.2022.06.20.14.55.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jun 2022 14:55:44 -0700 (PDT)
From: Phillip Hunt <phil.hunt@independentid.com>
Message-Id: <9BD9A9E5-E515-4624-8DEA-D0BAC988C078@independentid.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5700E365-1EBA-4550-9704-E33904556B67"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Date: Mon, 20 Jun 2022 14:55:43 -0700
In-Reply-To: <BY5PR00MB0708733ABCEDAE892EF6D7F8FFB09@BY5PR00MB0708.namprd00.prod.outlook.com>
Cc: "scim@ietf.org" <scim@ietf.org>
To: Danny Zollner <Danny.Zollner=40microsoft.com@dmarc.ietf.org>
References: <BY5PR00MB0708733ABCEDAE892EF6D7F8FFB09@BY5PR00MB0708.namprd00.prod.outlook.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/paSkqidezW1YVSDWy8lo9b3q33Y>
Subject: Re: [scim] Revisiting SCIM roles and entitlements extension draft
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/scim/>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2022 21:55:49 -0000

Danny,

I took a look at the draft. Great thoughts. However, I was not sure of your intention. On one level, it feels like you are defining attributes that could be attached to any User or Group object.

However, looking at your example (GET /Roles), it looks like you might intend Roles and Entitlements are resource types (and thus might require ResourceType definitions).  

Assuming roles and entitlements are resouces: 
* There should be “id” attribute (a guid) and a “name” attribute instead of “value”).
* Are defined Roles referenced in the “roles” attribute (e.g. by Name)?
* As a resource type, you don’t really need serviceProviderConfig data because the extension is discoverable through the /Schemas and /ResourceTypes endpoints.

If you mean to define a new attribute, the normal way is to define a new schema which can be attached to another resource. For example, see: Section 4.3 of RFC7643 which shows the Enterprise User Schema extension.  This could be some new extension like "urn:ietf:params:scim:schemas:extension:enterprise:2.0:RoleEntitlement”.  Doing it this way means you can attach the new attributes to any existing Resource like a User or Group.

Nested Roles like Groups are powerful things (I’ve used it to control access to a million plus resources for a 100k employee company using 40 groups built by HR role information). However in practice, resolving nested groups/roles can be expensive at scale. In particular it was very bad for search results. For any kind spec,I think we have to assume many won’t support nesting (same as for nested groups now).

One thing I see in my work today is that instead of a single shared PDP/access service, there are many PEP/PDP control points each needing the same data. While nested groups makes information management easy, having a SCIM server or client “flatten” the roles a dozen times for each request raises some performance worries.  Maybe this can be solved with caching (which may cause other security concerns)?  This also might not be so bad if SCIM is the backing store for an OIDC server where the flattening process only has to happen once to generate the ID_TOKEN assertion.  Not saying we have to solve this, but it would be good security consideration discussion (because killing performance becomes a Denial of Service concern).

Hope this helps!

Phillip Hunt
@independentid
phil.hunt@independentid.com




> On Jun 19, 2022, at 9:25 PM, Danny Zollner <Danny.Zollner=40microsoft.com@dmarc.ietf.org> wrote:
> 
> Hi SCIM-ers,
>  
> Last fall I submitted a draft for an extension to add new /roles and /entitlements resources that can be queried to allow a SCIM client to discover what roles exist on the service provider before trying to apply any values to roles or entitlements for a user. That draft has since expired, but I would like to revisit it and make any necessary revisions ahead of submitting a newer draft and requesting a call for adoption. The expired version of the draft is located here: https://datatracker.ietf.org/doc/draft-zollner-scim-roles-entitlements-extension/ <https://datatracker.ietf.org/doc/draft-zollner-scim-roles-entitlements-extension/>
>  
> In addition to what is described in the first version of this draft, in order to gauge interest I want to bring up a second concept that could be added to the draft. The new concept is a representation of relationships between roles or entitlements. Many systems have a hierarchy of roles or entitlements. To add on to my draft, I’m considering adding two new multi-valued attributes to both the roles and entitlements resources – “containedBy” and “contains” (names open to change). The goal would be to allow representation of something like:
>  
> A SCIM app used as a CRM system has a role structure where the role “Super Administrator” has all privileges
> More granular roles exist also – i.e.: “Application Administrator”, “Finance Administrator”, “Sales and Accounts Administrator”.
> This structure may nest several levels deep – i.e.: “Finance Admin” may have separate sub-roles underneath such as “Accounts Receivable Administrator”, “Accounts Payable Administrator”, “Payroll Administrator”, etc. 
>  
> Applying a SCIM/JSON structure to represent that data, we may see something like:
>  
> Role 1: Super Administrator
>  
> {
> “value”:”SuperAdmin”,
> “display”:”Super Administrator”,
> “enabled”:true,
> “contains”:[“AppAdmin”,”FinanceAdmin”,”SalesAdmin”]
> }
>  
> Role 2: Finance Admin
> {
> “value”:”FinanceAdmin”,
> “display”:”Finance Administrator”,
> “enabled”:true,
> “containedBy”:[“SuperAdmin”]
> “contains”:[“AccountsReceivableAdmin”,”AccountPayableAdmin”,”PayrollAdmin”]
> }
>  
> Role 3: Payroll Admin
> {
> “value”:”PayrollAdmin”,
> “display”:”Payroll Administrator”,
> “containedBy”:[“FinanceAdmin”],
> }
>  
> If contains and containedBy are left as multi-valued strings, there’s then the problem of deciding if you only represent direct or indirect membership in a higher role – i.e.: Payroll Administrator is contained by Finance Administrator directly – but if the goal is to determine what permissions the Super Administrator role has – the indirect values, that is - the nested memberships from the three roles that Super Administrator contains would then need to be unpacked recursively(I think that’s the right word) until the bottom of the structure is met. 
>  
> An alternative approach there could be to add an additional two attributes, and have four multi-valued string attributes – containsDirect, containsIndirect, containedbyDirect, and containedByIndirect. Another approach that I think is the better solution to this problem would be to change contains and containedBy from multi-valued string to multi-valued complex, and to have two sub-attributes on the complex object – value and type(name tbd), with type representing if the value is a direct link – i.e.: Payroll Administrator being contained in Finance Administrator – or if it’s an indirect link, i.e.: Payroll Administrator being contained in Super Administrator by way of Finance Administrator.
>  
> My questions/requests to the group are:
>  
> I would appreciate feedback on the current expired version of the draft
> For the new idea that I outlined, is there need for this level of detail being represented as an optional component of the extension?
> For the new idea, general feedback – is the current approach best, are one of the others that can handle indirect links better, or is there another approach I haven’t written about?
> For the new idea, what are thoughts on circular references – i.e.: Payroll Administrator contains Finance Administrator, but Finance Administrator also contains (not is containedBy) Payroll Administrator. Should they be explicitly prohibited, or are there scenarios that should be accommodated that would require circular references?
>  
> Thanks,
>  
> Danny Zollner
>  
>  
>  
>  
>  
> _______________________________________________
> scim mailing list
> scim@ietf.org <mailto:scim@ietf.org>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>