[security-dev] IDM: LDAP Custom Attributes

[Pedro Igor Silva]

----- Original Message -----
> From: "David M. Lloyd" <david.lloyd at redhat.com>
> To: security-dev at 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 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.

Important one. Today we're supporting only primitive types as custom attributes.

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