Subject: [scim] Proprietary/custom properties

From: Andrew Badera <[email-masked]>
Date: Thu, 20 Sep 2012 12:59:53 -0500

Hello all-

If an organization is looking at early adoption of SCIM and has a number of
additional properties associated with users and groups that aren't part of
core schema or existing/proposed extensions, is there a preferred or
recommended way of handling those values? My thoughts to date are:

1. Treat it like an unofficial extension, (but then wonder about returning
supporting schema and configs, though we may not support that at this point
anyhow)
2. Bolt-on a users and groups attribute system, which can easily get ugly,
bloated, onerous and non-intuitive, fast. (Defining and supporting
attributes and their metadata, supporting retrieval and modification on a
per-attribute basis, etc.)
3. Something I haven't considered, or missed being discussed on-list
previously?

These are not (strictly) LDAP values, though many are currently stored in
otherwise-unused, sometimes repurposed LDAP fields. These run the gamut
from users being "enabled" or "disabled" to user's roles (beyond usertype)
to user's customer details, etc.

Thanks in advance for any insights-
∞ Andy Badera
∞ Technical Evangelist, MPS Partners, Chicago
∞ This email is: [ ] bloggable [x] ask first [ ] private
∞ Google me: http://www.google.com/search?q=andrew%20badera

---

From: Emmanuel Dreux <[email-masked]>
Date: Thu, 20 Sep 2012 19:18:55 +0000

Our own feedback :
We’re integrating SCIM on 2 SAAS provider’s platforms.
For both (= 100%), we’re extending the core user schema because we have to handle non standard defined attributes.

--
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

De : Andrew Badera [mailto:[email-masked]]
Envoyé : jeudi 20 septembre 2012 20:00
À : [email-masked]
Objet : [scim] Proprietary/custom properties

Hello all-

If an organization is looking at early adoption of SCIM and has a number of additional properties associated with users and groups that aren't part of core schema or existing/proposed extensions, is there a preferred or recommended way of handling those values? My thoughts to date are:

1. Treat it like an unofficial extension, (but then wonder about returning supporting schema and configs, though we may not support that at this point anyhow)
2. Bolt-on a users and groups attribute system, which can easily get ugly, bloated, onerous and non-intuitive, fast. (Defining and supporting attributes and their metadata, supporting retrieval and modification on a per-attribute basis, etc.)
3. Something I haven't considered, or missed being discussed on-list previously?

These are not (strictly) LDAP values, though many are currently stored in otherwise-unused, sometimes repurposed LDAP fields. These run the gamut from users being "enabled" or "disabled" to user's roles (beyond usertype) to user's customer details, etc.

---

From: Andrew Badera <[email-masked]>
Date: Thu, 20 Sep 2012 14:39:15 -0500

Thanks Emmanuel.

With JSON, as long as JSON remains schema-less, with most JSON
serialization frameworks being fairly loose and lax, that's probably pretty
pain-free. What about those consuming or serving XML however? Or what
happens if JSON Schema is adopted? Won't extending the core schema open up
the possibility, create the likelihood even, of breakage due to validation
issues? Or issues with anyone who's a very strict consumer?

--ab

On Thu, Sep 20, 2012 at 2:18 PM, Emmanuel Dreux <[email-masked]>wrote:

>  Our own feedback :****
>
> We’re integrating SCIM on 2 SAAS provider’s platforms.****
>
> For both (= 100%), we’re extending the core user schema because we have to
> handle non standard defined attributes.****
>
> ** **
>
> --****
>
> 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****
>
> ** **
>
> *De :* Andrew Badera [mailto:[email-masked]]
> *Envoyé :* jeudi 20 septembre 2012 20:00
> *À :* [email-masked]
> *Objet :* [scim] Proprietary/custom properties****
>
> ** **
>
> Hello all-****
>
> ** **
>
> If an organization is looking at early adoption of SCIM and has a number
> of additional properties associated with users and groups that aren't part
> of core schema or existing/proposed extensions, is there a preferred or
> recommended way of handling those values? My thoughts to date are:****
>
> ** **
>
> anyhow)****
> per-attribute basis, etc.)****
>
> previously?****
> ** **
> to user's customer details, etc.****
>
> ** **
>
> ∞ Technical Evangelist, MPS Partners, Chicago****
>
> ****

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 22 Sep 2012 18:56:23 +0200

I would go for option 1 with an unofficial extension created according to
the extensions rules with a schema name and config for discovery. Then when
you have it in place or want some opinions on the extension I would present
it to the list, and if it is an extension that solves a common problem it
might become an official extension.

Cheers
//Samuel

Sent from my iPad

On 20 sep 2012, at 20:00, Andrew Badera <[email-masked]> wrote:

Hello all-

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