[security-dev] IDM: LDAP Custom Attributes

[Marek Posolda]

On 06/12/12 17:53, Anil Saldhana wrote:
> On 12/06/2012 10:49 AM, Marek Posolda wrote:
>> On 06/12/12 16:11, David M. Lloyd wrote:
>>> 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.
>> I also think that we should stick with simple attribute types like
>> Strings and primitives. In IDM 1.x we supported binary attributes, but
>> it was quite painful process to properly support binary attributes all
>> databases and in the end the binary attributes were never used... And
>> those serialization/classloading issues for support of custom java types
>> as attribute is another potentially painful thing, which would be good
>> to avoid IMO.
> The challenge is LDAP schema. :)  For basic users who just want to store
> user/role/group with attributes
> into their ldap stores and not do fancy custom schemas or interact with
> another team that manages ldap
> servers,  simple serialization mechanisms that we have put in with basic
> primitive attributes will work. :)
Sure, it would be good to support this and using serialization for 
custom (not managed) attributes as I mentioned in my point 1 of previous 
mail. But just in case that those custom attributes are 
Strings/primitives. I hope that nobody has requirement to support custom 
attributes of non-primitive types:-)

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