Re: Implementing additional passwords with limited scope / "app passwords"

[Michael Ströder <michael@stroeder.com>]

On 4/24/19 9:37 AM, Christoph Biedl wrote:
> looking for a way to implement alternative passwords for a given object
> (i.e. account information). The tricky part, such passwords should not
> be usable in every application but e.g. for mail access only, not for
> interactive login.

It really depends on how fine-grained you need it.

It might be worth to look into OAuth2 tokens but the client and server
have to support this.

> The "restriction to an application" logic could possibly be implemented
> using an attribute I'd call "capability", but I have no clue how to
> handle the passwords.

Bear in mind that bind requests are anonymous per se and slapd does not
have authenticated information about which LDAP client application sent
the bind request. So the really tricky part is to determine in the
OpenLDAP server which application sent the bind request to authorize the
authentication.

Hint: What you can authorize is the user entry search operation sent by
the application prior to the bind request.

> Findings so far: It is possible to store more than one userPassword in
> an account object, but now I cannot see how to tell apart which of the
> ones was used for successful binding, and I reckon this is not possible
> at all in a sane way.
> 
> Enhancing the schema I might store the the extra password/capabilities
> combos in separate objects. But this creates the question how to deal
> with applications that don't allow to enter the entire request string.
> 
> Another idea I could think of was to have separate objects
> ("cn=john.doe", "cn=john.doe+login") - but I consider that ugly.

Those are the reasons why I'm doing something like this in
https://ae-dir.com with completely separate accounts.

If you find this ugly then I think it's unlikely you'll find a "nice"
solution.

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature