10:41 a.m.
On 06/12/12 14:15, Pedro Igor Silva wrote:
----- Original Message -----
> From: "Boleslaw Dawidowicz" <bdawidow(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Cc: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>,
security-dev(a)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(a)redhat.com>
> wrote:
>
>> ----- Original Message -----
>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
>>> To: security-dev(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>>>
>> _______________________________________________
>> security-dev mailing list
>> security-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev