Subject: [scim] Is ServiceProviderConfig Required?

From: Danny Mayer <[email-masked]>
Date: Wed, 13 Oct 2021 11:24:38 -0400

I've been looking at some SCIM servers and it seems that some do not 
provide the ServiceProviderConfig endpoint and at least one Commercial 
SCIM Client didn't request the endpoint when I was testing it last year. 
Is it a requirement to provide this endpoint and is the client required 
to read it and obey the rules laid out in the returned information? Are 
clients using it?

I'm also not sure about the /Me endpoint. That requires that the SCIM 
server retain state. That should be the SCIM client's responsibility.

Danny

---

From: Phillip Hunt <[email-masked]>
Date: Wed, 13 Oct 2021 08:57:54 -0700

Inline

Phil

> On Oct 13, 2021, at 8:24 AM, Danny Mayer <[email-masked]> wrote:
> 
> I've been looking at some SCIM servers and it seems that some do not provide the ServiceProviderConfig endpoint and at least one Commercial SCIM Client didn't request the endpoint when I was testing it last year. Is it a requirement to provide this endpoint and is the client required to read it and obey the rules laid out in the returned information? Are clients using it?

ServiceProviderConfig is the standard way to do functionality, schema and resource type discovery. 

As a discovery feature it is technically optional. It does seem silly not to implement it since for many its fairly simple to implement. 

I have heard of many smarter clients that use it. I2scim.io client does discovery to defines its own schema to match. 
> 
> I'm also not sure about the /Me endpoint. That requires that the SCIM server retain state. That should be the SCIM client's responsibility.

Not sure what you mean here. The server just uses the authorization header to locate what /Me refers to.  Eg matching username or sub claim. 

> 
> Danny
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Danny Mayer <[email-masked]>
Date: Wed, 13 Oct 2021 12:45:29 -0400

Inline too!

> I have heard of many smarter clients that use it. I2scim.io client does discovery to defines its own schema to match.
I think it should be REQUIRED to both implement and used. Having the 
client know what it can and cannot do seems to be essential especially 
as the client requests will be rejected (hopefully) if the client makes 
a request that it has already been told that it will not allow. Change 
Passwords come to mind as an example.
> Not sure what you mean here. The server just uses the authorization header to locate what /Me refers to.  Eg matching username or sub claim.

That sounds dangerous from a security point of view. If an employee is 
able to make a call and authenticate themselves they could potentially 
change their own access permissions. On my SCIM Server implementation, 
only the authorized SCIM client was allowed to make any changes (and 
could not do it to their own account).

Danny

---

From: Phillip Hunt <[email-masked]>
Date: Wed, 13 Oct 2021 12:51:27 -0700

Regarding SPC (ServiceProviderConfig)….we can certainly discuss this as part of the “discovery” features in the charter.  Just an FYI, its pretty non-trivial to change MAY to MUST in any spec. It would likely have to be part of an overall SCIMbis effort.

On the /Me stuff. I’m not seeing the problem. The only thing a SCIM server needs to know is how to map the credential to a scim resource.  Section 2 of RFC7644 discusses the required (MUST) need to map the client to an authorization policy that permits the action. For example, I believe PingIdentity uses a model evolved from LDAP ACIs as does i2scim.io (https://i2scim.io/AccessControl.html).

From RFC744 Section 2:

   Regardless of methodology, the SCIM service provider MUST be able to
   map the authenticated client to an access control policy in order to
   determine the client's authorization to retrieve and update SCIM
   resources.  For example, while a browser session may have been
   established via HTTP cookie or TLS client authentication, the unique
   client MUST be mapped to a security subject (e.g., User).  The
   authorization model and the process by which this is done are beyond
   the scope of this specification.

   When processing requests, the service provider SHOULD consider the
   subject performing the request and whether or not the action is
   appropriate given the subject and the resource affected by the
   request.  The subject performing the request is usually determined
   directly or indirectly from the "Authorization" header present in the
   request.  For example, a subject MAY be permitted to retrieve and
   update their own "User" resource but will normally have restricted
   ability to access resources associated with other Users.  In other
   cases, the SCIM service provider might only grant access to a
   subject's own associated "User" resource (e.g., for the purpose of
   updating personal contact attributes).

Phillip Hunt
@independentid
[email-masked]

> On Oct 13, 2021, at 9:45 AM, Danny Mayer <[email-masked]> wrote:
> 
> Inline too!
> 
> I think it should be REQUIRED to both implement and used. Having the client know what it can and cannot do seems to be essential especially as the client requests will be rejected (hopefully) if the client makes a request that it has already been told that it will not allow. Change Passwords come to mind as an example.
> That sounds dangerous from a security point of view. If an employee is able to make a call and authenticate themselves they could potentially change their own access permissions. On my SCIM Server implementation, only the authorized SCIM client was allowed to make any changes (and could not do it to their own account).
> 
> Danny
> 
>> 
>>> Danny
>>> 
>>>