Subject: [scim] SCIM as Cloud Directory API

From: Patrick Radtke <[email-masked]>
Date: Tue, 20 Nov 2012 10:56:16 -0800

We've (internally) been discussing a need for a read only Web API for 
our directory servers. I've been reading Phil Hunt's scim-directory 
draft and had some questions about the mapping inetOrgPerson to User, 
but first I'll describe some of the issues that make it impractical for 
us to map inetOrgPerson to User.

In our directory, inetOrgPerson often do not have uids. These are often 
incoming students or affiliates that have not yet created accounts and 
that we'll need to make available through the Web API.  In this case we 
wouldn't have a valid SCIM userName for these Users and couldn't expose 
them as a valid User resource.

Our inetOrgPerson entries frequently have multiple names (e.g. former 
lastnames, Anglicized first names, etc), and we couldn't return the 
additional names in a current User resource. Similar issues arise for 
any multi-valued LDAP attribute that map to single value User or 
Enterprise User attributes (organization, department, etc). Our 
inetOrgPerson may, at some point, be allowed multiple uids, etc.

Is our use case missing the point of the draft?
Is the intent of the draft to be a quickstart in providing an LDAP 
backed SCIM endpoint, rather then a 'Cloud Directory'?
In a 'Cloud Directory' future, would there be new standard Resources and 
Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. 
an Organization resources to map organizationalUnit)? Or would 
organizations initially define their own ( e.g. suOrganization, 
eduPerson, etc)?

thanks for any answers or crystal ball gazing,

-Patrick

---

From: Melinda Shore <[email-masked]>
Date: Tue, 20 Nov 2012 10:26:25 -0900

> us to map inetOrgPerson to User.

This may be off-topic but might, on the other hand, go to the
use case question - why don't you want to use one of the standard
LDAP APIs?

Melinda

---

From: Phil Hunt <[email-masked]>
Date: Tue, 20 Nov 2012 11:48:34 -0800

Patrick,

You are on the right track looking at the directory draft. From your description, I see you've already been working hard to extend LDAP to support a lot more cases like multiple values etc.

I came to the conclusion that a SCIM has a vastly different data model than that of LDAP and are not compatible.  

So the question is, should the LDAPv3 community propose an LDAP REST API specification or should they plan to migrate to SCIM?  In looking at the data requirements of the cloud, I came to the conclusion that classic LDAP data was not the same as what was proposed for the cloud where vCards and PoCo are popular.  My feeling is an LDAP REST spec would be short-lived or have limited use.  If anyone feels otherwise, I'd love to here from you!

It was from this perspective that I wrote the SCIM Directory draft. It proposes directory features based on the SCIM data model. As part of this I proposed a mapping that could give backwards mapping support for LDAPv3 clients since it is easier to support LDAP name/value pairs on top of SCIM complex attributes rather than the other way around.

However, with all the extensions you've made at Stanford, I suspect, this mapping will be insufficient. It is something those of us familiar with LDAP should talk about some more.

Regarding eduPerson etc, I would expect many organizations to start defining new SCIM resource extensions to define attributes that core SCIM does not already define.  In doing so, it might be nice to collect related attributes together in a complex attribute structure as was done with Address in the core User schema.

Thanks for bringing forward your case. 

Cheers,

Phil

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

On 2012-11-20, at 10:56 AM, Patrick Radtke wrote:

> We've (internally) been discussing a need for a read only Web API for our directory servers. I've been reading Phil Hunt's scim-directory draft and had some questions about the mapping inetOrgPerson to User, but first I'll describe some of the issues that make it impractical for us to map inetOrgPerson to User.
> 
> In our directory, inetOrgPerson often do not have uids. These are often incoming students or affiliates that have not yet created accounts and that we'll need to make available through the Web API.  In this case we wouldn't have a valid SCIM userName for these Users and couldn't expose them as a valid User resource.
> 
> Our inetOrgPerson entries frequently have multiple names (e.g. former lastnames, Anglicized first names, etc), and we couldn't return the additional names in a current User resource. Similar issues arise for any multi-valued LDAP attribute that map to single value User or Enterprise User attributes (organization, department, etc). Our inetOrgPerson may, at some point, be allowed multiple uids, etc.
> 
> Is the intent of the draft to be a quickstart in providing an LDAP backed SCIM endpoint, rather then a 'Cloud Directory'?
> In a 'Cloud Directory' future, would there be new standard Resources and Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. an Organization resources to map organizationalUnit)? Or would organizations initially define their own ( e.g. suOrganization, eduPerson, etc)?
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Patrick Radtke <[email-masked]>
Date: Tue, 20 Nov 2012 12:50:45 -0800

> use case question - why don't you want to use one of the standard

The primary reason is that there are some mobile phone apps being 
developed on campus that need to search for people. This directory data 
requires authenticated access. We don't want users to enter/save their 
central credentials into these applications and would prefer to use 
something like Web SSO and OAuth2 to handle the authn/authz. Not enough 
of our mobile users have client certificates for us to pursue that option.

-Patrick

---

From: Patrick Radtke <[email-masked]>
Date: Tue, 20 Nov 2012 12:55:27 -0800

Thanks Phil. That really helps my mental picture of this stuff.

---

From: Emmanuel Dreux <[email-masked]>
Date: Tue, 20 Nov 2012 22:08:24 +0000

I see 2 points in your thread:
1. inetOrgPerson often do not have uids [...]
=> LDAP directories do not (generally) provide immutable ids.
=> You can allocate uniqueIDs in your SCIM implementation and maintain a mapping table between your LDAP objects and SCIM Identifiers.
=> This also simplifies group membership and roles synchronization.

2. Schema: The SCIM default schemas are extensible and you can easily implement yours.
Personal feedback from a real experience. Today:
a. We synchronize LDAP organizational units with google and postini.
b. We allocate licences during provisioning of Office 365.
c. We sync public keys with a SAAS provider for specific needs.

In a "SCIM" world, for each of these scenario, the provider would have to implement a specific schema.
Said differently, today, if we want to provision Salesforce, Google, Dropbox, office365,etc.,  we have to learn and integrate their heterogeneous apis. 
Tomorrow, in a SCIM world, we'll have to integrate as many proprietary schemas as we would have providers. 
What's the difference, is it more practicable?

In parallal, Microsoft has implemented his LDAP restful apis (see phil comments). It is very convenient to use and entirely fits LDAP scenarii (schema : http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx)
In parallal, we've also discovered FOAF and RDF. This is, according to us, the most extensible solution: a unique and universal schemas, transparently extensible for everybody (compared to LDAP and OIDS definitions, and compared to SCIM and the need to define your own classes when you need additional attributes).

I'm really afraid that if we have 100 SAAS providers, we'll endup with 100 proprietary schemas. Please send me your comments on this. 

--
Cordialement / Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Patrick Radtke [mailto:[email-masked]] 
Envoyé : mardi 20 novembre 2012 19:56
À : [email-masked]
Objet : [scim] SCIM as Cloud Directory API

Is our use case missing the point of the draft?
Is the intent of the draft to be a quickstart in providing an LDAP backed SCIM endpoint, rather then a 'Cloud Directory'?
In a 'Cloud Directory' future, would there be new standard Resources and Attributes that roughly correspond to existing LDAP ObjectClasses (e.g. 
an Organization resources to map organizationalUnit)? Or would organizations initially define their own ( e.g. suOrganization, eduPerson, etc)?

-Patrick

---

From: Patrick Radtke <[email-masked]>
Date: Mon, 26 Nov 2012 09:14:39 -0800

Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph 
API - it is interesting to read their approach.

As for your point on "100 SAAS providers and 100 proprietary schemas" I 
suspect that a SAAS provider would not require more than the core 
schemas for basic provisioning, and the proprietary schemas would come 
in to play for SAAS specific settings (data visibility, privacy 
settings, access controls, in app 'theme' selection, etc) that are 
somewhat tangential to provisioning but are linked to a user's account. 
I think the proprietary schema would provided an enhanced experience but 
would not be required for provisioning.

-Patrick

---

From: Emmanuel Dreux <[email-masked]>
Date: Mon, 26 Nov 2012 18:01:55 +0000

If you look at the 2 main providers for online messaging systems, you will notice that the core SCIM schema is not sufficient:

- Google syncs AD organizational Unit to Google Organizations = Need for Extended schema
- Office 365 needs to assign specific licences = Extended schema.

In fact, for all the SAAS providers that we sync, the core schema has never been sufficient. For example,
- We provision RunMyProcess: they have a notion of roles and entities, (= 2 distinct level of roles).
- We are plugging a new SAAS provider with which we need to sync public keys (not the full certificate handled by SCIM).
Etc... Etc...

In fact, we have noticed that all of our SAAS partners have particularities and if we want to sync them through SCIM, we have to build a proprietary schema for each of them, reason why we're asking the possibility to extend more simply the core schema (add attributes without having to create a separate schema).

(Finally we have noticed that FOAF is THE flexible and evolutive identity schema that would 100% address all the needs of identity management, but if you allow to add attributes to the core SCIM schema, it would also be fine...)

-----Message d'origine-----
De : Patrick Radtke [mailto:[email-masked]] 
Envoyé : lundi 26 novembre 2012 18:15
À : Emmanuel Dreux
Cc : [email-masked]
Objet : Re: [scim] SCIM as Cloud Directory API

Thanks for the feedback Emmanuel, and the pointer to the Microsoft Graph API - it is interesting to read their approach.

As for your point on "100 SAAS providers and 100 proprietary schemas" I suspect that a SAAS provider would not require more than the core schemas for basic provisioning, and the proprietary schemas would come in to play for SAAS specific settings (data visibility, privacy settings, access controls, in app 'theme' selection, etc) that are somewhat tangential to provisioning but are linked to a user's account. 
I think the proprietary schema would provided an enhanced experience but would not be required for provisioning.

-Patrick

On 11/20/12 2:08 PM, Emmanuel Dreux wrote:
> 1. inetOrgPerson often do not have uids [...] => LDAP directories do 
> not (generally) provide immutable ids.
> In parallal, Microsoft has implemented his LDAP restful apis (see phil 
> comments). It is very convenient to use and entirely fits LDAP 
> scenarii (schema : 
> http://msdn.microsoft.com/en-us/library/windowsazure/hh974478.aspx)
> De : Patrick Radtke [mailto:[email-masked]] Envoyé : mardi 20 
> novembre 2012 19:56 À : [email-masked] Objet : [scim] SCIM as Cloud 
> Directory API
>

---

From: Erik Wahlström <[email-masked]>
Date: Tue, 27 Nov 2012 14:07:47 +0000

Hi,

Why isn't schema discovery and some well crafted code that adopts from it it enough for the scenarios described? It sounds from your description that you use SCIM internally but call the proprietary/heterogeneous API:s using different methods and schemas. If you would use FOAF wouldn't you be forced to parse that especially to depending on where you send the data?

I also think that there is a finite numbers of extension that would exist and that we could handle them in the way vCard handles extensions. The problem with having just a bucket to add attributes the schema quickly looses it's value.

/ Erik

---

From: Emmanuel Dreux <[email-masked]>
Date: Tue, 27 Nov 2012 21:56:01 +0000

If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for it.
They will have to create an extended schema (currency, division, etc...)

If Google adopts SCIM, how do you provision it? SCIM schema is ko for it.
They will have to create an extended schema. ( Organizational units)

If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for it.
They will have to create an extended schema. ( pictures as jpeg not as html link, licences, etc...)

Etc...
I'm just trying to prove (and hope to have proven that n providers = n schema).
Is it what we want? 
Or could we allow the root core schema to be extensible for more flexibility (and simplicity?).

The format JSON/XML/FOAF/VCARD or whatever is another story, we have fully understood his value but I will not try to convince this working group as it is not a very easy and accessible technology.

-----Message d'origine-----
De : Erik Wahlström [mailto:[email-masked]] 
Envoyé : mardi 27 novembre 2012 15:08
À : Emmanuel Dreux
Cc : [email-masked]; Patrick Radtke
Objet : Re: [scim] SCIM as Cloud Directory API

Hi,

/ Erik

On Nov 26, 2012, at 7:01 PM, Emmanuel Dreux wrote:

> (Finally we have noticed that FOAF is THE flexible and evolutive 
> identity schema that would 100% address all the needs of identity 
> management, but if you allow to add attributes to the core SCIM 
> schema, it would also be fine...)
> 
> 
> --
> Cordialement / Regards,
> Emmanuel Dreux
> http://www.cloudiway.com
> Tel: +33 4 26 78 17 58
> De : Patrick Radtke [mailto:[email-masked]] Envoyé : lundi 26 
> novembre 2012 18:15 À : Emmanuel Dreux Cc : [email-masked] Objet : Re: 
> [scim] SCIM as Cloud Directory API
> 
>> In parallal, Microsoft has implemented his LDAP restful apis (see 
>> phil comments). It is very convenient to use and entirely fits LDAP 
>> scenarii (schema :

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 27 Nov 2012 22:02:56 +0000

>From the Office365 perspective we would need to be able to specify a schema or discover a schema at the root, as I think we would get into extensibility issues sooner or later.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Dreux
Sent: Tuesday, November 27, 2012 1:56 PM
To: Erik Wahlström
Cc: [email-masked]; Patrick Radtke
Subject: Re: [scim] SCIM as Cloud Directory API

Etc...

-----Message d'origine-----

Hi,

/ Erik

---

From: Erik Wahlström <[email-masked]>
Date: Wed, 28 Nov 2012 15:12:29 +0000

The current schema is extensible. You can define new resource types and add attributes to an existing one, that's rather extensible and flexible to me :)

Some examples of the type of changes you would like to have would be great to help understand what types of changes to the schema spec you need. It doesn't sound like we are talking about resource relations here right?

Best regards
Erik

---

From: Emmanuel Dreux <[email-masked]>
Date: Wed, 28 Nov 2012 22:50:56 +0000

Hi Erik,

Correct me if I'm wrong, but you would not extend the schema, you would replace it with your own one.
The question is (as I didn't cross any yet): can someone post a link to a SAAS provider (or on premise app) for which the default SCIM schema would be sufficient to provision (not partially) the identities?

Is it then useful to define a schema in SCIM if the schema is not used / adopted because not practicable?
In one sense, it helps normalize the name of a few attributes, but in other way, as soon as you have to create your own "user class", you have to redefine them and get free to change the name of the attributes (firstname,givenName,sn, familyname,givenname, etc...).

Wouldn't it be fine to force to "derive" your own user "class" from the core user schema? (in a sense really "extend" it).
Or, are we allowed to say that any traffic based on rest api, authenticated with Oauth and exchanging user informations in JSON will be labeled "SCIM". (Is Microsoft Azure graph API the first live SCIM implementation?)

-----Message d'origine-----
De : Erik Wahlström [mailto:[email-masked]] 
Envoyé : mercredi 28 novembre 2012 16:12
À : Emmanuel Dreux
Cc : [email-masked]; Patrick Radtke
Objet : Re: [scim] SCIM as Cloud Directory API

Best regards
Erik

---

From: Melinda Shore <[email-masked]>
Date: Wed, 28 Nov 2012 21:56:52 -0900

On 11/28/12 6:12 AM, Erik Wahlström wrote:
> The current schema is extensible. You can define new resource types
> and add attributes to an existing one, that's rather extensible and
> flexible to me :)

It might be worth identifying what is meant by "extensible," and how
to avoid non-interoperable implementations.  Also, this might be a
good time to start thinking about IANA considerations - what goes into
an IANA registry, if anything, and what doesn't.  But the main
issue is avoiding interoperability problems while still supporting
extensibility.

Melinda

---

From: Erik Wahlström <[email-masked]>
Date: Thu, 29 Nov 2012 16:30:38 +0000

Hi,

http://tools.ietf.org/html/draft-scim-core-schema-01#section-11.3

In that example the core User schema is extended with an enterprise extension (that's just one extension that acts as an example in the specification). The enterprise extension is discoverable using the following format http://tools.ietf.org/html/draft-scim-core-schema-01#section-11.6 and you can get all extensions a server supports using the /Schemas endpoint. That means that a core resource is extendable in my book.

In the same way you can totally define your new types of Resources that you can control your self. For example /Device or /Machine, /Person or whatever that's all derived from Resource. Those are all still very discoverable.

You are more then welcome to propose new attributes you think is missing in the core schema (have the 80/20 rule in mind). The examples you mentioned sounds good to me. I guess keeping your attributes in the core specification is in the interest of a service provider to ease onboarding to it's service. If a service provider decides (or more probably and probably more common, is forced) to use an extension they have the possibility to do that and your system have the possibility to adopt to that.

I do think your system will need some smart mapping functionality for some attributes (for example entitlements).

I'm hoping that we will find some common extensions and a process to handle that (as Melinda  talked about)

/ Erik

On Nov 28, 2012, at 11:50 PM, Emmanuel Dreux wrote:

Hi Erik,

-----Message d'origine-----
De : Erik Wahlström [mailto:[email-masked]]
Envoyé : mercredi 28 novembre 2012 16:12
À : Emmanuel Dreux
Cc : [email-masked]; Patrick Radtke
Objet : Re: [scim] SCIM as Cloud Directory API

Best regards
Erik

If Salesforce adopts SCIM, how do you provision it? SCIM schema is ko for it.
They will have to create an extended schema (currency, division,
etc...)

If Office 365 adopts SCIM, how do you provision it? SCIM schema is ko for it.
They will have to create an extended schema. ( pictures as jpeg not as
html link, licences, etc...)

Etc...

-----Message d'origine-----
De : Erik Wahlström [mailto:[email-masked]]
Envoyé : mardi 27 novembre 2012 15:08
À : Emmanuel Dreux
Cc : [email-masked]; Patrick Radtke
Objet : Re: [scim] SCIM as Cloud Directory API

Hi,

/ Erik

- Google syncs AD organizational Unit to Google Organizations = Need
for Extended schema
- Office 365 needs to assign specific licences = Extended schema.

In fact, for all the SAAS providers that we sync, the core schema has
never been sufficient. For example,
- We provision RunMyProcess: they have a notion of roles and entities, (= 2 distinct level of roles).
- We are plugging a new SAAS provider with which we need to sync public keys (not the full certificate handled by SCIM).
Etc... Etc...

-----Message d'origine-----

-Patrick

-----Message d'origine-----

-Patrick