[security-dev] IDM: LDAP Custom Attributes

[Marek Posolda]

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.

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
>>>> _______________________________________________
>>>> security-dev mailing list
>>>> security-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>>
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev