Subject: [scim] Fwd: Summary of issues with SCIM

From: Emmanuel Dreux <[email-masked]>
Date: Sun, 15 Apr 2012 11:53:04 +0200

Cross posting to [email-masked] as it's at the boarder of the discussion of
what is SCIM (provisioning protocol / not provisioning protocol etc...)

Here is my feedback (technical) based on our attempt to make our first
implementation of SCIM.
 This leads us to think that in his current states SCIM cannot be reduced
to the vision of a "provisioning protocol":
It had strong dependancies with the target (allocation of uniqID that must
never change) and might require modifications of the target in order to be
able to provision the target (if we do not address that point in the spec)

 Therefore, we had (and still have to) to make important design decisions
that are not described in the spec.
Our first implementation is a blackbox system that indeed talks using REST
api and indeed exchange objects on the wire using the XML/JSON defined
schema.
But it's also a system that maintains and allocate uniqueIdentifiers
independantly of the target to be provisioned (For example we cannot rely
on an Active Directory that sends us a uniqID that is subject to change if
an admin makes evolution in his Active Directory infrastructure or if the
user gets renamed or moved).
This module of allocation of IDs (AllocID) has to provide identity
translation services (what is the identity of {uniqID} in this target?).
This is mandatory for groups/roles provisioning where SCIM sends
you uniqIDs as groupMembership that you have to translate to CN to write
to the LDAP directory.

In order to no be intrusive in the target system (make modifications on it
to store the uniqID), SCIM has to integrate an AllocID system and not
simply be a "provisioning protocol" or or a definition of a User and Group
schema in JSON and XML.

This is my opinion after having tried to implement the first version of
SCIM, and I submit it for discussion.

---------- Forwarded message ----------
From: Emmanuel Dreux <[email-masked]>
Date: 2012/4/15
Subject: Summary of issues with SCIM
To: [email-masked]

Hi,

here is a summary of the discussion we had at the interrop session.
We're mainly using Active Directory as backend database on server side.

Issue 1: Unique Identifier generation
- It can't be the Active Directory ObjectGuid:
      --> If you make an Active Migration, this objectGuid changes,
Consequence the uniqueIdentifier changes
- Option: Extend Active Directory Schema and create an additional attribute
to store the uniqueID (independant of AD infrastructure)
     --> One of our customer has 350 AD Forests.
     --> New customers will not accept to extend theit schema for our
product
- Use the DistinguishedName as unique Key.
     --> If I remember, this is the current option used by Trey's solution
(I remember I have seen this in the server answer?)
     --> If a user is moved to a new OU, the DN changes.
-  Use the samAccountName
    --> If a person gets married/renamed, the samAccountName might change.
- Maintain the uniqueID in a cache database out of the AD.
     --> This would be the better solution

Issue 2: Group Synchronisation
Member attributes contains the DN of users and groups membership
Today we send the content of the member attribute as found in the source:
we send the DN(s) of the source and make a DN translation in the target
(CN=USER,OU=SOMEOU,DC=SOURCE,DC=COM => CN=USER,OU=SOMEOU,DC=Target,DC=COM)

With SCIM, we will have to send the uniqueIdentifier of the object.
First the source will have to make a DN to uniqID translation.
Then, at the target, if we choose the last option of Issue 1, we'll have to
maintain a table uniqueID/DN that we will lookup when updating group
objects.
When a user is moved (at the source but also at the target) , we'll have to
updated this cache database as well to reflect the change of the DN.

Issue 3: Async Mode (discussed in previous mail)

If we refer to the discussions taking place in the IETF mailing list, SCIM
cannot be "simply" seen as a provisioning protocol, as as you see, it
cannot work AS IS for Active Directory provisioning and needs a complex
external logic to work with AD.

Conclusion : I can't imagine SCIM (as defined in the current state of the
spec) as a simple provisioning protocol that could be integrated in any
IAM/metadirectory platform in the form of a "simple" connector implementing
the REST apis.
Today, putting SCIM to provision an Active Directory/LDAP Server is
challenging and requires non negligible external logic not defined in the
specs.

---

From: Tina TSOU <[email-masked]>
Date: Sun, 15 Apr 2012 20:01:30 +0000

Emmanuel,
IMHO, only JSON is sufficient. XML just adds head and tail to JSON. We don't need two sets.

Sent from my iPad

On Apr 15, 2012, at 8:06 AM, "Emmanuel Dreux" <[email-masked]<mailto:[email-masked]>> wrote:

Cross posting to [email-masked]<mailto:[email-masked]> as it's at the boarder of the discussion of what is SCIM (provisioning protocol / not provisioning protocol etc...)

Here is my feedback (technical) based on our attempt to make our first implementation of SCIM.
This leads us to think that in his current states SCIM cannot be reduced to the vision of a "provisioning protocol":
It had strong dependancies with the target (allocation of uniqID that must never change) and might require modifications of the target in order to be able to provision the target (if we do not address that point in the spec)

Therefore, we had (and still have to) to make important design decisions that are not described in the spec.
Our first implementation is a blackbox system that indeed talks using REST api and indeed exchange objects on the wire using the XML/JSON defined schema.
But it's also a system that maintains and allocate uniqueIdentifiers independantly of the target to be provisioned (For example we cannot rely on an Active Directory that sends us a uniqID that is subject to change if an admin makes evolution in his Active Directory infrastructure or if the user gets renamed or moved).
This module of allocation of IDs (AllocID) has to provide identity translation services (what is the identity of {uniqID} in this target?). This is mandatory for groups/roles provisioning where SCIM sends you uniqIDs as groupMembership that you have to translate to CN to write to the LDAP directory.

In order to no be intrusive in the target system (make modifications on it to store the uniqID), SCIM has to integrate an AllocID system and not simply be a "provisioning protocol" or or a definition of a User and Group schema in JSON and XML.

This is my opinion after having tried to implement the first version of SCIM, and I submit it for discussion.

---------- Forwarded message ----------
From: Emmanuel Dreux <[email-masked]<mailto:[email-masked]>>
Date: 2012/4/15
Subject: Summary of issues with SCIM
To: [email-masked]<mailto:[email-masked]>

Hi,

Issue 1: Unique Identifier generation
- It can't be the Active Directory ObjectGuid:
      --> If you make an Active Migration, this objectGuid changes, Consequence the uniqueIdentifier changes
- Option: Extend Active Directory Schema and create an additional attribute to store the uniqueID (independant of AD infrastructure)
     --> One of our customer has 350 AD Forests.
     --> New customers will not accept to extend theit schema for our product
- Use the DistinguishedName as unique Key.
     --> If I remember, this is the current option used by Trey's solution (I remember I have seen this in the server answer?)
     --> If a user is moved to a new OU, the DN changes.
-  Use the samAccountName
    --> If a person gets married/renamed, the samAccountName might change.
- Maintain the uniqueID in a cache database out of the AD.
     --> This would be the better solution

Issue 2: Group Synchronisation
Member attributes contains the DN of users and groups membership
Today we send the content of the member attribute as found in the source: we send the DN(s) of the source and make a DN translation in the target (CN=USER,OU=SOMEOU,DC=SOURCE,DC=COM => CN=USER,OU=SOMEOU,DC=Target,DC=COM)

With SCIM, we will have to send the uniqueIdentifier of the object.
First the source will have to make a DN to uniqID translation.
Then, at the target, if we choose the last option of Issue 1, we'll have to maintain a table uniqueID/DN that we will lookup when updating group objects.
When a user is moved (at the source but also at the target) , we'll have to updated this cache database as well to reflect the change of the DN.

If we refer to the discussions taking place in the IETF mailing list, SCIM cannot be "simply" seen as a provisioning protocol, as as you see, it cannot work AS IS for Active Directory provisioning and needs a complex external logic to work with AD.

Conclusion : I can't imagine SCIM (as defined in the current state of the spec) as a simple provisioning protocol that could be integrated in any IAM/metadirectory platform in the form of a "simple" connector implementing the REST apis.
Today, putting SCIM to provision an Active Directory/LDAP Server is challenging and requires non negligible external logic not defined in the specs.

---

From: Melinda Shore <[email-masked]>
Date: Sun, 15 Apr 2012 16:30:33 -0800

On 4/15/12 1:53 AM, Emmanuel Dreux wrote:
> translation services (what is the identity of {uniqID} in this
> target?). This is mandatory for groups/roles provisioning where SCIM
> sends you uniqIDs as groupMembership that you have to translate to CN
> to write to the LDAP directory.

It seems to me that there are several ways to do this.  You can
convey some set of identities in a blob, in which case there needs
to be changes to the schema and to the semantics, or you can do
identityt mappings/translation in a bump in the {wire,stack} and
with a wave of the hand declare it out-of-scope for scim.

 From the documents I haven't been able to get a handle on why uniqID
needs to be unique for the purposes of scim.

Melinda