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

Danny Zollner <Danny.Zollner@microsoft.com> Mon, 20 June 2022 23:21 UTC

Return-Path: <Danny.Zollner@microsoft.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 D7212C15D4AF for <scim@ietfa.amsl.com>; Mon, 20 Jun 2022 16:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.753
X-Spam-Level:
X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 wETe-cvL39ks for <scim@ietfa.amsl.com>; Mon, 20 Jun 2022 16:21:51 -0700 (PDT)
Received: from na01-obe.outbound.protection.outlook.com (mail-cusazon11020022.outbound.protection.outlook.com [52.101.61.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD26FC15790B for <scim@ietf.org>; Mon, 20 Jun 2022 16:21:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SfmNAHxM6h15c9SP6CGswR6ILtuJSgc5Vs8Ihuw5mj1QbZaWcnQ9OOMBm6kbtuEvp2gUsZxbVaQrGwHv15ZnJjXRmAXpAHWPQUd+/7RV+188RdBCk2Yp5WTHSN/3L84+DquyDg3jEC19fUDv/Og8tCzIYF3GYb5kQlaavgT352nPyXI5Uo2bVn2UC3FmVY128XOtmUCzu6RE5f8Dp2JTKCRlWMX/KlgZu/Tik0Llh1ArlmNqpV8SXGPd4ryvFjDzGSPeKRPd4JbBYbrAascr6fO93Vr6tWA9igJ3TWu2JO4jU85nvBy3el5HwN+lqFPap8q4Hv9AWlb8/UYdrYo24Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gg/B7547w3Q9ijmmEtY5QahcVCtqwSUCa1A4PU4Cnzg=; b=iF3W2+lsVj0abYTPuB8boMeAJCF+LG44owvJtJX00htxWO1Oo12jJpy5ibzxZcbyxWKQOOYyZhgsAyoxdS2UaGfXQK785ZE3tLV6a+ko10E7GuLdlQ+KW4rmMIHrZ9MKHBdQ0EHWmhmIZEq0cDFJKNU5KlQtv25rc4rCB7KU1wbLh36XX/PEV0Ew8NkdlsT/R3ubiB6h3H5TijZIvhyCK8zSeVA0kGkcXSQZSSaBk5K0Nwln+qGDT47RfjGtLrfj6As/Jl3XRLh3pnR1z4keMAqaveJfXb8ufBW4xu2xJRWGR6z0j9lhjNfJnrTa0Gwz+558B7ptd10kaZ3dgrW+aA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gg/B7547w3Q9ijmmEtY5QahcVCtqwSUCa1A4PU4Cnzg=; b=MHLwXfbv4BYhyVfV7f6hqBXXStgnfc9l1dmDq3al0fUp679hUyIJ44iVdYbKZJyfJTV/z4dUBuBFrN9jfX57cbUHPBbHCB4/1vPtetc1I/f1m9pERL85wjIkgCPGtbn7eVMn3+7Oz2pFdxnyocJiqFAmM8H9P3zoQ9tl/NEjNLs=
Received: from MN2PR00MB0720.namprd00.prod.outlook.com (2603:10b6:208:1d8::15) by SJ0PR00MB1173.namprd00.prod.outlook.com (2603:10b6:a03:380::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5399.0; Mon, 20 Jun 2022 23:21:36 +0000
Received: from MN2PR00MB0720.namprd00.prod.outlook.com ([fe80::8d8:fd70:5c8e:ac48]) by MN2PR00MB0720.namprd00.prod.outlook.com ([fe80::8d8:fd70:5c8e:ac48%9]) with mapi id 15.20.5409.000; Mon, 20 Jun 2022 23:21:36 +0000
From: Danny Zollner <Danny.Zollner@microsoft.com>
To: Phillip Hunt <phil.hunt@independentid.com>, Danny Zollner <Danny.Zollner=40microsoft.com@dmarc.ietf.org>
CC: "scim@ietf.org" <scim@ietf.org>
Thread-Topic: [EXTERNAL] Re: [scim] Revisiting SCIM roles and entitlements extension draft
Thread-Index: AdiEBr2GiFh2IDBDTGKUp9o/9SGzyQA6b9iAAACT1ZA=
Date: Mon, 20 Jun 2022 23:21:36 +0000
Message-ID: <MN2PR00MB0720DD2A634FF1BC65764BFEFFB09@MN2PR00MB0720.namprd00.prod.outlook.com>
References: <BY5PR00MB0708733ABCEDAE892EF6D7F8FFB09@BY5PR00MB0708.namprd00.prod.outlook.com> <9BD9A9E5-E515-4624-8DEA-D0BAC988C078@independentid.com>
In-Reply-To: <9BD9A9E5-E515-4624-8DEA-D0BAC988C078@independentid.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-06-20T23:21:33Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=edaa6496-0e3d-4859-acbf-0ebbf06e0ade; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d353cd76-aa16-4816-21ec-08da53139f0b
x-ms-traffictypediagnostic: SJ0PR00MB1173:EE_
x-microsoft-antispam-prvs: <SJ0PR00MB1173279E03D8D6EA437902A5FFB09@SJ0PR00MB1173.namprd00.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: J6SntKKzNJT1GOJ8jmpuhvvc1DmXJjUaPyV+Qcm/llhQUfF6vJHUPvRjAMVRwe8rm3B2EXEtBw3gmZI9YJ0I25jk0hhep0D1Ws1fp5KWAPXhv/7L+aEdxUDTFGJHCg+vVUw+eSJEcXir1lcDTtmFyNZtjlSxMEqbIGBDs8BhHOcl7KdFDqTm1VhTuJc2rgiZy/9VOXJch0FVc3zDwY+eDxrufnhm+gKGZYsm+5YfuqnoxAo3hzsoTPB9qRbVWxIigAI1sa66pEVIXnxStSH4fJ0awj+IqtykWP+6LXIu1HT71i5onvLaNb0jTo+G35HiKkCFmPHdt6giL74mwxB3Q8I9I67/hTENnCnj9pAndFoOxRyrA+dQVF0N6rH40bgF/Pc+ZvAuzAcZua+C1He1WhyeBLObnNJfUd9glG6JiFIGdrM2azcTPzNPbpcW1Fts4Dt2jG8SozNRZukrCoNcFVmvYO/MQ9AjJuzywR/L4li1Tpfg2BZbjG6apj3L9LyL+X+sR9Drp4rXo+wmIonayDlKgyKdHdXfDJOvUcfRLn3uwmHCDR+Xc26twTMVS0rYYGas/7wZet5TKzO40ppcIvHnY51YrSEiJsPcPp7O2gvEz2IyXi8COgL4ZSiXkDlB9SKHlRFfsysUCgfo7UGtpMYdtmPj+5cT41e9mtHQsFBwohhLc0A8HbrEm2KM0CFteKElRK4WdI8UMoZq2JT1Tr4tn+LO23cwxgI7Kq05LmBJ63yuM1glOuR32fFE2J5iBLAbRM9xFwTUsf9cZ48K3AE1RzdhQCREjG+QWJv1afGczRdd9+KF85tCvS4v67j3vbCKIKLC/FJZNGpR+p1F2Mxp7Jkiu3oRqS/O1e9Gj5keJU2/5JYGx7NeveiLV0pw
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0720.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(376002)(39860400002)(136003)(396003)(346002)(366004)(451199009)(38070700005)(41300700001)(8936002)(122000001)(9326002)(82950400001)(66446008)(66946007)(66556008)(66476007)(10290500003)(4326008)(83380400001)(38100700002)(186003)(64756008)(478600001)(71200400001)(53546011)(6506007)(7696005)(30864003)(52536014)(5660300002)(33656002)(966005)(82960400001)(55016003)(316002)(76116006)(110136005)(166002)(2906002)(86362001)(8990500004)(8676002)(26005)(9686003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?XD9LeWyngR4nqcayMbIUwDjHmAOr/0ZJ/cA0i4AGv/cksdTsRdEy1RnmK0z/?= =?us-ascii?Q?Hxyvy+HDiMPmkgppJMl91KxGXp45L5hyi3iukHeM5G+h4tdjz6mvoz2jHUNS?= =?us-ascii?Q?RRFEgtjkajNjJm3mcHVpsCHVuUtK1/z7GmzNmv3UeROJ8QksZ4NO0Kyj6fzI?= =?us-ascii?Q?0zMvlbE5v/c15WiLbQKXteVuNmg1Ds/1n1/4z+cZVSaS67V6uFZl8dPzU0It?= =?us-ascii?Q?9V6g5cqcQrr098x5QR4/xMwOStqJtgFA7VNWg88ggXSly5lNCbbbGZo/TzAb?= =?us-ascii?Q?KnjY0FUezUU/VjiCc3uvIcdMfM4D/n6C7tyYv3sMRTQssXMFGOGcvgZTvolX?= =?us-ascii?Q?YtQOEkfxt+xYtqXEJgEFVh3fdm7WNhQnXZuXALZZt4Q2X2DPs/AnrSf9i8a2?= =?us-ascii?Q?+lLPX0Jsf08eCpdhS+3W+uZ5UdjeKqsQ7Q05fS81ilvdC6Z+hWJNKJAeqo6F?= =?us-ascii?Q?p5yLRKLubx/F9L/QkEmJUzZKD+NXD155ueyGmxp6Oy60ODSz8XaJbK96KI3E?= =?us-ascii?Q?Oqb13//nQ8Y2a2p/Fr8/NWGjTTS+BoyyYpsg0CQL6DYD1JnDSxATrf6v/ajz?= =?us-ascii?Q?o3VFd66y0XhrECWrB8DvexFtISrmfkDLBz+VyrtivNj6YZsmcCSXqPXnHV1o?= =?us-ascii?Q?Y9VSABZ18kuKxmqYiVQP7WjYsKxkwWXUcmPQoFs5cvKHLJ2KgXptvsrXXc0U?= =?us-ascii?Q?fF0w/LgInZE7mPRGp4KppQ6K3TmvJ+M85ruNAyLjd3OE/zz1VFUX4HeK7zvP?= =?us-ascii?Q?kf45KyuvIanYPl+SY6k7AYqI4EFF1ra4OTHyuxuJOQMuMGrlKOlwiG46Ndgh?= =?us-ascii?Q?jjwwnV9orICm+O/t4EWDId4UyYa35vBibn+HFY1Y3Dy3/yMouHCs5kq+6mAM?= =?us-ascii?Q?vnNcq5BIzlqgaHrFJ62IumMtn1r3BdLIDq99D/kEXmzuXYCxCs/3dg1XBFIL?= =?us-ascii?Q?gZ9lR+7jP0qLufgJOC1Gnmehn2Wd0KRcYD5WABYYe3tzwonUsnxVm+n7u+PU?= =?us-ascii?Q?0UsO9VnBOsKLzUae0S2qcfv/ZmD975rZKfR132qKJ9jm7+krxxXHFuhnafNh?= =?us-ascii?Q?5hx/Bc5hxaGAVysYaXkleG6Obo1EX5MqhREHVckDFSrLn+NAQjdK5ysupD4R?= =?us-ascii?Q?99OGzM1F+fi8tfqq+E/PWPGJHGXOFsyxxdpptfdLLWRo80keR0OgGrnFlaMt?= =?us-ascii?Q?fX4yOp9YwguSX8TYhrQlNWUTWa9e0tlUwdYddco7eeStklkDkWg8ny6+FogG?= =?us-ascii?Q?VZ3e2HVhIf8/Ygd63bYn3h/b3G3H3DCyp6SseSmuX5zQfrJ02+3RZlB4B5lj?= =?us-ascii?Q?DKWnDsIa8PjTaAba3M58b9BTLgxOFKfhq92HDsHPJmR1za7Br3Ss8Wsx9neY?= =?us-ascii?Q?wlYfMpXOHRyMAokdSXKLNQ/sDCXmsAMILNUeHgh/BdIKgfmqHwQK6/rKLyNb?= =?us-ascii?Q?103Hp4MWFkcRE7Td9fr04ay7/nbaST6OfJ6hCI2DS7VMgt13T/jiX660YPUn?= =?us-ascii?Q?3tBWFxZ8eBC37zQ2Ve97zr3+nqFNf/PwXxl5xvooqMnqChOLx5k4GZNNNwij?= =?us-ascii?Q?C1plS3g1LE242yRravpuFW3590Y8rv+EFZWZnSpRtUfzxJMhUE0ylHnj8P+I?= =?us-ascii?Q?P1vEj7jyh+ME0DDIyBpH8EEtt+Pz0mLya/YkmBg4OFpwctYsS9uMqov6sdTv?= =?us-ascii?Q?d32zQqbjnxYGXLjI1lDOHyeWhG8tvtKRxm4mAUNEFzAX1EImdVwALs3j9KNk?= =?us-ascii?Q?euO8UovJLQ=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0720DD2A634FF1BC65764BFEFFB09MN2PR00MB0720namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0720.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d353cd76-aa16-4816-21ec-08da53139f0b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2022 23:21:36.3512 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UX9RVcW6XEhfM5Wpl345FxnF6zfgg6dELhoJf14GkitqGa/CW6c/upd1cK0tde3bc/2pp10qQkvZMCKKJUDXFQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR00MB1173
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/LYsRJSZKKC3M55-qW0FKvvZ6Wjg>
Subject: Re: [scim] [EXTERNAL] Re: 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 23:21:54 -0000

Hi Phil,

Thanks for the feedback. First, to clarify: These are intended to be new resource types (/roles and /entitlements) and the intent is to provide a list of values that are acceptable to the user resource's core "roles" and "entitlements" attributes. I think the confusion around your comment that I could be "defining attributes that could be attached to any User or Group object" is that that is actually sort of the case - except it's that I'm trying to standardize a way to define what values can be populated in certain attributes (roles, entitlements) on a user object.

To your comments on "if they are resources" - out of order since it's easier to flow thoughts that way:

#2 - Yes - the roles returned via GET /roles should be accepted values for the user resource's "roles" attribute - from what I've seen of various SaaS implementations, I'd expect the user resource's "roles" value to require the value of the "value" attribute rather than a friendly displayName type attribute. "id" and "value" could be converged into one attribute, but probably only if there was no hard requirement to have the "id" value be a GUID versus some internal (and immutable) value.

#1 - Acknowledged/somewhat agreed on changing to id + name/displayName rather than value +name/displayName. The thing that had me going in a different direction was trying to match the available sub-attributes on the complex "roles" and "entitlements" objects on the user resource. As another approach, "id" could still be included but just as an anchor, and could then actually free up the "name" and "value" sub-attributes to be mutable, since the job of being an immutable anchor would be held by "id".

#3 - If this were extending the schema to add new attributes that are just simple non-validated strings, I'd be in agreement. One of the common points of variation in how I've seen SCIM implementers approach roles is in whether they only accept a single value or multiple values. Given the primary goal of this draft is to create an easier alignment between SCIM clients and SCIM service providers, surfacing which way the service provider has gone here (via ServiceProviderConfig) solves a pretty common set of pain points.

Re: the contains/containedBy nesting topic, my initial thoughts were similar - there is value in knowing the structure, but is there enough value in the service provider handling full mapping of that (direct/indirect), versus putting that burden on the client - which probably just becomes a single GET /roles or GET /entitlements request and the client can then map the structure based on each object's direct contained/containedBy (or.. parent and child? Another naming idea..) and cache the results if it so chooses. If I had to put support behind any variation of this, it would be the base direct link only version of contains/containedBy, and to avoid - maybe even explicitly recommend against or prohibit - showing indirect nested results. The entire contains/containedBy concept would be optional, also.

Thanks,

Danny

From: scim <scim-bounces@ietf.org> On Behalf Of Phillip Hunt
Sent: Monday, June 20, 2022 3:56 PM
To: Danny Zollner <Danny.Zollner=40microsoft.com@dmarc.ietf.org>
Cc: scim@ietf.org
Subject: [EXTERNAL] Re: [scim] Revisiting SCIM roles and entitlements extension draft

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<mailto:phil.hunt@independentid.com>




On Jun 19, 2022, at 9:25 PM, Danny Zollner <Danny.Zollner=40microsoft.com@dmarc.ietf.org<mailto: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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-zollner-scim-roles-entitlements-extension%2F&data=05%7C01%7Cdanny.zollner%40microsoft.com%7Caedd12d40c23459872f808da5307a8bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637913589638079730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WPpS6T3Zet7lRXFXEPRaf1%2FD0go0YOXprABx3AnaOcs%3D&reserved=0>

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=05%7C01%7Cdanny.zollner%40microsoft.com%7Caedd12d40c23459872f808da5307a8bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637913589638079730%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2sg59W17Buy2PFCQpqTYf86CZHWMS2Nm4qpgOefYbWc%3D&reserved=0>