You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Originally posted by ChrisMagnuson April 1, 2024
I am currently using a managed PostgreSQL instance that doesn't allow me to provision additional roles but provides me with a role to use that was setup via their automated provisioning process.
I am also using an OIDC provider that does not allow me to customize the claims that are provided in the id_token jwt and currently there is no claim in the token that matches the name of the role provisioned in postgres.
Per the documentation if the jwt doesn't have a role claim (or another claim that matches the jwt-role-claim-key) then it will default back to the anonymous role.
In this scenario postgrest was able to use the jwt-secret to confirm that the id_token jwt is valid (comes from an issuer that knows the secret or if using RSA, has the private key that corresponds with the public key configured as the jwt-secret) and it also confirms that the id_token has not expried but it then drops back to anonymous access because of the missing role.
I would like to give users who don't have a role claim but do have a valid unexpired id_token access to postgrest without having to grant access to anonymous users.
Right now postgrest treat's users who have a valid unexpired id_token as just as unauthenticated as someone completely anonymous and I would like to treat user's in that category differently.
The idea would be to have something like a db-noclaim-role configuration parameter that would be used to assign a role to users who have a valid unexpired id_token jwt but don't have a claim that matches the path defined in jwt-role-claim-key.
Is this something that the team would be open to receiving as a pull request or would there be a better way to handle this situation given that I don't control either postgres or the OIDC providers?
Ps, if this is something that would be better posted elsewhere please let me know.
The text was updated successfully, but these errors were encountered:
I would like to give users who don't have a role claim but do have a valid unexpired id_token access to postgrest without having to grant access to anonymous users.
I can see how it makes sense to make a difference between those.
The idea would be to have something like a db-noclaim-role configuration parameter that would be used to assign a role to users who have a valid unexpired id_token jwt but don't have a claim that matches the path defined in jwt-role-claim-key.
Maybe something like db-authenticated-fallback-role or so? That would match db-anon-role a bit.
@wolfgangwaltherdb-authenticated-fallback-role sounds good to me, is there anyone else's input that is needed or should I go ahead and start working on this based on the description provided?
wolfgangwalther
changed the title
Adding support for a generic authenticated user role, irresepctive of jwt-role-claim
Adding support for a generic authenticated user role, irrespective of jwt-role-claim
Apr 3, 2024
Discussed in #3366
Originally posted by ChrisMagnuson April 1, 2024
I am currently using a managed PostgreSQL instance that doesn't allow me to provision additional roles but provides me with a role to use that was setup via their automated provisioning process.
I am also using an OIDC provider that does not allow me to customize the claims that are provided in the id_token jwt and currently there is no claim in the token that matches the name of the role provisioned in postgres.
Per the documentation if the jwt doesn't have a role claim (or another claim that matches the
jwt-role-claim-key
) then it will default back to the anonymous role.In this scenario postgrest was able to use the
jwt-secret
to confirm that the id_token jwt is valid (comes from an issuer that knows the secret or if using RSA, has the private key that corresponds with the public key configured as thejwt-secret
) and it also confirms that the id_token has not expried but it then drops back to anonymous access because of the missing role.I would like to give users who don't have a role claim but do have a valid unexpired id_token access to postgrest without having to grant access to anonymous users.
Right now postgrest treat's users who have a valid unexpired id_token as just as unauthenticated as someone completely anonymous and I would like to treat user's in that category differently.
The idea would be to have something like a
db-noclaim-role
configuration parameter that would be used to assign a role to users who have a valid unexpired id_token jwt but don't have a claim that matches the path defined injwt-role-claim-key
.Is this something that the team would be open to receiving as a pull request or would there be a better way to handle this situation given that I don't control either postgres or the OIDC providers?
Ps, if this is something that would be better posted elsewhere please let me know.
The text was updated successfully, but these errors were encountered: