openstack
/
keystone-specs
Code Issues Proposed changes

Update patch set 11 

Patch Set 11:

(1 comment)

Patch-set: 11
Attention: {"person_ident":"Gerrit User 27900 \u003c27900@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_28356\u003e replied on the change"}
Attention: {"person_ident":"Gerrit User 28356 \u003c28356@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_28356\u003e replied on the change"}
This commit is contained in:
Gerrit User 28356 2024-01-29 10:43:15 +00:00 committed by Gerrit Code Review
parent cd9ea6f41a
commit eef898ed57
1 changed files with 18 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
90ffbc6081dee41196fcda7be249c02c9f0364ea
View File

@ -16,6 +16,24 @@
"message": "I am generally absolutely supporting such step, but miss few things to be explicit here:\n\n- should the mapping be persisted when user logs in or the information stays dynamic only in the token? Keeping it dynamic would have in my eyes potential for issues with services and for users it would be absolutely in transparent (who in the domain is currently having which roles/projects)\n\n- If changes are persisted upon user log in - what happens when the definition changes (projects/roles removed). Are \"old\" values purged or only new changes are added? AFAIK current behavior is to keep old data and apply new (what is bad). If we are about to add more dynamics, shouldn\u0027t we add also possibility to specify whether new mapping should be simply applied or \"replace\" the current one? I guess this possibility would be actively used by many.",
"revId": "90ffbc6081dee41196fcda7be249c02c9f0364ea",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
},
{
"unresolved": false,
"key": {
"uuid": "ad3ed5e5_18a515a6",
"filename": "/PATCHSET_LEVEL",
"patchSetId": 11
},
"lineNbr": 0,
"author": {
"id": 28356
},
"writtenOn": "2024-01-29T10:43:15Z",
"side": 1,
"message": "Awesome questions!\n\nI already implemented, in the patch that needs rebasing, but let me answer your doubts. I will also add these details in the spec.\n\n- should the mapping be persisted when user logs in or the information stays dynamic only in the token\n\nA: We implemented them to be persistent. Then, one cab easily audit/debug/troubleshoot after the user accesses the system.therefore, for every federated login, the information Keystone has are updated, similarly to what happens today with username, email, and so on.\n\n- If changes are persisted upon user log in - what happens when the definition changes (projects/roles removed)\n\nA: That is also already considered. We remove the assignments that the user lost in the identity provider, we add the new ones, and we update the ones that were changed (e.g. role addition or removal for a user in a project).",
"parentUuid": "4a1cc2cf_e50b75d3",
"revId": "90ffbc6081dee41196fcda7be249c02c9f0364ea",
"serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
}
]
}