Re: password_rollover_time like Oracle

On Thu, Jun 20, 2024 at 08:53:02PM -0400, Rui DeSousa wrote:
> It can be achieved by using roles and rolling accounts. Then the application
> would need to update username/password before it expires to the new account/
> password. The only difference is rather than changing just the password the
> account information also changes; however, no permissions are ever given
> directly to the user account. I’ve been in an environments that have use this
> approach — Just remember to create the new user and update the username/
> password before they expire.
>
> i.e.
>
> approle (A role with no login and all the application permissions)
>
> create user appuser202406 with inherit in role approle valid until '07/01/2024'
> encrypted password 'xxxx’;
> create user appuser202407 with inherit in role approle valid until '08/01/2024'
> encrypted password ‘yyyy';

I can see that causing problems if you want to store CURRENT_USER in the
database, perhaps for auditing. I guess you could call it user4_login12
and keep incrementing the login number, but that seems cumbersome.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.