Re: [scim] Retrieving members of a group

"Jackson Shaw (jshaw)" <Jackson.Shaw@oneidentity.com> Tue, 04 December 2018 17:27 UTC

Return-Path: <Jackson.Shaw@oneidentity.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 CA379130F19 for <scim@ietfa.amsl.com>; Tue, 4 Dec 2018 09:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=oneidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBA5gv6NQz-1 for <scim@ietfa.amsl.com>; Tue, 4 Dec 2018 09:27:38 -0800 (PST)
Received: from amersmtp2.quest.com (amersmtp2.quest.com [12.106.87.227]) (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 E822E130F85 for <scim@ietf.org>; Tue, 4 Dec 2018 09:27:37 -0800 (PST)
Received: from amersmtp2.quest.com (127.0.0.1) id h0qsgk0171s8 for <scim@ietf.org>; Tue, 4 Dec 2018 09:27:37 -0800 (envelope-from <Jackson.Shaw@oneidentity.com>)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneidentity.com; s=default; i=@oneidentity.com; h=Received: Received:Received:From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:Content-Type:MIME-Version; bh=fDUX1ZaICtJpb9VhD pOS4dYyM3gi0EEEVIcOF5Muj1Q=; b=KlvQZJCZZWV0ARuiNV8COZpU12RcJS18c FNDovI8w4hqDUSpFGgkdU9QEdRZl3DK1JWoNyvDxj0a6mufmaL3CZ9neNrD5n+ZE j2N/S9Fa+m0Xlr5qBN0wNeFERpb5MjXeNK9ijgXlg0ye4xzw9V5vcQeRgS8d1SeK DsUyCyLp7M=
Received: from ALVETXW04.prod.quest.corp ([10.1.100.92]) by amersmtp2.quest.com ([10.1.100.227]) (SonicWALL 9.0.5.2079 ) with ESMTPS (version=TLSv1.2 cipher=AES128-SHA256 bits=128/128) id o201812041727360208832-108; Tue, 04 Dec 2018 09:27:36 -0800
Received: from ALVHTXW02.prod.quest.corp (10.1.135.18) by mail.quest.com (10.1.107.111) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 4 Dec 2018 09:27:35 -0800
Received: from ALVMBXW01.prod.quest.corp ([fe80::cc5a:be3d:40e:3012]) by ALVHTXW02.prod.quest.corp ([::1]) with mapi id 14.03.0279.002; Tue, 4 Dec 2018 09:27:36 -0800
From: "Jackson Shaw (jshaw)" <Jackson.Shaw@oneidentity.com>
To: Phil Hunt <phil.hunt@oracle.com>, Jaap Francke <jaap.francke=40iwelcome.com@dmarc.ietf.org>
CC: "scim@ietf.org" <scim@ietf.org>
Thread-Topic: [scim] Retrieving members of a group
Thread-Index: AQHUi7i1HSuQH2+yFkGgfz/NvPWml6VvVSGA//+AkFA=
Date: Tue, 4 Dec 2018 17:27:35 +0000
Message-ID: <81058E390D0B3847B069D324750FCFF576B17C17@ALVMBXW01.prod.quest.corp>
References: <E95EE44D-FEE3-404B-B2BE-D31338DB82BE@iwelcome.com> <F4B4C160-078B-4C96-A642-4E104C17D165@oracle.com>
In-Reply-To: <F4B4C160-078B-4C96-A642-4E104C17D165@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.104.156]
x-c2processedorg: 0b7fb32a-9e41-4a01-8d60-ef67dd9ea696
Content-Type: multipart/alternative; boundary="_000_81058E390D0B3847B069D324750FCFF576B17C17ALVMBXW01prodqu_"
MIME-Version: 1.0
X-Mlf-CnxnMgmt-Allow: 10.1.100.92
X-Mlf-Version: 9.0.5.2079
X-Mlf-License: BSVKCAPE_
X-Mlf-UniqueId: o201812041727360208832
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/v_OMq9vUAiV3Np8g34NnPF_8V24>
Subject: Re: [scim] Retrieving members of a group
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 04 Dec 2018 17:27:42 -0000

Indeed. We are one of the ones who feel this question is not adequately addressed…

Jackson Shaw
Product Management, One Identity
☎ +1-425-577-1769

From: scim <scim-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Tuesday, December 4, 2018 9:03 AM
To: Jaap Francke <jaap.francke=40iwelcome.com@dmarc.ietf.org>
Cc: scim@ietf.org
Subject: Re: [scim] Retrieving members of a group

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Jaap,

You are correct that the SCIM protocol does not support sub-pagination of group members.

This question has come up several times since, so I’ll pass along my *personal* thoughts...

As group membership grows, the associated confidentiality of that list also grows. As such many service providers do not return member values except to privileged clients. Listing the members of a team is one thing, but listing the employees of a company, or all customers is quite another.

As group size grows, the change rate of a Group resource also grows. Many use cases for pagination assume that consistent results between pages would also be supported. That means the SCIM SP would have to maintain a query results buffer in order to return results while the data may be changing underneath. This impacts SCIM service providers in key ways:
* Scalability costs of providing consistent result sets
* Results consistency and increased shared state costs across clusters.
* Denial-of-Service risks associated as attackers perform seemingly innocent queries that consume undue resources. LDAP has this problem, and it is one of the reasons I never recommend LDAP for open internet use without some form of counter-measures.

Many of the use-cases I have heard are often driven by user-interface designs intended to aid users in scanning through a group. In my experience I’ve found these systems to be particularly tedious with large groups. The UX often ends up requiring a user-agent side search function so you can find names rather than page through hundreds of pages. This is in part why I suggest group management be done using user-centric calls (see below) or relationship basis like we see in large-scale social networks.

One could argue that group membership should never be returned and instead:
* Use queries against User resources to search for groups a User is a member of.
* Use a query filter against Group resources to test if a User is a member.

There are cases where privileged services need to synchronize or reconcile across domains. In these cases, it is important to return the entire group object as of a point in time so that consistency between systems can be periodically compared.

It’s quite possible the group may re-form to tackle this question down the road. After-all the pagination question keeps coming up and is worthy of more discussion IMO.

Cheers,

Phil Hunt


On Dec 4, 2018, at 2:04 AM, Jaap Francke <jaap.francke=40iwelcome.com@dmarc.ietf.org<mailto:jaap.francke=40iwelcome.com@dmarc.ietf.org>> wrote:

Hi all,

I would like to have my understanding confirmed on usage of the GROUP endpoint.

When I do a GET on the GROUP endpoint, the members attribute of a returned GROUP resoiurce contains a list of all members of that group.
If the group contains only a few members, that’s not a problem.
However, when the group contains a lot of members, the payload gets “too big” and pagination for the members does not apply.

I assume the way to solve this is to return a partial representation of the group resource by setting the schema metadata returned=never (or returned=request) in the group schema definition?
When doing so, a GET on the GROUP endpoint results in a list of groups with common resource attributes (id, externalid, meta) and group displayName.

To retrieve the list of members of a group, one would have to do a GET on the user endpoint using a filter on the groups attribute, right? In this case pagination does apply.

Your responses are appreciated, thanks!

Jaap Francke
_______________________________________________
scim mailing list
scim@ietf.org<mailto:scim@ietf.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_scim&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=LsCH7qZCjIgw_Y1OrhcvqpsjNdeYbp7rYDyNrjjTeCY&s=f5f3wOp9RMHmsloc2YdksmbnaxEwZbhvA-_nP6fujvI&e=