Re: [scim] Retrieving members of a group

Phil Hunt <> Tue, 04 December 2018 17:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A7CA130F7C for <>; Tue, 4 Dec 2018 09:03:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.759
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kq_6G6-uT83v for <>; Tue, 4 Dec 2018 09:03:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC7E7130F91 for <>; Tue, 4 Dec 2018 09:03:17 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id wB4Gwlu7111402; Tue, 4 Dec 2018 17:03:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 ( []) by 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 ( []) by (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 ( []) by (8.14.4/8.13.8) with ESMTP id wB4H3CdA012150; Tue, 4 Dec 2018 17:03:12 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Dec 2018 09:03:11 -0800
From: Phil Hunt <>
Message-Id: <>
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: <>
Cc: "" <>
To: Jaap Francke <>
References: <>
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: <>
Subject: Re: [scim] Retrieving members of a group
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Simple Cloud Identity Management BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Dec 2018 17:03:33 -0000


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.


Phil Hunt

> On Dec 4, 2018, at 2:04 AM, Jaap Francke <> 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