Documenting the overriding of PostgreSQLs Session Role with Secret in QFC #673
Conversation
Co-authored-by: Guilhem Allaman <40383801+gounux@users.noreply.github.com>
| GRANT user_mielena TO qfield_service; | ||
| ``` | ||
|
|
||
| **QGIS Configuration:** In the QGIS Connection setup, you connect as `qfield_service`, but in the "Session role" field, you enter `user_mielena`. |
There was a problem hiding this comment.
I believe that the idea here could be to keep a generic role in the QGIS PostGIS connection - so maybe a role like admin, qfield_admin or anything more relevant, describing a pg role that has let's say "a lot of grants / powers". Then, the Session Role overriding would happen in the QFieldCloud workers, making use of this QFC_PG_EFFECTIVE_USER Secret.
So I'd maybe not advise to put a Session ROLE in the QGIS connection, since that would be more to happen in QFieldCloud Secrets.
But this is the use case I have in mind, OFC QFC users are free to play with this feature and set a Session ROLE in the QGIS connection.
There was a problem hiding this comment.
Totally agree, so I restructured and added a complete example and made some rephrasing. please have a look. 🥷
| In QGIS, the **Session ROLE** setting allows you to separate **authentication** (logging in) from **authorization** (permissions and identity). | ||
| This utilizes the PostgreSQL `SET ROLE` command. | ||
|
|
||
| ! | ||
|
|
||
| **Use Case: Simplified User Management & Auditing** | ||
|
|
||
| Imagine in the organization with field workers. Managing many unique passwords and updating them in QFieldCloud Secrets is inefficient. Instead, you can use a **Proxy Authentication** approach: |
There was a problem hiding this comment.
Before assessing this, I'd ask for @lukasgraf's thoughts here, our senior auth* expert :)
No description provided.