On 12/1/21 15:34, A. Schulze wrote:
Let me explain my understanding of operating an identity-provider.
- identity-provider = OpenLDAP-Server
- service-provider = dovecot / apache/nginx for example
Well, personally I'd avoid this terminology but well..
- client = MUA / Webbrowser
- any connections between client and service-provider as well as between
service-provider and identity-provider is encrypted
Yepp, TLS everywhere!
- service-provider validating a password get a plaintext password from a client
and transfer it to the identity-provider
The response is only Yes/No = password was right or wrong
-> no service-provider must handle any hashing scheme for that job
- service-provider setting a new password get a plaintext password from a client
and transfer it to the identity provider
-> no service-provider must handle any hashing scheme for that job
- for the identity provider there are only two types of access to an attribute
'userPassword':
compare/authenticate and write.
User's passwords are always transferred un-hashed /to/ the identity-provider.
- the identity-provider takes care for calculations and storage of that hash.
Is this model correct?
Yes, it is correct. One could argue that it's an unnecessary risk that
services receive clear-text passwords from clients. Because if the
service gets hacked you passwords can get stolen therein.
Possible risk mitigations:
- additionally use one-time passwords
- use OAuth 2.0 in services with short-term tokens
And as part of this model I like to avoid any service-provider write a local
pre-hashed userPassword
I'd strongly recommend to disallow any service to write userPassword
values by ACLs.
Instead use an isolated simple central password self-service web app
which you can configure with really paranoid security settings (systemd
sandboxing, AppArmor/SELinux, lean and secure coding, etc.).
Ciao, Michael.
