[security-dev] IDM: LDAP Custom Attributes

[Bill Burke]

On 12/6/2012 10:11 AM, 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!
>

IMO, the classloader environment will need to be configurable 
irregardless of whether serialization is used/supported or not.  I've 
already run into this problem when writing a custom LoginModule.

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

This is what Base64 encodings are for.  We use base64 to transmit/store 
keys/certs, why not Java objects?  I'll bet $5 that you'll have the need 
for serialization in some form, whether its Java serialization or 
Java-to-JSON or whatever.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com