Re: Implementing additional passwords with limited scope / "app passwords"
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.
Attachments:
- smime.p7s (application/pkcs7-signature — 3.9 KB)