[security-dev] IDM: LDAP Custom Attributes

[David M. Lloyd]

On 12/06/2012 07:15 AM, 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.

I don't know, this is a pretty big can of worms.  Supporting 
serializable objects means supporting their correct deserialization as 
well, which in turn means that semantics would have to be established 
regarding the class loaders to use for various classes.  And that means 
that the class loading environment has to be specified, and now it's 
gotten much more complex than it was before!

I strongly urge you to stick with simple data types for custom 
attributes: Strings, primitives, that sort of thing.  Data types that 
you *know* can be supported by any backend store.

> 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 lose 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
>


-- 
- DML