Re: [scim] Discovery support for SCIM

[Phil Hunt <[e-mail]>]

Chuck,

Thanks.  That too was my main objective.

Is there anything else that should be returned other than the URL for the SCIM server?  E.g. do we want a JSON structure that might convey multiple pieces of information?  E.g. authentication requirements and endpoints.

I am leaning towards just returning a URL and keeping the response simple since SCIM already has its own service specific discovery endpoints (e.g. /ServiceProviderConfig).

Phil

@independentid
www.independentid.com
[e-mail]

> On Sep 28, 2015, at 12:37 PM, Chuck Mortimore <[e-mail]> wrote:
> 
> We're interested, in the service discovery aspect.   Less so on the profile discovery / webfinger   
> 
> On Mon, Sep 28, 2015 at 11:58 AM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
> It’s now Monday after completion of the SCIM RFCs and I have already received a new enhancement request.  BTW thanks to everyone in the WG for all your efforts!
> 
> The request is to define discovery for SCIM. For example using the Well-known mechanism (RFC5785) and potentially WebFinger (RFC7033).
> 
> For example, a SCIM client may send the following query:
> 
> GET  https://www.example.com/.well-known/scim <https://www.example.com/.well-known/scim>
> 
> For which the server might respond with a URL to the appropriate SCIM server and path to the server root (e.g. "profile.example.com/scim <http://profile.example.com/scim>”).
> 
> In a more complex version with a webfinger (RFC7033) query:
> 
> GET https://www.example.com/.well-known/webfinger?resource=acct%3Abob%40example.com& <https://www.example.com/.well-known/webfinger?resource=acct%3Abob%40example.com&>
>         rel=scim-profile
> 
> Which responds:
>      HTTP/1.1 200 OK
>      Access-Control-Allow-Origin: *
>      Content-Type: application/jrd+json
> 
>      {
>        "subject" : "acct:[e-mail] <mailto:[e-mail]>",
>        "links" :
>        [
>          {
>            "rel" : “scim-profile",
>            "href" : "https://www.example.com/sciim/Users/bob-id <https://www.example.com/sciim/Users/bob-id>"
>          }
>        ]
>      }
> 
> 
> Overall, I see a few different use-cases:
> 
> 1.  A SCIM client simply wants to know where the SCIM Profile service is for a specific domain (e.g. tenacy.example.com <http://tenacy.example.com/>).
> 
> 2.  A SCIM client might be looking for a user’s profile service.  So it asks example.com <http://example.com/> where is [e-mail] <mailto:[e-mail]>?  This would be a WebFinger style query based on the well-known endpoint. The same WebFinger query could also return the OIDC endpoints as well as the SCIM endpoints for the user.  This may be useful for cases where service providers have multiple tenancies and there is a need to have a generic, tenancy neutral lookup service.
> 
> 3.  A SCIM client that has the service endpoint for a SaaS service (e.g. CRM, HCM, Finance) may be looking for the provisioning endpoint and the ResourceType and schemas relevant to the application.   For example, a client that wants to provision to a User to a Finance system, wants know where the Finance app provisioning endpoint is.  It could be an Finance SCIM endpoint or it may a profile service endpoint.
> 
> Questions:
> 
> A. Are there members of the WG interested in this?
> 
> B. From a protocol standpoint, it should not matter whether a client is talking to SCIM that is deployed in front of a business application (like CRM, Finance), vs. SCIM as a general User profile service. However, due to possible difference in the higher-level logic of the client, would it be important to distinguish between say “scim-provisioning” and “scim-profile” as distinct types of services?  If so, what do we think defines that difference?
> 
> Thanks,
> 
> Phil
> 
> @independentid
> www.independentid.com <http://www.independentid.com/>
> [e-mail] <mailto:[e-mail]>
> 
> _______________________________________________
> scim mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
>