public inbox for [email protected]
help / color / mirror / Atom feedFrom: raphi <[email protected]>
To: [email protected]
Subject: Re: password rules
Date: Fri, 27 Jun 2025 19:00:36 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
view thread (7+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: password rules
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox