Subject: Re: [scim] Scope change request

From: Erik Wahlström <[email-masked]>
Date: Tue, 3 Apr 2012 17:24:26 +0000

Hi,

I truly believe that the Consumer shall have no knowledge of the complexity that's behind a Service Provider. Once a SCIM Resource is created at a service provider, the consumer will loose control over the resource. The service provider can choose to store the resource within a sql-database, nosql-database, a file system, a directory or to sent it to one or more down streams scim service providers. It's the same logic as you do not know if a sql server is replicated or not while calling it.

This considered, isn't a reverse proxy a viable solution that would resolve the targeting requirement? A reverse proxy is good at targeting specific resources and you get the added features of logging, authorization and in some cases authentication.

Targeting have a couple of other challenges that we run into while developing the ScimProxy, a open source implementation that tries to solve this specific problem, but in a more transparent way. For example, the problem that's solved with accountRefs in the targeting proposal. It's good that it's there in some way because it must be handled by someone but isn't it enough that it's handled by the service provider and not by the consumer? See it as the magic of the somewhat special service provider (hub) hence leaving it out of the core schema.

If using versioning, the Consumer need to have one or many provisioning strategies for different targets. If a target has changed one of it's resources and hence it's version the consumer will get a conflict if making a PUT/PATCH/DELETE. The consumer must decide if it should fail the request, get latest version from the service provider and try a merge it with the current change, and if many targets is targeted possible rollback already changed resources. This is something that should be handled by a specialized service provider, not by the consumer.

Authentication is another thing. Should the hub keep track on the authentication methods and creds to the different targets or should the client do that and send it to the server. Targets using JSON or XML is another one.

Targeting opens up to many questions and a good reverse proxy or some hub-like scim implementations solves the problem without adding this complexity to the core schema making SCIM harder to implement. I would "hum" no for adding it to the charter at this moment.

It's great work though and I learned a lot reading the proposal. Nice work implementing everything as extensions.

Best Regards
Erik Wahlström

On Mar 29, 2012, at 1:56 PM, Phil Hunt wrote:

> I would like to request that the Targeting proposal presented today at the BoF be added to the charter for consideration.
> 
> A draft proposal has been submitted (new this week --> draft-hunt-scim-targeting) which shows how targeting could be done.
> 
> A brief summary:  When provisioning to a service provider that has multiple applications that may be provisioned, there are 3 alternatives:
> 
> 1.  Use schema extensions to objects (e.g. entitlements) to infer app requests
> 2.  Use separate domains and implement app specific endpoints (or combined multi-homed service)
> 3.  Use targeting for a RESTful explicit approach.
> 
> Item 1 IMHO leads to complexity and future inter-op problems.  Instead it is better to keep SCIM requests simple and app-specific.
> 
> As far as 2 and 3 goes, the proposal difference is:
> 
> app-tennantid.scim.cloud.com/Users/xxxxxx
> vs.
> scim.cloud.com/Targets/app-tennantid/Users/xxxxxx
> 
> The first one requires many more certificates to be issued and leads to complexity for things like proxies and load-balancers.  Putting the app target in the path is going to be logistically much easier to manage. It also means the semantics of the transaction are simplified because the operation is now focused on a specific application target.
> 
> I submitted the draft only to get the ball rolling and am very open to other ideas. I do however feel that this requirement is a deliverable that the IETF SCIM WG should address in the first round of specifications.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 
> 
> 
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Apr 2012 10:51:42 -0700

Erik,

I agree. I'm not saying the client has specific knowledge-quite the opposite.

In current practice i am told deployers use a single complex endpoint where the client must know a lot about site specific schema extensions and all the app services behind that scim SP. For example the client must know about how the SP models entitlements. The is  a somewhat directory centric view. 

In target mode a single operation is more narrowly defined in a logical way and is therefore simpler. Add xyz to crm is simpler than add xyz with extensions abc to directory. 

By routing all operations through a single SP the targeted ops can still be mapped, if desired, to a single common directory entry as before, but the clients perspective is simple and the sp architecure is flexible and can be firewalled.  

Regards

Phil

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 3 Apr 2012 20:18:03 +0000

Hi Phil,

Another approach would be to use the schema discovery end point by the consumer. The service provider can compile all data needed (and potentially any extensions that's needed) into one scim resource that the consumer sends and the service provider distribute it to all down steams servers. The service providers schema can be discovered using the schema end point and is compiled from all the attributes needed by using the schemas from all downstream servers. That means that the service provider can keep hiding the complexity.

If there is a need for many extension I guess a couple of missing attributes should be added to the core schema. The service provider can also define a good format for it's entitlements attribute to support all down stream servers.

Best Regards
Erik Wahlström

---

From: Phil Hunt <[email-masked]>
Date: Tue, 3 Apr 2012 14:03:16 -0700

Ok. If I work on your premise, we would have a single user object that is a conglomeration of accounts in many services.  In LDAP this often becomes unwieldy and is often broken into several entities. The inter-op issue comes in the form that different sites will do this very differently. In SCIM what happens when a User object is broken apart?

Consider when each service being provisioned has the possibility for Users to hold multiple accounts.  E-mail is one example that shows up in the new SCIM schema and where there is a complex attribute showing primary account etc. But what of other application scenarios where it is reasonable for users to have one or more accounts?  Hypothetically, consider AOL where I may have one or more email, AIM, or FlickR accounts. This gets awfully complex quickly trying to show an amalgamated entity.

What if instead the hub view showed that the hub Person was related to one ore more accounts in each system.? Thus each Flickr account in Flickr is a simple User object from the SCIM perspective. But, via the hypothetical AOL Hub there is a clear relationship between the User object there and the 2 or 3 FlickR accounts.

Likewise, Google has many different services where users may have many Calendar, Doc, or Blogspot accounts.

This model of single end-point is too simplistic IMHO and likely to quickly go insanely complicated.

Trey and I talked about some ways to do this without an explicit Targets object just using a path before the SCIM endpoints (e.g. scim.cloud.com/crm/tenant/Users/xxxxx). But I think this would require modification of the core specification to allow this. I'm neutral as long as inter-operability is not complicated.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 4 Apr 2012 13:57:22 +0000

I agree with Phil.  Lots of meta-directory software has been developed to try to give the single directory-centric view of a user.  If the service provider is sophisticated enough (and the data model simple enough), it is possible to give a single view of a user that can encompass data from other accounts.  As Phil mentions, this can fall apart very quickly for a variety of reasons (multiple accounts, data transformations, desire to see specific account-level attributes).  In these cases, it is much easier for the client to have a more direct view and explicit control over the targets.

I see a lot of value in targeting and would like to see it added to the charter as an extension to be worked on in parallel with the other core work.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, April 03, 2012 4:03 PM
To: Erik Wahlström
Cc: [email-masked]
Subject: Re: [scim] Scope change request

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-04-03, at 1:18 PM, Erik Wahlström wrote:

>>>> 1.  Use schema extensions to objects (e.g. entitlements) to infer 
>>>> app requests 2.  Use separate domains and implement app specific 
>>>> endpoints (or combined multi-homed service) 3.  Use targeting for a RESTful explicit approach.
>>>>

---

From: Trey Drake <[email-masked]>
Date: Wed, 4 Apr 2012 09:17:45 -0500

Hi Phil,

What are your thoughts on formalizing the spec to accommodate targeting via the URL scheme we discussed?  In my view, this can be handled as an operational/deployment decision vs something that must be formalized into the spec.  For example, supporting a multi-tenant deployment is shared by the majority of current contributors though we haven't yet prescribed the mechanics as some will want to work it out via the bound client (the authenticated principal), aspects of the url and/or attribute extension.  

Its worth noting that different tenants in a SCIM deployment could expose different schema and that's perfectly legit behavior in the current draft; e.g., https://example.com/tenant1/Schemas  and https://example.com/tenant2/Schemas are for all practical purposes separate backends.  In the same fashion an addressable 'target' aka 'app' could be expressed in this fashion w/o changing the current draft; e.g.,  https://example.com/crm/tenant1/Schemas and https://example.com/email/tenant1/Schemas

Given my understanding, the ugly in targeting is the need to provide a different resource schema for each target; e.g., 'User' attributes in the email target will be different than those of the crm target .  If an answer to targeting is to prefix the URL path to accommodate the target then we don't have to change the spec since the client (via configuration of some sort) will need to be smart enough to work out the targets it needs to address.  Conceptually this feels similar to multi-tenant handling.  If the client is expected to be 'dumb' (has no idea what targets it needs to address) a discovery mechanism will need to be introduced in the protocol.  is this an accurate assessment (the crux is what to do about schema)?

Thanks,
Trey

---

From: Phil Hunt <[email-masked]>
Date: Wed, 4 Apr 2012 08:10:32 -0700

I think it ia possible but then would you not have to formalize the (optional) behavior in the core spec along with AttributeRef schema change?

Either way is fine. 

Would it be better to define a person object that holds the references to user accounts in order to keep track of relations in the SP rather then extend user to point to user via relative URLs?

Phil

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 5 Apr 2012 12:21:56 +0000

> Would it be better to define a person object that holds the references to user accounts in order to keep track of relations in the SP rather then extend user to point to user via relative URLs?

If I understand it correctly it sounds like it's very Group-like or it could at least borrow a lot from the Group representation. Instead of a group representing users within a group it's a group of Users for a specific person.

/ Erik

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 5 Apr 2012 13:37:42 +0000

I don't know that we need a different person resource type.  Typically, top-level users and target users will have similar schemas.  Top-level users would have the additional account references and target users would potentially have some target-specific schema items (eg - mailboxSize, etc...).  Otherwise, most of the schema would be shared.

Regarding groups, while these are collections of users, the current schema doc describes them as "enabl[ing] expression of common Group or role based access control models".  Other than this, group is pretty thin, only containing id, externalId, displayName, and members.  Using this as a container for account references seems semantically incorrect.

It is imperative that targeting sticks with the "simple" part of SCIM.  To me, it feels like the current draft proposal of *optionally* adding a Targets resource and a small schema extension for top-level users fits this bill pretty well.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Wahlström
Sent: Thursday, April 05, 2012 7:22 AM
To: Phil Hunt
Cc: [email-masked]; Trey Drake
Subject: Re: [scim] Scope change request

/ Erik

---

From: "Diodati,Mark" <[email-masked]>
Date: Thu, 5 Apr 2012 23:05:36 +0000

I agree with Kelly.

Thanks,

Mark

-----Original Message-----
From: Kelly Grizzle [mailto:[email-masked]]
Sent: Thursday, April 05, 2012 8:38 AM
To: Erik Wahlström; Phil Hunt
Cc: [email-masked]; Trey Drake
Subject: Re: [scim] Scope change request

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Wahlström
Sent: Thursday, April 05, 2012 7:22 AM
To: Phil Hunt
Cc: [email-masked]; Trey Drake
Subject: Re: [scim] Scope change request

/ Erik

________________________________

This e-mail message, including any attachments, is for the sole use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Gartner makes no warranty that this e-mail is error or virus free.