Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando When idassert-bind is configured to use SASL bind, an "authcID" needs to be provided, while the "binddn" is not needed. However, if a "binddn" is not provided as well, in some cases the proxiedAuthz control may be used incorrectly. The need to configure the "binddn" is not documented, so this ITS is minimally addressed by documenting this requirement. If the "binddn" is provided, everything works as expected, with the only minor issue that the DN of the user as it is known to back-meta may not match the actual identity the "authcID" assumed on the remote server. The "right" way to address this problem consists in performing a "WhoAmI" (RFC 4532) right after the bind, or better use a "authorization identity control" (RFC 3829) along with the bind operation. Both approaches should be implemented, but they should not be used unless explicitly requested. p.
changed notes changed state Open to Active
changed notes
masarati@aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.14.92) > Submitted by: ando > > > When idassert-bind is configured to use SASL bind, an "authcID" needs to be > provided, while the "binddn" is not needed. However, if a "binddn" is not > provided as well, in some cases the proxiedAuthz control may be used > incorrectly. The need to configure the "binddn" is not documented, so this ITS > is minimally addressed by documenting this requirement. I tripped over this change while investigating #6711. Adding this requirement is certainly not the right solution; SASL Binds ordinarily don't require a BindDN and requiring it here just makes things confusing. Also with the fixes that I made for #6711 I don't believe the issue exists any more. Please describe the conditions where the problem occurs. > If the "binddn" is provided, everything works as expected, with the only minor > issue that the DN of the user as it is known to back-meta may not match the > actual identity the "authcID" assumed on the remote server. The "right" way to > address this problem consists in performing a "WhoAmI" (RFC 4532) right after > the bind, or better use a "authorization identity control" (RFC 3829) along with > the bind operation. Both approaches should be implemented, but they should not > be used unless explicitly requested. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
> masarati@aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. > > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. At the time I looked at this issue, there were places in the code where after an idassert-bind the lc_bound_ndn would receive a copy of idassert's authcDN. In case of SASL, this is empty/null; then back-ldap (and meta) would fail from recognizing the connection as successfully bound. I understand there are better solutions; for example, ldapconn_t could have a "bound" flag, or so. I understand that code may need some reworking, but I can't work at that now, sorry. p. >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >
> masarati@aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. I understand the fix I'm suggesting can sound counter-intuitive. The documentation should clearly indicate that the binddn in case of SASL is for *local* and *internal* issues, and will not be part of the authentication process. As an alternative, lc_bound_ndn could receive a dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive the actual identity from the remote server using the authid control along with the bind or performing a whoami extop later, as already implemented). p. > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. > >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >
masarati@aero.polimi.it wrote: >> masarati@aero.polimi.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: HEAD/re24 >>> OS: irrelevant >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (2.40.14.92) >>> Submitted by: ando >>> >>> >>> When idassert-bind is configured to use SASL bind, an "authcID" needs to >>> be >>> provided, while the "binddn" is not needed. However, if a "binddn" is >>> not >>> provided as well, in some cases the proxiedAuthz control may be used >>> incorrectly. The need to configure the "binddn" is not documented, so >>> this ITS >>> is minimally addressed by documenting this requirement. >> >> I tripped over this change while investigating #6711. Adding this >> requirement >> is certainly not the right solution; SASL Binds ordinarily don't require a >> BindDN and requiring it here just makes things confusing. > > I understand the fix I'm suggesting can sound counter-intuitive. The > documentation should clearly indicate that the binddn in case of SASL is > for *local* and *internal* issues, and will not be part of the > authentication process. As an alternative, lc_bound_ndn could receive a > dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive > the actual identity from the remote server using the authid control along > with the bind or performing a whoami extop later, as already implemented). Using a dummy DN here sounds OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Active to Partial
back-ldap ok in HEAD back-meta TODO back-ldap done in RE24 back-ldap redone in RE24
changed notes moved from Incoming to Software Bugs