Subject: Re: [scim] Organizational unit SCIM extension

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 25 Mar 2015 16:47:44 +0000

If you are talking about hierarchical organization of resource instances,
we had that discussion in the very early days of SCIM 1.0 work. I actually
think I brought that up as a request but after talking to other vendors it
seemed every SaaS service was doing a flat name space for users & groups
and nobody had a request from customers for a hierarchical model so the
feature was dropped.

Cheers,
Morteza

On 3/24/15, 6:54 PM, "Haavar Valeur" <[email-masked]> wrote:

>Has there been any discussion around a standard SCIM extension that
>handles organizational units (OU)? A quick google search came up with a
>couple of emails from 3 years ago, but no real subsidence.
>
>If there has not been any discussion around this, is there a reason for
>it?
>
>Best
>Haavar
>_______________________________________________
>scim mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/scim

---

From: Haavar Valeur <[email-masked]>
Date: Wed, 25 Mar 2015 19:33:47 +0000

I think having the OUs be hierarchical should be an option if an extension was added, but even without that I would think that it’s beneficial to have OUs in the API. Without OU represented in the schema you would have loose references to objects that are created with proprietary APIs or schemas.

I’m a little surprised that the consensus was that SaaS providers have a flat OU structure. From what I’ve seen, a lot of providers support a hierarchy (with a some notable exceptions). I would think it would be a common use case for larger customers of a SaaS provider to sync their employee directory to the provider, including OUs. The OUs would be used to set password polices, federated login settings and administration or product privileges on the SaaS provider side. 

Have the SaaS providers changed this over the years, or do I have the wrong impression?

> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) <[email-masked]> wrote:
> 
>> https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9SiEHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim
> 
>

---

From: Ian Glazer <[email-masked]>
Date: Wed, 25 Mar 2015 16:11:28 -0400

In our case we have a flat-ish model. We can represent OUs and a hierarchy
but it is represented on the user object and not as a standalone
organizational structure

On Wed, Mar 25, 2015 at 3:33 PM, Haavar Valeur <[email-masked]>
wrote:

> I think having the OUs be hierarchical should be an option if an extension
> was added, but even without that I would think that it’s beneficial to have
> OUs in the API. Without OU represented in the schema you would have loose
> references to objects that are created with proprietary APIs or schemas.
>
> I’m a little surprised that the consensus was that SaaS providers have a
> flat OU structure. From what I’ve seen, a lot of providers support a
> hierarchy (with a some notable exceptions). I would think it would be a
> common use case for larger customers of a SaaS provider to sync their
> employee directory to the provider, including OUs. The OUs would be used to
> set password polices, federated login settings and administration or
> product privileges on the SaaS provider side.
>

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

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 25 Mar 2015 20:11:41 +0000

To be clear my previous response to your email and this email are with me
wearing implementer hat and not speaking as chair.

I can¹t see how we could add the OU hierarchy as an extension of the SCIM.
That would be a pretty intrusive change and require changes to almost
everything in SCIM. However, if you have ideas how this could be done, I
would love to hear them.

Also if you know of SaaS solutions where the identity space is
hierarchical, please share that. I started thinking the same way but
didn¹t find any vendor that supported it or customers that asked for it.

Cheers,
Morteza

On 3/25/15, 2:33 PM, "Haavar Valeur" <[email-masked]> wrote:

>I think having the OUs be hierarchical should be an option if an
>extension was added, but even without that I would think that it¹s
>beneficial to have OUs in the API. Without OU represented in the schema
>you would have loose references to objects that are created with
>proprietary APIs or schemas.
>
>I¹m a little surprised that the consensus was that SaaS providers have a
>flat OU structure. From what I¹ve seen, a lot of providers support a
>employee directory to the provider, including OUs. The OUs would be used
>to set password polices, federated login settings and administration or
>>>https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si
>>>EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL
>>>0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2F
>>>www.ietf.org%2Fmailman%2Flistinfo%2Fscim
>> 
>> 
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 25 Mar 2015 20:19:47 +0000

Thanks for bringing that up. Yes, that type of relationship is easily represented. A true hierarchical model where potentially even uniqueness is hierarchical (like LDAP) is what I was talking about.

Cheers,
Morteza

From: Ian Glazer <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 25, 2015 at 3:11 PM
To: Haavar Valeur <[email-masked]<mailto:[email-masked]>>
Cc: Morteza Ansari <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [scim] Organizational unit SCIM extension

In our case we have a flat-ish model. We can represent OUs and a hierarchy but it is represented on the user object and not as a standalone organizational structure

On Wed, Mar 25, 2015 at 3:33 PM, Haavar Valeur <[email-masked]<mailto:[email-masked]>> wrote:
I think having the OUs be hierarchical should be an option if an extension was added, but even without that I would think that it’s beneficial to have OUs in the API. Without OU represented in the schema you would have loose references to objects that are created with proprietary APIs or schemas.

> On Mar 25, 2015, at 11:47 AM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
>
> On 3/24/15, 6:54 PM, "Haavar Valeur" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> [email-masked]<mailto:[email-masked]>

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

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

---

From: Haavar Valeur <[email-masked]>
Date: Wed, 25 Mar 2015 20:46:24 +0000

I might be wrong, I’ve not gone too deep into the user administration of different providers, but my first impression is that salesforce (apparently actually flat-ish), google, amazon and SAP have some sort of hierarchy. I’m sure members of this WG have more detailed knowledge of the different providers.

I have not put much thought into how this can be represented as an extension. I wanted to see if there has been any work in this area already, or if it’s even needed. Seems like if it’s expected to manage OUs external to SCIM, and then have a soft reference on the user user object, it would be possible to have an extension data model for OUs that are not intrusive to the core schema.

> On Mar 25, 2015, at 3:11 PM, Morteza Ansari (moransar) <[email-masked]> wrote:
> 
>>>> http://secure-web.cisco.com/1Eu6_QGp7T23OybgyO6R0YBcrk2gA5H6_Vq-ArbeGT7COGOcICwQByVBUplMr8O8ClHILi9O6lNofRWiFWH6ywXgPwf0J5vZL8TuJAYXRVacWmuhqE7wUgKl34hfs0f-Mrpyk0cZUEf7k1gFotYWbMd0_2BWMR_NtGNAI3pYv_6KrtDx3dJ00seMmPigsLNUu/http%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim
>>> 
>>> 
>> 
> 
>

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 29 Mar 2015 12:25:04 +0200

Hi,

Does not seem like there is a consensus that OU hierarchy is needed,
however a suggestion for a solution came to mid so I just thought I send it
out and se what people think.

What about using the path to create the hierarchical OU structure

<base-path>/<ou1>Users
<base-path>/<ou1>Groups
<base-path>/<ou1>/<ou2>Users
<base-path>/<ou1>/<ou2>Groups

When searching under <base-path>/<ou1> results would include Users/Groups
under <base-path>/<ou1>/<ou2> but not the other way around. I dont know if
this creates enough flexibility e.g
with the following structure
<base-path>/<ou1>/<ou2>Users
<base-path>/<ou3>/<ou4>Users
It would be hard to search for users in both ou2 and ou4 with one request.

Best regards
//Samuel

On Wed, Mar 25, 2015 at 9:46 PM, Haavar Valeur <[email-masked]>
wrote:

> I might be wrong, I’ve not gone too deep into the user administration of
> different providers, but my first impression is that salesforce (apparently
> actually flat-ish), google, amazon and SAP have some sort of hierarchy. I’m
> sure members of this WG have more detailed knowledge of the different
> providers.
>
> I have not put much thought into how this can be represented as an
> extension. I wanted to see if there has been any work in this area already,
> or if it’s even needed. Seems like if it’s expected to manage OUs external
> to SCIM, and then have a soft reference on the user user object, it would
> be possible to have an extension data model for OUs that are not intrusive
> to the core schema.
>