Re: [scim] Charter discussion item: What are the use cases for having a SCIM cursors

"Matt Peterson (mpeterso)" <Matt.Peterson@oneidentity.com> Wed, 07 July 2021 18:47 UTC

Return-Path: <Matt.Peterson@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 8111C3A244E for <scim@ietfa.amsl.com>; Wed, 7 Jul 2021 11:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 jk9nEQElWvPr for <scim@ietfa.amsl.com>; Wed, 7 Jul 2021 11:47:36 -0700 (PDT)
Received: from NAM02-DM3-obe.outbound.protection.outlook.com (mail-dm3nam07on2131.outbound.protection.outlook.com [40.107.95.131]) (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 51EAA3A244B for <scim@ietf.org>; Wed, 7 Jul 2021 11:47:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mTdMKcntowIm/oCI5ItVQphf1jf1JGSLEJ+Wvzl3w43PszQW4MddsSAd4RgR5gd68d+YIKq40NTq72D38ZNMx/awTPejNgtnAHEYtGDMb1YyIXaoR0S5J7oLvdErcUCZKuqQKi5+5jbYTv8295h1N1ABM1Uq7zCd6KK/nDzYvnTKhBbJIUlhnJJazUgep5ryxWdv4A4f3BPD7fqELRg8bOOtLJdRADICvbCledZ1FlZZbMhGsvOK9ZBg5UL3gdc+Sztm3S+3dPKZwUOzx3U+R378TLhkdx27NaOdxUuoFxy9nAZ7lZfrSjyjsl07srO2D+uSLxDsc4h69u/2ePBOmg==
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-SenderADCheck; bh=HOFvOKHQDa+Mc+tul+8K7iYrohOI6iRZCM9hKTJRF4c=; b=FUQlp9j/bGBpNODjE2WhjgzQ0X5GVeuOZBSsCQ8QQnDim7jofQojZOcIfmL/Aej6jUgcTeTuBdiMB3GS2iYvI6uvAe1ypaGtXTIlYd5dxlCC41+l+pvNbyQjaDozxc5OR8h2bpe+BauE5OkjMtZPIThR8ApFJt9qKiLkMRyg30GfRbh3ubvDrwneAWe4NOqXCWm5y9LmeWpZFnwEpOwIuj/SPkH7EyKaWb4+idDCy/d96h+dtPSxD442U/LJQThr1mfv58l9eddgoyqrPjNLZHI01IBNy0tOQrEScQPNxNsnT6JUkn9BqxnMxjtJcjrsi9ZTSlEPrN7SMV3K8dOFCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oneidentity.com; dmarc=pass action=none header.from=oneidentity.com; dkim=pass header.d=oneidentity.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneidentity.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HOFvOKHQDa+Mc+tul+8K7iYrohOI6iRZCM9hKTJRF4c=; b=d3G/mly8y2GI4xP82dpSSluvLA2HLsrVMJ4cJP4HN21n2t5ogpLo37F3ICJ/qlEb88wIix/feQscjBL5/ERhzpqsQp+opKznnaFsSRx32sy+8gs2q79cgCtZWCiNxJVJ6CVRpgSHfdZzUr2UbaCDaJzqesk3EnNJLX7L8poyc6Itii8WzMZ9oOyToMbDS+oQmi0NoNCVXo6dnXlYjS71DnBZfNwKyi4sYWedqN7OZPZEIMQFM9/gSFMpKcWhP8ADMVHqb0e4/9Pc/oFHSi+HK4O0DM4qOH079a8XOeavxaPGjNqljW9yVBaLRrLgRsA7nRiRM0QtZlu0mPQ+F8yLPA==
Received: from MWHPR19MB0957.namprd19.prod.outlook.com (2603:10b6:300:a4::16) by MW3PR19MB4251.namprd19.prod.outlook.com (2603:10b6:303:4a::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19; Wed, 7 Jul 2021 18:47:32 +0000
Received: from MWHPR19MB0957.namprd19.prod.outlook.com ([fe80::b522:861b:b4aa:70d5]) by MWHPR19MB0957.namprd19.prod.outlook.com ([fe80::b522:861b:b4aa:70d5%12]) with mapi id 15.20.4287.033; Wed, 7 Jul 2021 18:47:31 +0000
From: "Matt Peterson (mpeterso)" <Matt.Peterson@oneidentity.com>
To: Phil Hunt <phil.hunt@independentid.com>, SCIM WG <scim@ietf.org>
Thread-Topic: [scim] Charter discussion item: What are the use cases for having a SCIM cursors
Thread-Index: AQHXc0uK7E+6kQq1VEmlMEPknSg5dKs3s5iQ
Date: Wed, 7 Jul 2021 18:47:31 +0000
Message-ID: <MWHPR19MB095795E416B23D8A6486F494E11A9@MWHPR19MB0957.namprd19.prod.outlook.com>
References: <AD34DA0D-63FF-4ADF-8F2A-7F43AE75416E@independentid.com>
In-Reply-To: <AD34DA0D-63FF-4ADF-8F2A-7F43AE75416E@independentid.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: independentid.com; dkim=none (message not signed) header.d=none;independentid.com; dmarc=none action=none header.from=oneidentity.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3c67e098-fb0b-4da5-fcb7-08d94177ada2
x-ms-traffictypediagnostic: MW3PR19MB4251:
x-microsoft-antispam-prvs: <MW3PR19MB4251E835835793154A2546EFE11A9@MW3PR19MB4251.namprd19.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WA3IuuzbtXWYvTot/Gj5NIZe0Cu1bc0ygMLF7ApB3x0qeQq4gnFA473jO5TRcWEA1PZhmbWN21tZ6S52ZxT1kH3sWoi5UB++c7MPyQgprLdI+9yV84B/Lh4nHgJTbDRtsOQb7IRyyJMdKuOHmarHh0asisI9ht29jMSrnEG76vDpSEzVzQJW3iQgy8d+MSbGwyniVk2jtmVi4RnBRbNk3lAm+1rr+ESWC2EWfS4lLLcomEoHk5z7fHHs6FurAoep7heo5AuE42o+UbC+yh3xEaP4Gg4WHl4PSxWL/ogC1NnTpu2STRQhGVUIIzmVcZhp0u+9plcBHloacOT5wgIw79arQoZSEw6mgMKcE0ZjXmAR7oHWvra3O09mKskPwAt61pb0MN/O+9YFtWPZOXRyatGjnzv7hklHJk8KxOo2q+rdwFXvPoLzm3HFHurq75gYzMOL7xjYupym4X7cBLWqY4iIvUjWuE6L9Pmh+1cMRQLeUcgn/FKWnK79ufqrCGBXZ/cVTilePMDXWx6A0ivdgg8XngFUFxwB9U4QseMNcxr+TKcc96DGY1qiViFadKD4w8WeObaM+a+AdBODsjjGBpNyQSwhzn8vtyi1j2ZLzk4WrS31k5Pv7iZZXTr7eOrRg3WntbHIqf/xIrg5y9U5rPAOPN0MiQniHus/pHxUPVqF8mf4ebxXCN+OVajyhlxlIlkuy6WhmG8LaS0fVtaLO3t3dImjgdpM3KF6DBMJEuU=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR19MB0957.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(396003)(346002)(366004)(376002)(136003)(5660300002)(478600001)(122000001)(66446008)(33656002)(64756008)(8936002)(66556008)(86362001)(66476007)(7696005)(966005)(52536014)(38100700002)(8676002)(66946007)(71200400001)(316002)(76116006)(55236004)(53546011)(26005)(6506007)(83380400001)(110136005)(2906002)(186003)(9686003)(55016002)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZXlvMjNuYVo2UkxRbDJVNEQ3RDBlWEIySzFkcFhDeGE5ZDR5V1hHTkVQWmVw?= =?utf-8?B?eGtMNGVBRlA5RzN5OFVFMDFiNGRmd0RucW82QWtuV1MvTGhTOWdZWnJmUERI?= =?utf-8?B?dnJMZmZmb1BsZFdOZ0Z2S0FRNzJRSENMNUxzenlNSnJZZDI1a1dZaFMvWWdq?= =?utf-8?B?QTdaZUlqeXUrLzdQdmhNV2xUL3RxeW5yb0pTdVJpa0YrZE96OVViVFlrbytr?= =?utf-8?B?OTkvR0k2SnFOS3NZci9VWEI0S2l3dXJ1dVVvamI4WnVnK3JnVjR2UHJkZ2pr?= =?utf-8?B?RWdLOXJVQlJtN2VCT1h6WHVibzhERG1PRUt4U3EzWXIzRGFhVlhCZGJNcDh4?= =?utf-8?B?bGl1Mmh5c1dzNEdnZUlndWxKUW5MSXlJREEzU1VpMjJLd2JpeGl4a2RTRVZE?= =?utf-8?B?cWtjcXFZeitlZGJYM2lTYVhRYi83cnV0b0E1cUt0V1VRVjRTeHhnc2tSbTZy?= =?utf-8?B?SUo2SWo3ejFISk1HaTN4czNDKzJwdHZJR0JJRDBuZnZNcjZYem9sSGJKV1Zs?= =?utf-8?B?VStRcVlrMzduRnRhbTdyTy8vYitUdWlOMzgyU3I4REJjOE9VYlRIK2loY2hW?= =?utf-8?B?N1ZNM2x0VmZWOUtvKzZJWGVqNnhFbDZSNUFrSGp4TXlxOTkwOS9ROWRoSlU1?= =?utf-8?B?TXo1bFRuNUtXK1B1UGlYMUV0WFh4aGUxaENobG9HVmVvODVUcmtYbk5UZmFP?= =?utf-8?B?SFYzckpqWFJTd010TnJQNm5aeDJWb2NwSkh2cDRvMHNrdndFVEJ6NHVyMTJu?= =?utf-8?B?dGo0cStTZ1RkaG01ekZCTnRiMyt6SG5RY1BRdlpUNHcrWmNjNmUzRlI2Rkkv?= =?utf-8?B?ZUhYM3FFalVXWmp4Vjc2ek1keThMbEhoL2J5NUZUOGtOTmpXbGpBaFMrZjZa?= =?utf-8?B?QnNqY1NWei9mT0JCZk5aeEJGenJjRUcySFhqejRxYzdvMTJGWlhPVFZoNmpC?= =?utf-8?B?WUZWcUtEY3Mra1lkbmtOcTZGeXc3cUdGVG5TVW9SODZnUWRueXQrc1VMaWk2?= =?utf-8?B?Tk1lREZyUWZxT3pUOVlkSVZXZDRnV1NZLzM4YzA0WGZnTm1JeVJCUlBkYmM1?= =?utf-8?B?bmhJOHozMXk2NWtGempLNUtTVWxVR1NoVURiOWZwZEp3RVRFeDV1OEtLNFZy?= =?utf-8?B?TTMzNFlmcWQzV0pqVTFnc050MHJMYXBNa0FTbU9yZko0RHp0a0wzUy9zdDNW?= =?utf-8?B?Z2RGejZabVRxT1ZqVi9JVk5PMStaMU93enk3NW85dnlGZ3JETk9VTGlWd0pm?= =?utf-8?B?cWZJN0s2WWpCU1QrREZoRWNrSGlsVmhWYnAzMkVyamRubW9Uejk0VVROMUpj?= =?utf-8?B?TTBSUmJNbVh2eUdFeHJKdWxscXEyK0puYkVhY0tpRmFTY2ZNbkU5NG1zYVN0?= =?utf-8?B?bG1tVHJqK3V1djRUUjlwZzlSWTIrUk56dVhDb1ZLZVlCa0pxTzlOMDJCRGZL?= =?utf-8?B?Yk1QbXdIRk1iNUYwaENJT3I3cFJ6Qm5VZjNDbXIxaHZ2MldYeXZteDFxcE5i?= =?utf-8?B?UzRiYlFvcVpQT3lRbWMyUUJIVnkyd0NnWWUvTm93U0djZHlSZDBUWkZCcnhD?= =?utf-8?B?bTdsVHVTdGZnU3dBMms2citpZHhFYS96b0IraWNOaHZVaWhqemhNYjZIVmE4?= =?utf-8?B?cmhnVUdyQ2Y0MnFOdVF3UlBxZjBoOElEU2dVcnpIVUtRUGdmeEs1b05FZHFt?= =?utf-8?B?V1k4bFRaYXlsK2dZVzJSWWpNZWNSWFh2bjZKYWpPR0xzZXdxMy9JejA4MDJu?= =?utf-8?Q?LrIMRU9E4aEGSgfkIRzCYcwtIkRlbrdLKPIyV+F?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB095795E416B23D8A6486F494E11A9MWHPR19MB0957namp_"
MIME-Version: 1.0
X-OriginatorOrg: oneidentity.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR19MB0957.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c67e098-fb0b-4da5-fcb7-08d94177ada2
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 18:47:31.8769 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 91c369b5-1c9e-439c-989c-1867ec606603
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RiKDrsposnC4ycKojEDVTyPAvQvZI64pIzSbxBeDx/47vCMfo+DL5vC3oCFTNKbL8Ksf+bzVIPzFydXYO0JGvg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR19MB4251
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/AC0sYJfZh_7tf4RbpPY9oh0ayzA>
Subject: Re: [scim] Charter discussion item: What are the use cases for having a SCIM cursors
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: Wed, 07 Jul 2021 18:47:42 -0000

Phil,

In order to implement index/offset pagination in SCIM on top of an API or database that uses cursor pagination, the SCIM Service Provider must fetch the entire result set (i.e. iterate on the cursor to completion), then store the full result set in order to serve (via SCIM) a specific indexed page.   This resource intensive translating between cursor pagination (the backend protocol/database) and SCIM index pagination (SCIM) was a showstopper for our implementation which uses low cost “serverless” (AWS Lambda, Azure Functions) architecture.

We have implemented “front end” SCIM Service Provider for all of the “back-end” services in this list: https://www.cloud.oneidentity.com/products/connect/connectors and we found that the majority of the web protocols that we were calling on the “back end” use SCIM service provider use cursor pagination.  We would only have been able to support a fraction of these application without implementing the scim-cursor-pagination draft.

I recognize that my use case of a SCIM Service provider with dozens of “backends” is not common.  However, the frequency with which we encounter cursor pagination in existing APIs and protocols seems like an important consideration for the SCIM workgroup.  For example, one does not even need to venture farther than adding a SCIM interface on top of LDAP to encounter the pagination translation problem described above.

As for why SCIM clients need to query SCIM Service Provider to obtain large result sets, here is what we have encountered:


  1.  Constructing and enforcing Application authorization models -  An application (acting as a SCIM client) downloads users/groups from an IdP in order to present views to application administrators that are used to create RBAC, Policy and ACL authorization rules.  Enforcement-time authorization decisions need to be made quickly such that authorization-time calls to SCIM service provider is not viable which is why many applications maintain an “sync’d” application-side cache of users and groups.
  2.  Identity Management and Governance systems – Use a “canonical” identity model where all accounts and groups are represented.  This model is used to create provisioning rules and calculate separation of duty violations, attestations, and approvals etc.   Management-time evaluation of the model needs to be done efficiently without blocking calls to connected systems.

In both 1 and 2 (above) the there is an *initial load* of objects into the SCIM client’s data model and then subsequent use of SCIM to keep client’s data model with changes on SCIM Service Provider.

Pagination is desirable for the initial load of all objects.  However, the subsequent up-to-date maintenance of a client’s copy (cache) of the results is not necessarily a good use case for pagination.  For example, the need to re-request all objects in order to detect a deleted object is something that could be made much more efficient and should be addressed separately from the pagination topic.

I have posted to this mailing list about “Maintaining SCIM client-side cache consistency with SCIMv2”.  See post with this same subject: (https://mailarchive.ietf.org/arch/msg/scim/P5DVTqWLmVKqyvD0dgUszADQZrE/).  There were no public responses to this thread, but I still believe that this is a VERY common pattern.   I did receive a good private response from Phil Hunt who suggested use of “ETags and RFC7232 Http Conditional requests” – an approach definitely worth discussing.

As feedback to our charter draft, I believe that there is enough interest in two distinct areas to merit mention in the charter:


  *   “Pagination of large data sets” - including interest in pagination of multi-valued attributes.  Yes, I think that object pagination and attribute pagination could be considered in the same topic.  Group membership is the primary use case for large multi-valued attributes. I believe the group membership use cases can be addressed with object pagination and best practice filters (see https://mailarchive.ietf.org/arch/msg/scim/oZ3DcI15AOvA519rH5sRtJOJV2A)”.  Another alternative Dale Old’s suggestion this morning, of a “GroupMembers collection” (which would allow use of object pagination for group members and, probably easier detection of group membership changes).
  *   “Maintaining SCIM client-side cache consistency with SCIMv2” (https://mailarchive.ietf.org/arch/msg/scim/P5DVTqWLmVKqyvD0dgUszADQZrE/).  )

--
Matt Peterson
matt.peterson@oneidentity.com

From: scim <scim-bounces@ietf.org> On Behalf Of Phil Hunt
Sent: Wednesday, July 7, 2021 10:17 AM
To: SCIM WG <scim@ietf.org>
Subject: [scim] Charter discussion item: What are the use cases for having a SCIM cursors

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

As promised on the call today, this is to follow up and ask for use cases for people who want to use cursors. I think this would be helpful to understand in order to drive to a common purpose and solution.

For example, today I think I heard:
*  Some clients want to confirm resources have been deleted.   Why does this come about? SCIM already returns a definitive success/fail upong HTTP DELETE. Is it a case of co-ordination between multiple clients?

* Is it used to re-concile (e.g. meta-directory style)  between disparately managed systems periodically?

* Others reasons?

Can the use of cursors be confined to “specialized” clients where cursor might be consider a special “priviledge”.  IOW….would you allow javascript UI components to use cursors against your SCIM server?

Phil Hunt
@independentid
phil.hunt@independentid.com<mailto:phil.hunt@independentid.com>