Re: [security-dev] IDM: LDAP Custom Attributes

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(a)redhat.com&gt; To: "Pedro Igor >>> Silva" <psilva(a)redhat.com&gt; Cc: "Anil Saldhana" >>> <Anil.Saldhana(a)redhat.com&gt;, 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&gt; >>> wrote: >>> >>>> ----- Original Message ----- >>>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; 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! > > 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.

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