Sorry if I asked about this before and forgot it...
Could we add an 'access ... by' variant for the client's TLS certificate, _without_ Bind:SASL/EXTERNAL? (To the cert's DN, I expect, but I don't know much about certificates. Maybe there are other things to look at as well.)
That could be used to authenticate a service (an LDAP client) rather than the user it Binds as, when the service asks the user for password and Binds with his DN and password.
The simple way to do that is to grant access to the service's IP address, but that's not always feasible, and gets hard to maintain.
Hallvard B Furuseth wrote:
Sorry if I asked about this before and forgot it...
Could we add an 'access ... by' variant for the client's TLS certificate, _without_ Bind:SASL/EXTERNAL? (To the cert's DN, I expect, but I don't know much about certificates. Maybe there are other things to look at as well.)
That could be used to authenticate a service (an LDAP client) rather than the user it Binds as, when the service asks the user for password and Binds with his DN and password.
The simple way to do that is to grant access to the service's IP address, but that's not always feasible, and gets hard to maintain.
This sounds like a special case of proxy authorization. Can't you just use that?
Howard Chu writes:
Hallvard B Furuseth wrote:
Could we add an 'access ... by' variant for the client's TLS certificate, _without_ Bind:SASL/EXTERNAL? (To the cert's DN, I expect, but I don't know much about certificates. Maybe there are other things to look at as well.)
That could be used to authenticate a service (an LDAP client) rather than the user it Binds as, when the service asks the user for password and Binds with his DN and password. (...)
This sounds like a special case of proxy authorization. Can't you just use that?
Not that I can see. man slapd.conf says under authz-policy: Proxy authorization (...) essentially allows user A to login as user B, using user A's password. But I want the service to authenticate the user with his own credentials and identify itself with its credentials, and use both identities for access control in a single access statement.
A more general description would be, grant access based on the DN which would be used if the client were to do Bind:SASL/EXTERNAL, or possibly the DN which would be passed to authz-regexp.
access to ... by self extdn=<certificate's DN> write by * read
Hallvard B Furuseth wrote:
Howard Chu writes:
Hallvard B Furuseth wrote:
Could we add an 'access ... by' variant for the client's TLS certificate, _without_ Bind:SASL/EXTERNAL? (To the cert's DN, I expect, but I don't know much about certificates. Maybe there are other things to look at as well.)
That could be used to authenticate a service (an LDAP client) rather than the user it Binds as, when the service asks the user for password and Binds with his DN and password. (...)
This sounds like a special case of proxy authorization. Can't you just use that?
Not that I can see. man slapd.conf says under authz-policy: Proxy authorization (...) essentially allows user A to login as user B, using user A's password. But I want the service to authenticate the user with his own credentials and identify itself with its credentials, and use both identities for access control in a single access statement.
A more general description would be, grant access based on the DN which would be used if the client were to do Bind:SASL/EXTERNAL, or possibly the DN which would be passed to authz-regexp.
access to ... by self extdn=<certificate's DN> write by * read
I guess it's feasible to implement this. It seems to me that this would mean executing the DN mapping code even though SASL/EXTERNAL wasn't invoked, which seems a tad wasteful. It may be appropriate to skip the mapping and only use the raw DN here, since it's not actually being associated with any particular user.
-
Hallvard B Furuseth -
Howard Chu