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