Re: [scim] Retrieving members of a group

Phil Hunt <phil.hunt@oracle.com> Tue, 04 December 2018 17:03 UTC

Return-Path: <phil.hunt@oracle.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 5A7CA130F7C for <scim@ietfa.amsl.com>; Tue, 4 Dec 2018 09:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.759
X-Spam-Level:
X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 (2048-bit key) header.d=oracle.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 kq_6G6-uT83v for <scim@ietfa.amsl.com>; Tue, 4 Dec 2018 09:03:17 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 AC7E7130F91 for <scim@ietf.org>; Tue, 4 Dec 2018 09:03:17 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wB4Gwlu7111402; Tue, 4 Dec 2018 17:03:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=WL/1HUdLHzYmtMGN2T9h9tpkzF9DD2WNaV07xchcoLc=; b=OdmTCFjAJUFiCYb5uuZokUh3j/SIPmAl8+xPm6EGOV8XaNdz1QkltFafBiMe+0XtPkxV qZ3i64E+mLiBBlb0FiooztSgGjXZ6If/rRejYBuCIMTr1lrwt5jWwMTgXUf+VtPB9/oC qNSr7Xzo39GpGMgDXi3sS+wnPlsWs6cbCVIzO7yKaZGyiBB4uwVEnn08I4FI4wD0QAfp uJE9DgF5mGuHiWwp4xA8BRX9MlUhvFAoFpXTSKYKgNB1mMV3OXcbu9I+Bo+dLH+fkky1 obQpgAcjYhmyzH84ZYdpRWFRGSm9icVY6UvpQCibxWnkgDhuqq4kpdI83JdE4EK7M8fv VQ==
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2130.oracle.com with ESMTP id 2p3hqtwry1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 04 Dec 2018 17:03:13 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id wB4H3C5Y029892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 4 Dec 2018 17:03:12 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id wB4H3CdA012150; Tue, 4 Dec 2018 17:03:12 GMT
Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Dec 2018 09:03:11 -0800
From: Phil Hunt <phil.hunt@oracle.com>
Message-Id: <F4B4C160-078B-4C96-A642-4E104C17D165@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CDBD88A4-E3D6-49FB-911E-647BA70F4A3D"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Tue, 4 Dec 2018 09:03:09 -0800
In-Reply-To: <E95EE44D-FEE3-404B-B2BE-D31338DB82BE@iwelcome.com>
Cc: "scim@ietf.org" <scim@ietf.org>
To: Jaap Francke <jaap.francke=40iwelcome.com@dmarc.ietf.org>
References: <E95EE44D-FEE3-404B-B2BE-D31338DB82BE@iwelcome.com>
X-Mailer: Apple Mail (2.3445.101.1)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9097 signatures=668686
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812040145
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/BelwTfWPY54IWICvBAkk_7obZaM>
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:03:33 -0000

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> 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
> 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=