Subject: Re: [scim] Organizational unit SCIM extension

From: Kelly Grizzle <[email-masked]>
Date: Wed, 29 Apr 2015 23:22:17 +0000

Haavar … I definitely see the benefit here for providers that are putting SCIM on top of a directory.  I can see a pretty simple standardize extension that would provide this.  It would be the addition of a single attribute (in an extension) and a new endpoint with an associated schema.  The User (and probably Group) resources would add an OU reference to their schema.  For example:

{
  "id": "827341",
  "username": "kgrizzle",
  "some:extension:urn": {
    "ou": {
      "value": "0988982340",
      "$ref": "https://example.com/v2/OrgUnits/0988982340"
    }
  }
}

The endpoint would be a flat list of org units (ie – they would all be directly under the /OrgUnits endpoint), but would be hierarchical through parent relationships.

GET /OrgUnits

[
  {
    "id": "0987478872734"
    "name": "OU 0",
  },
  {
    "id": "877987238974"
    "name": "OU 1",
    "parent": {
      "value": "0987478872734",
      "$ref": "https://example.com/v2/OrgUnits/0987478872734",
      "displayName": "OU 0"
    }
  }
]

The only trick here would be search for objects in “OU 0”.  Should resources in “OU 1” also be returned?  Perhaps a new query parameter could take care of whether to do a sub-tree search or not.

I think Samuel’s idea would map well to a directory, but there isn’t a good facility for that type of extension in SCIM.

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: Sunday, March 29, 2015 5:25 AM
To: Haavar Valeur
Cc: [email-masked]; Morteza Ansari (moransar)
Subject: Re: [scim] Organizational unit SCIM extension

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]<mailto:[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.

> On Mar 25, 2015, at 3:11 PM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
>
> 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]<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.
>>
>> 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]<mailto:[email-masked]>> wrote:
>>>
>>> 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]<mailto:[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]<mailto:[email-masked]>
>>>>
>>>> https://secure-web.cisco.com/1NT5zWq_V-xu9QCR-6B-Tt7Xn0FeTRZi_8n68D4z9Si
>>>> EHdcWXiN2cxbye8f49wsXxzPhWJlG_ejB347Ms-1S58ruhVcwIdr4FBqCedrTeDbsXWnZPHL
>>>> 0LLo5a6tEMLTP35ZBQCYAvIbMdNvP7J2GgEW5edLkCpsTLVCJziaEkXtk/https%3A%2F%2F
>>>> http://secure-web.cisco.com/1Eu6_QGp7T23OybgyO6R0YBcrk2gA5H6_Vq-ArbeGT7COGOcICwQByVBUplMr8O8ClHILi9O6lNofRWiFWH6ywXgPwf0J5vZL8TuJAYXRVacWmuhqE7wUgKl34hfs0f-Mrpyk0cZUEf7k1gFotYWbMd0_2BWMR_NtGNAI3pYv_6KrtDx3dJ00seMmPigsLNUu/http%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim
>>>
>>>
>>
>
>

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

---

From: Haavar Valeur <[email-masked]>
Date: Thu, 30 Apr 2015 00:05:10 +0000

Yes, this is essentially what I had in mind.

I think sometimes you would want to do a recursive search trough the hierarchy, and other times you might not. As you said it could be controlled by a query parameter.

There should probably also be some way to filter the results that are retuned under the /OrgUnits endpoint.

On Apr 29, 2015, at 4:22 PM, Kelly Grizzle <[email-masked]<mailto:[email-masked]>> wrote:

{
  "id": "827341",
  "username": "kgrizzle",
  "some:extension:urn": {
    "ou": {
      "value": "0988982340",

GET /OrgUnits

[
  {
    "id": "0987478872734"
    "name": "OU 0",
  },
  {
    "id": "877987238974"
    "name": "OU 1",
    "parent": {

--Kelly

From: scim [mailto:[email-masked]] On Behalf Of Samuel Erdtman
Sent: Sunday, March 29, 2015 5:25 AM
To: Haavar Valeur
Cc: [email-masked]<mailto:[email-masked]>; Morteza Ansari (moransar)
Subject: Re: [scim] Organizational unit SCIM extension

Hi,

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

Best regards
//Samuel

_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://secure-web.cisco.com/1TmPg2NShpvbeNEyl00kT0Co5AGRs4APdZk90xnrAMC3NMkG9OzbqHTpvAGipoV2IZPxeaSWHeRsVs4IgN-QqAGrRWee4IWVsxlQWvvbUAnHBtAbZUJ512Q_SE8jUIeUeCThC6HFcUaWuj1z3KRKVEhjpMRf7dtcSEYaQM6tTp4Yq5g0ZZrK1uWLclM-SA5-M/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim