Re: [scim] Discovery support for SCIM

I like that approach Phil

On Tue, Sep 29, 2015 at 2:10 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

> 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
> phil.hunt@oracle.com
>
> On Sep 28, 2015, at 12:37 PM, Chuck Mortimore <charliemortimore@gmail.com>
> 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 <phil.hunt@oracle.com> 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
>>
>> 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”).
>>
>> In a more complex version with a webfinger (RFC7033) query:
>>
>> GET
>> 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:bob@example.com",
>>        "links" :
>>        [
>>          {
>>            "rel" : “scim-profile",
>>            "href" : "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).
>>
>> 2.  A SCIM client might be looking for a user’s profile service.  So it
>> asks example.com where is phil.hunt@acme.com?  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
>> phil.hunt@oracle.com
>>
>> _______________________________________________
>> scim mailing list
>> scim@ietf.org
>> https://www.ietf.org/mailman/listinfo/scim
>>
>
>
>
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>

-- 
Ian Glazer
Senior Director, Identity
+1 202 255 3166
@iglazer <https://twitter.com/iglazer>