You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Moyer, Steven William" <sw...@psu.edu> on 2019/03/25 15:50:50 UTC
LDAP API 2.x question
Team,
Before I enter put a bug report in the issue tracker I wanted to verify that my interpretation of the LDAP API client is correct. We've got several systems which manage the entries stored into our LDAP servers. When entries are created, users should generally have at least one mail attribute that is not a @psu.edu address and may also have exactly one @psu.edu address depending on what type of account it is.
For those seeking employment here and for the very large population of those applying to attend university here, we might have several external email addresses by the time the LDAP account creation happens. For the most part, the system works exactly as planned but in some cases we're creating entries using the client that are failing to be created on the server. Mail in this case is the most common type of error but is an example of other attributes that might exhibit the same behavior.
If an identity (entry) contains mail addresses such as smoyer1@selesy.com and SMOYER1@selesy.com, the client still accepts that I've added to different mail attributes. When the entry is submitted to the server it fails because the server does not allow duplicates and the matching rules are:
Equality match: caseIgnoreIA5Match
Substring match: caseIgnoreIA5SubstringsMatch
Clearly it would be possible to iterate over the attributes in the code using the client API and eliminate duplicates but it feels like this is a common problem and that the better place to enforce the server's syntax is in the Apache LDAP API. I'm posting this to the mailing list first because it's entirely possible we're missing something in how we're using the API. If not, is there interest in enhancing the LDAP API to enforce the (presumably attached) server's syntax rules or should we just patch the code where we encounter problems and move on.
Thanks,
Steve
Re: LDAP API 2.x question
Posted by "Moyer, Steven William" <sw...@psu.edu>.
Emmanuel,
I certainly don't want the duplicate addresses in LDAP and I realized why the server was rejecting the requests to create entries ... the revelation I learned from your email is that there is a schema aware version of the client. I'm going to dig into that tomorrow but it sounds like exactly what I wanted. I don't want to write code that solves the problem in one line of code when it's clearly a problem for many users and affects many attributes.
Thanks for the help!
Steve
________________________________
From: Emmanuel Lécharny <el...@gmail.com>
Sent: Monday, March 25, 2019 12:18 PM
To: dev@directory.apache.org
Subject: Re: LDAP API 2.x question
Hi Steve,
basically, the 'mail' attributeType, as defined by RFC 4524 is part of
the core schema, and can't be changed.
That means you can't inject two email address that are equal when case
sensitivity is off (ie elecharny@apache.org and ELECHARNY@APACHE.ORG are
the same value).
From a user perspective, this is annoying, because any attempt to
inject an existing value will end with an error.
There is a (dirty) workaround : use a COMPARE operation beforehand, in
order to verify that the entry contains the value or not (cf
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fldap.com%2Fthe-ldap-compare-operation%2F&data=02%7C01%7Cswm16%40psu.edu%7Ca7d089b239c04f8c226e08d6b13e8172%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C636891279364547874&sdata=d70DQKZ6JcoBz78By9dlIBdfbiTbZLTJCIJBqDE9Tlg%3D&reserved=0). If it contains the value,
then there is no need to inject it.
Another workaround would be to create your own AttributeType, case
sensitive, but that would be overkilling, IMHO.
Last, not least, if you use the schema aware version of the API, you can
load the entry and quickly check if it contains the mail value you have,
and if not inject it. OTOH, it requires you load the entry - or at least
the 'mail' attribute and all its values-, which would be more costly
than sending a COMPARE request.
Side note: the COMPARE operation only accept one single value. It's
clearly not optimal when you want to inject more than one value, and in
this case, fetch the entry's mail values and check them locally, with a
schema aware entry.
And if you ever asked yourself : yes, sometime, LDAP sucks when it comes
to do things that are not very basic. LDAP is to RDBMS what RISC is to
CISC...
Hope it helped...
On 25/03/2019 16:50, Moyer, Steven William wrote:
> Team,
>
> Before I enter put a bug report in the issue tracker I wanted to
> verify that my interpretation of the LDAP API client is correct.
> We've got several systems which manage the entries stored into our
> LDAP servers. When entries are created, users should generally have
> at least one mail attribute that is not a @psu.edu address and may
> also have exactly one @psu.edu address depending on what type of
> account it is.
>
> For those seeking employment here and for the very large population of
> those applying to attend university here, we might have several
> external email addresses by the time the LDAP account creation
> happens. For the most part, the system works exactly as planned but
> in some cases we're creating entries using the client that are failing
> to be created on the server. Mail in this case is the most common type
> of error but is an example of other attributes that might exhibit the
> same behavior.
>
> If an identity (entry) contains mail addresses such as
> smoyer1@selesy.com and SMOYER1@selesy.com, the client still accepts
> that I've added to different mail attributes. When the entry is
> submitted to the server it fails because the server does not allow
> duplicates and the matching rules are:
>
> Equality match: caseIgnoreIA5Match
> Substring match: caseIgnoreIA5SubstringsMatch
>
> Clearly it would be possible to iterate over the attributes in the
> code using the client API and eliminate duplicates but it feels like
> this is a common problem and that the better place to enforce the
> server's syntax is in the Apache LDAP API. I'm posting this to the
> mailing list first because it's entirely possible we're missing
> something in how we're using the API. If not, is there interest in
> enhancing the LDAP API to enforce the (presumably attached) server's
> syntax rules or should we just patch the code where we encounter
> problems and move on.
>
> Thanks,
>
> Steve
Re: LDAP API 2.x question
Posted by Emmanuel Lécharny <el...@gmail.com>.
Hi Steve,
basically, the 'mail' attributeType, as defined by RFC 4524 is part of
the core schema, and can't be changed.
That means you can't inject two email address that are equal when case
sensitivity is off (ie elecharny@apache.org and ELECHARNY@APACHE.ORG are
the same value).
From a user perspective, this is annoying, because any attempt to
inject an existing value will end with an error.
There is a (dirty) workaround : use a COMPARE operation beforehand, in
order to verify that the entry contains the value or not (cf
https://ldap.com/the-ldap-compare-operation/). If it contains the value,
then there is no need to inject it.
Another workaround would be to create your own AttributeType, case
sensitive, but that would be overkilling, IMHO.
Last, not least, if you use the schema aware version of the API, you can
load the entry and quickly check if it contains the mail value you have,
and if not inject it. OTOH, it requires you load the entry - or at least
the 'mail' attribute and all its values-, which would be more costly
than sending a COMPARE request.
Side note: the COMPARE operation only accept one single value. It's
clearly not optimal when you want to inject more than one value, and in
this case, fetch the entry's mail values and check them locally, with a
schema aware entry.
And if you ever asked yourself : yes, sometime, LDAP sucks when it comes
to do things that are not very basic. LDAP is to RDBMS what RISC is to
CISC...
Hope it helped...
On 25/03/2019 16:50, Moyer, Steven William wrote:
> Team,
>
> Before I enter put a bug report in the issue tracker I wanted to
> verify that my interpretation of the LDAP API client is correct.
> We've got several systems which manage the entries stored into our
> LDAP servers. When entries are created, users should generally have
> at least one mail attribute that is not a @psu.edu address and may
> also have exactly one @psu.edu address depending on what type of
> account it is.
>
> For those seeking employment here and for the very large population of
> those applying to attend university here, we might have several
> external email addresses by the time the LDAP account creation
> happens. For the most part, the system works exactly as planned but
> in some cases we're creating entries using the client that are failing
> to be created on the server. Mail in this case is the most common type
> of error but is an example of other attributes that might exhibit the
> same behavior.
>
> If an identity (entry) contains mail addresses such as
> smoyer1@selesy.com and SMOYER1@selesy.com, the client still accepts
> that I've added to different mail attributes. When the entry is
> submitted to the server it fails because the server does not allow
> duplicates and the matching rules are:
>
> Equality match: caseIgnoreIA5Match
> Substring match: caseIgnoreIA5SubstringsMatch
>
> Clearly it would be possible to iterate over the attributes in the
> code using the client API and eliminate duplicates but it feels like
> this is a common problem and that the better place to enforce the
> server's syntax is in the Apache LDAP API. I'm posting this to the
> mailing list first because it's entirely possible we're missing
> something in how we're using the API. If not, is there interest in
> enhancing the LDAP API to enforce the (presumably attached) server's
> syntax rules or should we just patch the code where we encounter
> problems and move on.
>
> Thanks,
>
> Steve