[security-dev] IDM: LDAP Custom Attributes

[Anil Saldhana]

On 12/06/2012 10:41 AM, Marek Posolda wrote:
> On 06/12/12 14:15, Pedro Igor Silva wrote:
>> ----- Original Message -----
>>> From: "Boleslaw Dawidowicz" <bdawidow at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: "Anil Saldhana" <Anil.Saldhana at redhat.com>, 
>>> security-dev at lists.jboss.org
>>> Sent: Thursday, December 6, 2012 10:51:00 AM
>>> Subject: Re: [security-dev] IDM: LDAP Custom Attributes
>>>
>>>
>>> On Dec 6, 2012, at 12:50 PM, Pedro Igor Silva <psilva at redhat.com>
>>> wrote:
>>>
>>>> ----- Original Message -----
>>>>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>>>> To: security-dev at lists.jboss.org
>>>>> Sent: Thursday, December 6, 2012 12:06:03 AM
>>>>> Subject: [security-dev] IDM: LDAP Custom Attributes
>>>>>
>>>>> Pedro,
>>>>>     we had discussions on performance associated in querying custom
>>>>> attributes in the LDAP implementation. I realized that since we
>>>>> will
>>>>> have an identity cache operating in the IDM layer. The cache needs
>>>>> to
>>>>> have LRU entries (or whatever policy that gets configured) thus
>>>>> avoiding
>>>>> round trips to the Identity Store.
>>>> You're right, one of the biggest challenges is how to perform well
>>>> when querying attributes that are not part of the LDAP schema.
>>>> Those attributes are not searchable and we need to make most of
>>>> the query logic inside the store.
>>> In case of LDAP I would really allow only attributes mapped
>>> previously in the store configuration. There are too many scenarios
>>> - like some are readOnly and managed by the server (memberOf). LDAP
>>> is also not flexibly used store because of enforced schema so it is
>>> a valid constraint - simplifies a lot. For custom attributes stored
>>> in serialised manner I would simply not allow to use them in queries
>>> or ignore in such. Simplifies a lot.
>> Totally agree, but from our last discussion Anil suggested to still 
>> support custom attributes using serializable objects. Ignore them 
>> would be much more simple, but i understood Anil's point of view.
> It would be nice if users have possibility to choose, so they can either:
> 1) Store custom attributes in LDAP using serialization
> 2) Store those attributes in different IdentityStore (for example in 
> database, which is quite flexible and can easily support custom 
> attributes). We used this in Picketlink IDM 1, where only some 
> standard attributes of user (firstName, lastName, email) are stored in 
> LDAP and all other attributes are stored in database. With respect to 
> membership, LDAP obviously support only plain membership (user "john" 
> is in group "acme") without specifying role (user "john" is "manager" 
> of group "acme"), so informations about custom roles also need to be 
> stored in database.
>
> We discussed this yesterday on IRC, but not all were here.
>
> I think that proper support of (2) will require implementation of new 
> IdentityStore, which will encapsulate other IdentityStores 
> (LDAPIdentityStore, JPAIdentityStore) and delegate operation to proper 
> one from those two.
In reality, we may end up creating separate identity store 
implementations for quirky but prominent identity stores such as MS 
Active Directory.  I am unsure MSAD follows all the LDAPv3 rules. Over 
time based on user feedback and our experiences, we may end up with a 
bunch of Identity Store implementations. :)

>
> Marek
>
>>
>> The current query support implementation for the LDAP store is 
>> working with managed and custom attributes. If the attribute used as 
>> a query parameter is managed, a normal LDAP search will be performed. 
>> Otherwise, we'll filter the users manually. Users should be aware 
>> that when used custom attributes they loose some performance on queries.
>>
>>>>> Bolek had opined about the use of LDAP entry change notifications
>>>>> to
>>>>> update the IDM cache. This is when the admin may have used some
>>>>> form
>>>>> of
>>>>> LDAP browser to update the entries or update happens via software
>>>>> not
>>>>> controlled by IDM.
>>>>>
>>>> Ok, going to consider that too.
>>>>
>>>>> Regards,
>>>>> Anil