From Matt.Peterson@oneidentity.com Tue Jan 23 13:11:02 2018 Return-Path: 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 0C07A12D7F3 for ; Tue, 23 Jan 2018 13:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 uq4qF0GFT_HP for ; Tue, 23 Jan 2018 13:11:00 -0800 (PST) Received: from amersmtp4.quest.com (amersmtp4.quest.com [12.106.87.249]) (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 48EC312D7FB for ; Tue, 23 Jan 2018 13:10:59 -0800 (PST) Received: from amersmtp4.quest.com (127.0.0.1) id hcuie80171sc for ; Tue, 23 Jan 2018 13:10:59 -0800 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneidentity.com; s=default; i=@oneidentity.com; h=Received: Received:Received:From:To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:Accept-Language:Content-Language:Content-Type: Content-Transfer-Encoding:MIME-Version; bh=0BTYnZ5xP5g8zyBjP5wNT dPteoRJwyN+dsyN/9Nka14=; b=llIm1V5TvyIW81FtUcjRVV+ZToxVmrAjsqpYq uaojE8IQbeqecTqCsXsrJrWg5UVkILnL5Z9N420S+C8/cgyVgYQzt99Mggm0yH3W 2zxgFrKXhyRLibw62DFfRWnbQ6XLbZb0OyjX3A0F0DJdBRmRt17LY36qOXsPZkk+ J9WctA= Received: from alvetxw02.prod.quest.corp ([10.1.100.90]) by amersmtp4.quest.com ([10.1.100.249]) (SonicWALL 9.0.5.2075 ) with ESMTPS (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256/256) id o201801232110560424455-82; Tue, 23 Jan 2018 13:10:56 -0800 Received: from ALVHTXW01.prod.quest.corp (10.1.135.17) by ALVETXW01.alvetxw01.prod.quest.corp (10.1.100.90) with Microsoft SMTP Server (TLS) id 14.3.279.2; Tue, 23 Jan 2018 13:08:43 -0800 Received: from ALVMBXW01.prod.quest.corp ([fe80::cc5a:be3d:40e:3012]) by ALVHTXW01.prod.quest.corp ([::1]) with mapi id 14.03.0279.002; Tue, 23 Jan 2018 13:08:54 -0800 From: "Matt Peterson (mpeterso)" To: "scim@ietf.org" Thread-Topic: draft-grizzle-scim-pam-ext-01: Section 2.1 - Use URI instead of linkedObject, nativeIdentifier? Thread-Index: AQHTlI5fe66ZbgfZMEyIaf2+LDJDDA== Date: Tue, 23 Jan 2018 21:08:53 +0000 Message-ID: <7F2B7AC6C3EEDC4A9C067A7852FA8A2D4AA13648@ALVMBXW01.prod.quest.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.155] x-c2processedorg: 0b7fb32a-9e41-4a01-8d60-ef67dd9ea696 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-CnxnMgmt-Allow: 10.1.100.90 X-Mlf-Version: 9.0.5.2075 X-Mlf-License: BSVKCAPE_ X-Mlf-UniqueId: o201801232110560424455 Archived-At: Subject: [scim] draft-grizzle-scim-pam-ext-01: Section 2.1 - Use URI instead of linkedObject, nativeIdentifier? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 22:19:32 -0000 LinkedObject is not useful for a SCIM client or the SCIM service (e.g. PAM = software) unless the LinkedObject extension of a user or group contains suf= ficient information to actually resolve the LinkedObject. =0A= =0A= The draft intends to communicate that the "source" attribute identifies the= External Store containing the LinkedObject, and "nativeIdentifier" identif= ies the object within External Store (identified by "source"). =0A= =0A= The definition of a "source" attribute as being just a string is ambiguous.= The example in 2.1.1. highlights the ambiguity of "source" by using a "so= urce" value of "Corporate Active Directory". How, in a the common scenario= where PAM users/groups are being enumerated, is a SCIM client going to mak= e sense of a "source" value like "Corporate Active Directory"? In a scenar= io where PAM users/groups are being created by the SCIM client, how is the = SCIM client going to know how to generate a "source" value like "Corporate= Active Directory" that is meaningful to the PAM software? =0A= =0A= Using a URI (instead of a "source" and "nativeIdentifier") seems like a mor= e interoperable and explicit way to reference a LinkedObject. For example,= a URI scheme (RFC 4516) is standardized and well-known to developers for r= eferencing AD/LDAP objects. Using a URI has the advantage of allowing Lin= kedObject reference into a broad range of object stores (not just directori= es) that can be supported without future modification of the draft.=0A= From Matt.Peterson@oneidentity.com Tue Jan 23 14:07:34 2018 Return-Path: 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 9B70412D851 for ; Tue, 23 Jan 2018 14:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CMocN3_wwxZs for ; Tue, 23 Jan 2018 14:07:33 -0800 (PST) Received: from amersmtp1.quest.com (amersmtp1.quest.com [12.106.87.226]) (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 D255312D850 for ; Tue, 23 Jan 2018 14:07:32 -0800 (PST) Received: from amersmtp1.quest.com (127.0.0.1) id hcup220171s1 for ; Tue, 23 Jan 2018 14:07:29 -0800 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oneidentity.com; s=default; i=@oneidentity.com; h=Received: Received:Received:From:To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:Accept-Language:Content-Language:Content-Type: Content-Transfer-Encoding:MIME-Version; bh=b4R69xiRfMhSuQ0KyMudO aParzeARW9dCd1evcoZVr4=; b=qvkD+lLctWFk5YT/pP4A1xhZRPSjCKc18udvu knDpA8JFjqFhhac83YgU6fwixj4dfegaM13u4dHKI4+jTbhPRzUMztkFJrKwVcKS t6uYtp+BPs5o4Uqx0jSIuBsB/ofJxs4/GrFAoBzmBCCw3r6mI5Ispf65g74Uonb3 +nPYvQ= Received: from alvetxw02.prod.quest.corp ([10.1.100.90]) by amersmtp1.quest.com ([10.1.100.226]) (SonicWALL 9.0.5.2079 ) with ESMTPS (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256/256) id o201801232207290171308-106; Tue, 23 Jan 2018 14:07:29 -0800 Received: from ALVHTXW01.prod.quest.corp (10.1.135.17) by ALVETXW01.alvetxw01.prod.quest.corp (10.1.100.90) with Microsoft SMTP Server (TLS) id 14.3.279.2; Tue, 23 Jan 2018 14:05:29 -0800 Received: from ALVMBXW01.prod.quest.corp ([fe80::cc5a:be3d:40e:3012]) by ALVHTXW01.prod.quest.corp ([::1]) with mapi id 14.03.0279.002; Tue, 23 Jan 2018 14:05:40 -0800 From: "Matt Peterson (mpeterso)" To: "scim@ietf.org" Thread-Topic: draft-grizzle-scim-pam-ext-01: Section 3.3, 3.4 - behavior of authorization granted outside scope of SCIM Thread-Index: AQHTlJMVdX58bA4UQ0SkEP00CJc7gg== Date: Tue, 23 Jan 2018 22:05:39 +0000 Message-ID: <7F2B7AC6C3EEDC4A9C067A7852FA8A2D4AA13669@ALVMBXW01.prod.quest.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.155] x-c2processedorg: 0b7fb32a-9e41-4a01-8d60-ef67dd9ea696 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-CnxnMgmt-Allow: 10.1.100.90 X-Mlf-Version: 9.0.5.2079 X-Mlf-License: BSVKCAPE_ X-Mlf-UniqueId: o201801232207290171308 Archived-At: Subject: [scim] draft-grizzle-scim-pam-ext-01: Section 3.3, 3.4 - behavior of authorization granted outside scope of SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 22:21:11 -0000 SCIM itself is possible because there are common models for Identity manage= ment that are built into applications (users, groups, etc) that have been i= nherited through the mature patterns and legacy of X509 directories. SCIM = was an opportunity to standardize a simple protocol on top of a well-establ= ished model.=0A= =0A= It is notable that SCIM itself is explicitly NOT designed not for authoriza= tion management. SCIM recognizes that authorization models vary widely fro= m application to application and that SCIM would not be able to cover both = identity management and authorization management. =0A= =0A= True, an argument could be made that SCIM's ability to manage groups is a f= orm of authorization management, but in this case SCIM is on solid ground d= ue to the prolific use of "group of users" concept in software applications= . SCIM allows management of the "groups", not what the groups can do.=0A= =0A= SCIM specification makes several attempts to clarify the the scope of SCIM = using statements like the following:=0A= =0A= RFC 7643 section 4.2 -=0A= ...although no explicit authorization model is defined. It is intended= =0A= that the semantics of group membership, and any behavior or authorizatio= n=0A= granted as a result of membership, are defined by the service provider; = these are=0A= considered out of scope for this specification.=0A= =0A= The pam-ext draft suggests that there is a common authorization model that = would be interoperable for SCIM clients of PAM services. We are suspicious= . As evidence, there are several very important attributes that make up th= e proposed authorization model that are defined as implementation-specific,= free-form strings. =0A= =0A= PrivilegedData.type =0A= PrivilegedDataPermission.rights=0A= ContainerPermission.rights=0A= =0A= >From the perspective of a SCIM Client, the model presented has minimal inte= roperability value for a read-only (i.e. GET verb only) SCIM client, and al= most no interoperabilty value for a SCIM client that needs to actually writ= e (POST,PUT) to these collections.=0A= =0A= It would be good if there was more public discussion about whether or not t= he model described in the pam-ext draft in sections 3.3-3.4 is 1) Implement= able by PAM software, and 2) useful to SCIM client.=0A= =0A= =0A= =0A=