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.