Am 26.06.2025 um 14:27 schrieb Peter J. Holzer:
On 2025-06-25 17:55:12 +0200, raphi wrote:
Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
On 2025-06-25 14:42:26 +0200, raphi wrote:
That's not how the identiy principle works, at least not how it's
implement in our company. A user in ldap has a direct relation to
one digital entity, either a token from an application or
certificate from a physical person (maybe some AD shenanigans
also). We don't have digital entities for teams, that's what's
missing. For it to work they (security) would need to allow to
weaken this principle and as you said, allow everyone who has a
certain role to manage the associated user in LDAP, like setting a
new password.
That user shouldn't have a password, since nobody is authenticating as
that user. It also doesn't have to exist in LDAP. It's just a role in
the database.
hmm I don't follow, maybe I was doing it wrong?
I'm thinking of something like this:
Roles assigned to people are in LDAP, and only they have passwords.
Application roles don't have to be in LDAP (maybe there are operational
reasons to have them there, but PostgreSQL doesn't need them) and don't
have passwords.
Thank you very much for the detailed test. It will be useful for other
ideas I have but (I think) it does not solve our particular case. Maybe
I wasn't clear enough and I'm sorry for that, but our problem lies in
the way how applications connect. The passwords that devs are ordering
via our self service is for the application that is connecting to the
database, not for themselfs. It's the application's password that we
want to ensure that it is complex and gets changed after we set an
initial password for it. Because PG does not do it, we wanted to resolve
this with LDAP but failed due to IAM.
But, I just returned from the once again phenomenal Swiss PGDays and I
had the chance to talk to Laurenz and Dani and I can say, that I finally
get it now. Laurenz explained very well how the whole authentication
works and that the philosophy is that the postgres server should never
know any passwords. I think that's what Tom tried to say but I failed to
understand it correctly, I thought the issue is not having unencrypted
passwords being sent over the network. So, why this also does not solve
our problem, I am giving up on trying to use PG to enforce some password
rules, I'm not even sure if credcheck is still a good idea. But the more
I think about it the more I like switching to certificates, after all we
already have mechanisms in place to automatically get new officially
trusted (not selfsigned) certificates, it could be adoptable for PG
connects too. I'm just not sure how and if all our applications can
adopt this, but that's a "me" problem.
Anyways, thanks to everyone who helped me see the PG way, I won't bother
anyone with this topic again ;)
have fun,
raphi
