Hello,
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. Such a feature can be seen in the nextcloud application where such "app passwords" may be unusable for accessing files while the calendar can still be read and written. The idea behind this is obviously being able to store such a password on a mobile device that might got stolen or lost otherwise - without compromising all other services the account credentials are be valid for. The global (or default) password should still be usable in any place - although users should avoid that.
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.
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.
Other ideas? Or even solutions that already exist?
Christoph
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.
openldap-technical@openldap.org
-
Christoph Biedl -
Michael Ströder