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.