Hi, rfc-4422 describes an EXTERNAL mechanism. Is there any means of defining and configuring an external authentication and authorization source, like an external sasl server? Or is this just confined to the client to provide an appropriate authorization string?
-Dieter
On 12. mars 2015 13:03, Dieter Klünter wrote:
rfc-4422 describes an EXTERNAL mechanism. Is there any means of defining and configuring an external authentication and authorization source, like an external sasl server? Or is this just confined to the client to provide an appropriate authorization string?
EXTERNAL means the credentials are passed in another layer than SASL (or LDAP): A TLS client certificate, or with ldapi:// (Unix domain sockets) some OSes including Linux can get the user/group ID from the socket. Try "ldapwhoami -H ldapi://".
What you describe sounds to me more like stuff like Kerberos tickets. These are passed inside a SASL mechanism (GSSAPI), after SASL on the server side is configured to check them against a Kerberos server.
Am Thu, 12 Mar 2015 14:00:02 +0100 schrieb Hallvard Breien Furuseth h.b.furuseth@usit.uio.no:
On 12. mars 2015 13:03, Dieter Klünter wrote:
rfc-4422 describes an EXTERNAL mechanism. Is there any means of defining and configuring an external authentication and authorization source, like an external sasl server? Or is this just confined to the client to provide an appropriate authorization string?
EXTERNAL means the credentials are passed in another layer than SASL (or LDAP): A TLS client certificate, or with ldapi:// (Unix domain sockets) some OSes including Linux can get the user/group ID from the socket. Try "ldapwhoami -H ldapi://".
RFC 4422 describes a 'EXTERNAL mechanism allows a client to request the server to use credentials established by means external to the mechanism to authenticate the client.'
What you describe sounds to me more like stuff like Kerberos tickets. These are passed inside a SASL mechanism (GSSAPI), after SASL on the server side is configured to check them against a Kerberos server.
It is a more bit complicated than Krb5 and GSSAPI. I'm in a erlang/OTP environment which provides an authorization server, called sasl server. I have no clue yet, what this sasl server provides. But there is a requirement that slapd accepts the authorization string, which should be mapped to a DN. Mapping seems to be not a problem.
-Dieter
On 03/12/15 20:24 +0100, Dieter Klünter wrote:
Am Thu, 12 Mar 2015 14:00:02 +0100 schrieb Hallvard Breien Furuseth h.b.furuseth@usit.uio.no:
What you describe sounds to me more like stuff like Kerberos tickets. These are passed inside a SASL mechanism (GSSAPI), after SASL on the server side is configured to check them against a Kerberos server.
It is a more bit complicated than Krb5 and GSSAPI. I'm in a erlang/OTP environment which provides an authorization server, called sasl server. I have no clue yet, what this sasl server provides. But there is a requirement that slapd accepts the authorization string, which should be mapped to a DN. Mapping seems to be not a problem.
Doesn't sound like EXTERNAL is appropriate here. Cyrus SASL has designed its EXTERNAL support around the idea of the server having a priori knowledge of who the user is, outside of the SASL exchange. You can't "tell" slapd who the user is, or at least without modifying slapd code.
With EXTERNAL, you would not submit an authentication identity, only an authz identity, *if* you wished to be authorized as another user.
Consider implementing a new SASL mechanism, or modifying the existing OTP code. If software is advertising itself as a "sasl server", then perhaps they've already implemented this.
openldap-technical@openldap.org
-
Dan White -
Dieter Klünter -
Hallvard Breien Furuseth