[Issue 9495] New: authz-regexp using dn: instead of a URI mangles characters with HTML excapes
https://bugs.openldap.org/show_bug.cgi?id=9495
Issue ID: 9495 Summary: authz-regexp using dn: instead of a URI mangles characters with HTML excapes Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: kop@karlpinc.com Target Milestone: ---
Trying to use an authz-regexp that maps directly to dn-s by using "dn:..." instead of a URI results in the authz id having some characters "html escaped". As a result the authorized entity cannot be found.
E.g. a "-U cn=Barbara Jensen,ou=Information Technology Division"
with
olcAuthzRegexp: "^uid=([^,]+),.*" "dn:$1,ou=people,dc=example,dc=com"
fails. Debug logs show that the equal and the comma character return from ldap_bv2dn() in escaped forms, that are then substituted into the target dn and result in a dn that does not exist in the DIT.
6046d7cd SASL Canonicalize [conn=1113]: authcid="cn=Barbara Jensen,ou=Informatio n Technology Division" 6046d7cd slap_sasl_getdn: conn 1113 id=cn=Barbara Jensen,ou=Information Technolo gy Division [len=52] => ldap_dn2bv(16) <= ldap_dn2bv(uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth)=0 6046d7cd slap_sasl_getdn: u:id converted to uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth
...
6046d7cd send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed"
I suspect that when the "dn:..." form is used with authz-regexp the supplied authzid should _not_ have it's characters canonicalized because they will not be substituted into a URI. If so, this would be a bug. If not, there should be documentation on the restrictions on what characters can be used in authzid when the "dn:..." form is used.
Tested against HEAD of master, although the version in the bug report is 2.5.
See also Bug# 6912.
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6912 Keywords| |needs_review
https://bugs.openldap.org/show_bug.cgi?id=9495
--- Comment #1 from Karl O. Pinc kop@karlpinc.com --- It occurs to me that the regexp I used only "works" because the comma in the authzid is altered.
A better olcAuthzRegexp regexp for testing with my example might be:
"^uid=([^,]+,[^,]+),.*"
Regards,
Karl kop@karlpinc.com Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | See Also|https://bugs.openldap.org/s | |how_bug.cgi?id=6912 | Target Milestone|--- |2.5.4
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=6912
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@openldap.org |hyc@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|hyc@openldap.org |bugs@openldap.org Target Milestone|2.5.4 |2.6.0
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Invalid usage.
SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid.
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |INVALID Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=9495
--- Comment #3 from Karl O. Pinc kop@karlpinc.com --- On Mon, 14 Jun 2021 16:39:43 +0000 openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added
Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Invalid usage.
SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid.
RFC4422 Simple Authentication and Security Layer (SASL) states:
3.4.1. Authorization Identity String
The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as.
So, the literal "cn=..." is a perfectly valid SASL username.
Regards,
Karl kop@karlpinc.com Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
https://bugs.openldap.org/show_bug.cgi?id=9495
Karl O. Pinc kop@karlpinc.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|INVALID |SUSPENDED
--- Comment #4 from Karl O. Pinc kop@karlpinc.com --- Based on rfc4422 (above) I've changed the status from "INVALID" to "SUSPENDED". This is probably not correct so you will probably want to change it.
https://bugs.openldap.org/show_bug.cgi?id=9495
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|SUSPENDED |INVALID
--- Comment #5 from Howard Chu hyc@openldap.org --- (In reply to Karl O. Pinc from comment #3)
On Mon, 14 Jun 2021 16:39:43 +0000 openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9495
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added
Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED--- Comment #2 from Quanah Gibson-Mount quanah@openldap.org --- Invalid usage.
SASL works with usernames, not DNs. I.e., -U "cn=..." is invalid.
RFC4422 Simple Authentication and Security Layer (SASL) states:
3.4.1. Authorization Identity String
The authorization identity string is a sequence of zero or more Unicode [Unicode] characters, excluding the NUL (U+0000) character, representing the identity to act as.
So, the literal "cn=..." is a perfectly valid SASL username.
You should read the entire text of that section.
A non-empty authorization identity string indicates that the client wishes to act as the identity represented by the string. In this case, the form of identity represented by the string, as well as the precise syntax and semantics of the string, is protocol specific.
While the character encoding schema used to transfer the authorization identity string in the authentication exchange is mechanism specific, mechanisms are expected to be capable of carrying the entire Unicode repertoire (with the exception of the NUL character).
A literal of the form "cn=..." is only valid if the protocol defines it to be valid. The particular SASL mechanism must support it for it to be valid.
https://bugs.openldap.org/show_bug.cgi?id=9495
Karl O. Pinc kop@karlpinc.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9594
-
openldap-its＠openldap.org