Subject: Re: [scim] #45: LDAP mapping

From: Steve Moyer <[email-masked]>
Date: Tue, 8 Oct 2013 11:31:34 -0400 (EDT)

Peter et al,

There are a couple of us on the list who have preliminary mappings between SCIM and LDAP's inetOrgPerson (as described in this issue: Re: [scim] #45: LDAP mapping).  Since we've been through some of that pain, would it make sense to collaborate on creating this mapping?

Steve

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Oct 2013 08:35:10 -0700

If you look at my scim directory draft you are welcome to use the mapping there. 

Phil

> On Oct 8, 2013, at 8:31, Steve Moyer <[email-masked]> wrote:
> 
> Peter et al,
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Peter Gietz <[email-masked]>
Date: Tue, 08 Oct 2013 18:03:54 +0200

Hi Steve,

Thanks a lot for this which sort of comes just in time, since working on
that is on the agenda for this week.

Of course it will make sense to collaborate on this. How should we start
that. Shall I do a first draft, which uses part of Phil's document, and
you will comment on it, or do you also have something already on which
we can build on?

We also will have to be clear about the scope of the document. I would
prefer first to do a schema only document and leave other scim-directory
things to a second document, which could reuse other parts of Phil's
document but which also could include a LDAP Error to HTTP error mapping.

@Steve, Phil, all: Does this make sense to you?

Peter

-- 

Peter Gietz, CEO

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9  
email: [email-masked]
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Oct 2013 09:33:01 -0700

Peter,

I think we need to talk through the use cases for LDAP mapping.

The reason that this is important, is I hear a lot of people saying "why can't I simply implement a SCIM API on top of my LDAP server?".  Without bi-directional mapping, you can't make a SCIM server based on an LDAP platform.  This is an important limitation to understand.  The reason I wrote the directory draft was to point out you have to move to an underlying data model that supports complex attributes (a SCIM Directory).  Once you have that, it becomes possible to provide LDAP on top of a SCIM Directory rather then a SCIM API sitting on top of an LDAP Directory.

Keeping in mind that our WG focus is actually "provisioning" and not "directory services", it is however possible to support LDAP in a provisioning only way:

1.  As an endpoint, where a SCIM centric entity pushes provisioning requests to an LDAP endpoint.
2.  Where a directory is used to push "limited" attributes to a SCIM SP.

These can only work as long as the client does not expect read-after-write to produce the same JSON.

The challenge for such a mapping is the amount of variability that results, particularly with dealing with how to handle mullti-valued/typed data.  This generates per-deployment and per-transaction variability that causes errors. For example what should a server do when a multi-value type appears which has no mapping (which is static)?  For example, a mapping for home address and work address is defined, but what happens when "other" address value appears?

If we could talk through the use cases, we may be able to come up with a document structure that works (which might well be what you propose).

Phil

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

---

From: Peter Gietz <[email-masked]>
Date: Tue, 08 Oct 2013 18:38:52 +0200

> I think we need to talk through the use cases for LDAP mapping.

Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of
the next scim telcos?

Cheers,

Peter

-- 

Peter Gietz, CEO

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Oct 2013 09:52:49 -0700

I think we should start on this list.

The first question to ask is which use-case solution does the WG expect:

1. SCIM on a LDAP Directory (in order to have a single identity store),
2. LDAP as a SCIM provisioning endpoint", or
3. LDAP on a SCIM Directory (in order to have a single identity store)?

I think once we have consensus on the above, our efforts will be much more scoped for the actual mapping.  

I think 2 and 3 are possible, but not 1.  FWIW, it goes without saying that 2 is technically what is in the WG mandate.  I mention the others, because people keep talking about #1 as it seems the least disruptive approach to SCIM adoption (which it isn't).

After that, we could start the list and get the chairs to book a separate call (there is a mandatory announcement period these days I think).

Phil

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

---

From: Steve Moyer <[email-masked]>
Date: Tue, 8 Oct 2013 13:39:10 -0400 (EDT)

I agree with both of you (aren't I just diplomatic today), the business logic for translating a SCIM user to an inetOrgPerson and back is important, and the other thread I started today (Filter ambiguity) will be impacted by both the LDAP mapping and the business rules for the resources being mapped.  For the mapping itself, I'd agree that we should start with the table Phil has provided in section 2.2.3.4. (Attribute Name Mapping).  The only error I see in that table is that region is not a synonym for locality and should be address.region and mapped to the LDAP "st" attribute.  There are some other attributes that aren't mapped the same way we're doing things, but that's why I restarted the discussion!

I'm actually more concerned (at this point) with how to store the "type" and "primary flag" for each multi-valued attribute, and how to guarantee the correct ordering of attributes that make up an address (so that the proper parts are kept together).  LDAP doesn't natively guarantee the storage order of attributes or even that the returned order matches the insertion order.  We're using the proposed specification for "Ordered Entries and Values in LDAP" (http://tools.ietf.org/html/draft-chu-ldap-xordered-00) to keep things aligned.  In our current system, we're using the postalAddress to store the "type" and "primary flag" along with the formatted value (yes, this breaks LDAP clients in some cases, but our intention is to move people away from direct LDAP access and onto the SCIM RESTful services.

I'd be happy to work with you in whatever manner seems easiest ... We have custom user extensions that we know won't match the group's consensus for LDAP mapping, but we'd like to migrate the attributes that make sense to be compatible.

Steve

P.S.  For those following along, Phil's document is here: https://www.ietf.org/id/draft-hunt-scim-directory-01.txt

----- Original Message -----
From: "Peter Gietz" <[email-masked]>
To: "Phil Hunt" <[email-masked]>
Cc: [email-masked], "Steve Moyer" <[email-masked]>
Sent: Tuesday, October 8, 2013 12:38:52 PM
Subject: Re: [scim] #45: LDAP mapping

Cheers,

Peter

-- 

Peter Gietz, CEO

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9

---

From: Kelly Grizzle <[email-masked]>
Date: Tue, 8 Oct 2013 17:50:00 +0000

Another point of reference is the SCIM SDK developed by UnboundID - https://code.google.com/p/scimsdk/.  Bjorn can provide information on the way that they have implemented it.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Moyer
Sent: Tuesday, October 08, 2013 12:39 PM
To: Peter Gietz
Cc: [email-masked]; Phil Hunt
Subject: Re: [scim] #45: LDAP mapping

Steve

----- Original Message -----
From: "Peter Gietz" <[email-masked]>
To: "Phil Hunt" <[email-masked]>
Cc: [email-masked], "Steve Moyer" <[email-masked]>
Sent: Tuesday, October 8, 2013 12:38:52 PM
Subject: Re: [scim] #45: LDAP mapping

> I think we need to talk through the use cases for LDAP mapping.

Agreed. Should we do this 1.) here, 2.) off-line or 3.) during one of the next scim telcos?

Cheers,

Peter

>> Thanks a lot for this which sort of comes just in time, since working 
>> on that is on the agenda for this week.
>>
>> Of course it will make sense to collaborate on this. How should we 
>> start that. Shall I do a first draft, which uses part of Phil's 
>> document, and you will comment on it, or do you also have something 
>> already on which we can build on?
>>
>> We also will have to be clear about the scope of the document. I 
>> would prefer first to do a schema only document and leave other 
>> scim-directory things to a second document, which could reuse other 
>> parts of Phil's document but which also could include a LDAP Error to HTTP error mapping.
>>

-- 

Peter Gietz, CEO

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 Oct 2013 10:51:44 -0700

Steve,

You hit one one of the major problems (type and primary flag).  LDAP has no way to handle this.  Lack of order makes it further complex.

The proposal I have seen most is to do things like extend LDAP schema and create an LDAP attribute per type.  Eg. for telephone number, the value with type of "home" goes to "hometelephonenumber" and so on.

Aside form requiring ongoing re-configuration of the SCIM to LDAP mapping, it also means constantly extending LDAP schema--> HUGE change management headaches. \

I think once deployers understand these costs, they are going to find the economy of having a single database supporting SCIM on top of LDAP as being very negative in practice.

Another way is to encode the values.  So, the value for home telephonenumber becomes for example:   "home:123-456-7890".  Or you use hashing to do the same thing so telephonenumber;home is 123-456-7890.   

The problem here, is that existing LDAP clients are impacted.  

While hashing is probably the best solution, complex values like address take us into new territories of complexity.

Phil

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

---

From: Steve Moyer <[email-masked]>
Date: Tue, 8 Oct 2013 15:24:09 -0400 (EDT)

I spoke too soon related to the "Ordered Entries and Values in LDAP" ... Our operations team says it's installed on our server (OpenLDAP) and it's even applied to some attributes, but when I asked him to apply it to the list of attributes comprising an address (like the constraint overlay), he let me know that this was a schema extension.  To use this for SCIM, we'd have to (in essence) extend the inetOrgPerson into a scimPerson and redefine the attributes we wanted to order.

I've seen a couple instances where it was recommended that SCIM add supplemental information to an inetOrgPerson, but I don't think we want to redefine the core attributes of inetOrgPerson.

Steve

----- Original Message -----
From: "Phil Hunt" <[email-masked]>
To: "Steve Moyer" <[email-masked]>
Cc: "Peter Gietz" <[email-masked]>, [email-masked]
Sent: Tuesday, October 8, 2013 1:51:44 PM
Subject: Re: [scim] #45: LDAP mapping

Steve,

Phil

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

---

From: Peter Gietz <[email-masked]>
Date: Thu, 10 Oct 2013 14:16:32 +0200

> I think 2 and 3 are possible, but not 1.  FWIW, it goes without saying that 2 is technically what is in the WG mandate.  I mention the others, because people keep talking about #1 as it seems the l…

Now I see what you mean.

If we find a way to do the mapping bidirectional without information
loss (which is needed for #3 as well), I cannot really find, why
use-case #1 should not be possible.

Of course, only dealing with #2 would make our life much easier.

Peter

-- 

Peter Gietz, CEO

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9

---

From: Peter Gietz <[email-masked]>
Date: Thu, 10 Oct 2013 14:17:20 +0200

> Another way is to encode the values.  So, the value for home telephonenumber becomes for example:   "home:123-456-7890".  Or you use hashing to do the same thing so telephonenumber;home is 123-456-…
When starting to think about this, I thought that such Attribute Options
(as specified in RFC 4512 par. 2.5.2) could be a way forward.

> The problem here, is that existing LDAP clients are impacted.  

Since every LDAPv3 conforming client should be able to deal with
Attribute Options (i.e. should at least be able to ignore them ), I
don't see the impact.

Since we all seem to agree that inetOrgPerson alone will not be
sufficient for the mapping, there  will have to be some new LDAP schema
for SCIM and we could well use Attribute Options where necessary.

>
> While hashing is probably the best solution, 
agreed assuming you mean Attribute Options when saying hashing
> complex values like address take us into new territories of complexity.

yes that will be the hard stuff.

Peter

-- 

Peter Gietz, CEO

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Oct 2013 08:42:58 -0700

Yes. Thanks forgot the name. 

Phil

> On Oct 10, 2013, at 5:17, Peter Gietz <[email-masked]> wrote:
> 
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Oct 2013 08:46:43 -0700

Re #3, the assumption is the data store can handle complex attrs and type values. In the other scenarios data is thown away to match ldap's limited schema. 

FWIW - does it make sense to even map more than one telephone number if ldap clients won't be upgraded to see them?

I have come to the conclusion the ldap directory and cloud directory are very very different. Only provisioning will exist between them. Now try to tell that to customers. :-)

Phil

> On Oct 10, 2013, at 5:16, Peter Gietz <[email-masked]> wrote:
>

---

From: Patrick Radtke <[email-masked]>
Date: Thu, 10 Oct 2013 09:19:58 -0700

> Attribute Options (i.e. should at least be able to ignore them ), I

Existing clients ignoring attribute options which may be its own 
problem. For example if my LDAP mail entry was

mail;x-scim-type-work;x-scim-primary: [email-masked]

then Outlook (at least the last time I tested in 2006) wouldn't display 
my email address in the address book, since there is not a "mail" 
attribute with no options.

We ended up putting all the primary data in attributes with no options, 
and just using options for the extra data. That seemed to keep regular 
clients happy.

-Patrick

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Oct 2013 09:21:02 -0700

Agreed.. So the bigger problem is that LDAP clients are unlikely to adapt to any mapping of the data.  Any mapping we make must be transparent to existing clients.

Phil

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

On 2013-10-10, at 9:19 AM, Patrick Radtke <[email-masked]> wrote:

> Existing clients ignoring attribute options which may be its own problem. For example if my LDAP mail entry was
> 
> then Outlook (at least the last time I tested in 2006) wouldn't display my email address in the address book, since there is not a "mail" attribute with no options.
> 
> We ended up putting all the primary data in attributes with no options, and just using options for the extra data. That seemed to keep regular clients happy.
> 
> -Patrick
> 
> 
> 
>