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

From: "David M. Lloyd" <david.lloyd(a)redhat.com&gt; To: security-dev(a)lists.jboss.org Sent: Thursday, December 6, 2012 1:11:41 PM Subject: Re: [security-dev] IDM: LDAP Custom Attributes 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.

> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>> >>> _______________________________________________ security-dev >>> mailing list security-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/security-dev >> >> > _______________________________________________ security-dev > mailing > list security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > -- - DML _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev