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

From: Rolf Brugger <[email-masked]>
Date: Mon, 27 Mar 2017 16:15:56 +0200

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
[email-masked], https://www.switch.ch

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 27 Mar 2017 09:55:32 -0500

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 <[email-masked]> wrote:
> 
> Hi all,
> 
> 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
> [email-masked], 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
> [email-masked]
> 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=

---

From: Rolf Brugger <[email-masked]>
Date: Mon, 27 Mar 2017 17:50:09 +0200

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:
> 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.
>
> 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
>
>> 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.
>>
>> 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.
>>
>> -- SWITCH Rolf Brugger, Trust & Identity Werdstrasse 2, P.O. Box,
>> 8021 Zurich, Switzerland direct +41 44 268 15 89
>> [email-masked],
>> 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
>> [email-masked]
> _______________________________________________ scim mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/scim
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 27 Mar 2017 10:53:02 -0500

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/>[email-masked] <mailto:[email-masked]>

> On Mar 27, 2017, at 10:50 AM, Rolf Brugger <[email-masked]> 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.
> 
>> [email-masked] 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
> [email-masked], 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= 
> 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=