Re: [scim] Does SCIM have an access rights model?

Phil Hunt <phil.hunt@oracle.com> Mon, 27 March 2017 15:53 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 12885126B71 for <scim@ietfa.amsl.com>; Mon, 27 Mar 2017 08:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.995
X-Spam-Level:
X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ffnGve5FR5xw for <scim@ietfa.amsl.com>; Mon, 27 Mar 2017 08:53:13 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 DBC5612945D for <scim@ietf.org>; Mon, 27 Mar 2017 08:53:12 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v2RFrBQu006422 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Mar 2017 15:53:12 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v2RFrB3B032111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 15:53:11 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v2RFrBUH023532; Mon, 27 Mar 2017 15:53:11 GMT
Received: from dhcp-93f3.meeting.ietf.org (/31.133.147.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 27 Mar 2017 08:53:11 -0700
From: Phil Hunt <phil.hunt@oracle.com>
Message-Id: <3B3D6357-F46A-489C-A3BB-358DEB082BD7@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_28994A82-8FC3-4D52-AC34-BCD58E97A146"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 27 Mar 2017 10:53:02 -0500
In-Reply-To: <e89ef324-b861-708a-85d3-6a1529675be4@switch.ch>
Cc: scim@ietf.org
To: Rolf Brugger <rolf.brugger@switch.ch>
References: <5dd746c7-647b-ad0f-a8cf-ad9c3ca8df7c@switch.ch> <5675DA25-C333-45E0-A5BB-AD88B20BFF83@oracle.com> <e89ef324-b861-708a-85d3-6a1529675be4@switch.ch>
X-Mailer: Apple Mail (2.3259)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/scim/jLX4PU-VUwWWEj0d3OfXRQL4YvE>
Subject: Re: [scim] Does SCIM have an access rights model?
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 27 Mar 2017 15:53:15 -0000

No problem. I believe you are free to innovate where it makes sense in the context of your application.

Note that as a profile of HTTP, SCIM has to follow the HTTP specifications.  We have made some clarifications as to HTTP status response meanings in the context of SCIM.

Phil

Oracle Corporation, Identity Cloud Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>











> On Mar 27, 2017, at 10:50 AM, Rolf Brugger <rolf.brugger@switch.ch> wrote:
> 
> Hi Phil,
> 
> It does make sense to me that a model to manage access rights for SCIM clients to a SCIM server is out of scope - mostly because it very context dependent.
> 
> In our use case we have to limit access rights of SCIM clients, and I just wanted to make sure that we are not re-inventing the wheel.
> 
> So thank you your answer. That was very helpful!
> 
> cheers
> 
> Rolf
> 
> 
> On 27/03/17 16:55, Phil Hunt (IDM) wrote:
>> Rolf
>> 
>> Thanks for your question.
>> 
>> At the moment SCIM is a provisioning protocol and access rules are up
>> to the service provider. Eg What makes sense for a directory may not
>> make sense for a crm system.
>> 
>> Regardless, the consequences to the client are still the same-success
>> or unauthorized. :)
>> 
>> For historical context a similar discussion happened in LDAP. While
>> requirements had consensus no interoperable model was defined.
>> 
>> With all that said, I think it may be useful to have discussions
>> about lan oauth scope standard that could enable clients to request
>> certain rights. Eg ability to query as a directory. Ability to do
>> self updates etc.
>> 
>> This became more apparent when we wrote the oidc scim profile as
>> clients wanted an access token with user self service rights instead
>> of read only access at the oidc userinfo endpoint.
>> 
>> Phil
>> 
>>> On Mar 27, 2017, at 9:15 AM, Rolf Brugger <rolf.brugger@switch.ch>
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm new to this list, and I hope my question is relevant to this
>>> community.
>>> 
>>> In our particular use case we have one SCIM server and multiple
>>> SCIM clients. All clients are allowed to query all identities and
>>> all attributes.
>>> 
>>> However, not all clients have the same permissions to update/write
>>> attributes. For example, some clients may only modify group
>>> memberships of identities, while other clients have the exclusive
>>> permission to modify name and email of identities.
>>> 
>>> Is there a model in SCIM or some kind of best practice in existing
>>> implementations how to model client read/write permissions for
>>> attributes?
>>> 
>>> best regards
>>> 
>>> Rolf
>>> 
>>> -- SWITCH Rolf Brugger, Trust & Identity Werdstrasse 2, P.O. Box,
>>> 8021 Zurich, Switzerland direct +41 44 268 15 89
>>> rolf.brugger@switch.ch,
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.switch.ch&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WmnYxVYjsRE1_cESvAJdAHdRQ3MCyAZb2HHTClsca_U&s=AN-ijCyAYZPgh5_id4zq-F0lgoKH7iHfL1Hyxn5H5Wg&e=
>>> _______________________________________________ scim mailing list
>>> scim@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WmnYxVYjsRE1_cESvAJdAHdRQ3MCyAZb2HHTClsca_U&s=18i8xxKNQ5Kt6BoRZ2uBLo4GL-gB9ZWkzfQhwK8z6uA&e=
>> 
>>> 
>> _______________________________________________ scim mailing list
>> scim@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=rhrL9frOOOJ1GNPuLsvDgauqPWURGhFr8AT0eiBF3Fs&s=d9nM8LNKtuwsKP-gjdDyKX1YqZxzqEmcF72B4XJBKmM&e= 
> 
> -- 
> SWITCH
> Rolf Brugger, Trust & Identity
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> direct +41 44 268 15 89
> rolf.brugger@switch.ch, https://urldefense.proofpoint.com/v2/url?u=https-3A__www.switch.ch&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=rhrL9frOOOJ1GNPuLsvDgauqPWURGhFr8AT0eiBF3Fs&s=fvcplE2qxGwfHwc_l9TCZtohuy5-fIhgyC3QWV1Xt_g&e= 
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=rhrL9frOOOJ1GNPuLsvDgauqPWURGhFr8AT0eiBF3Fs&s=d9nM8LNKtuwsKP-gjdDyKX1YqZxzqEmcF72B4XJBKmM&e=