)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"1295f37bd201c33aa2cef7b2f3cad3c28506f6de","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"02070b4d_e18134ab","updated":"2022-06-24 13:20:26.000000000","message":"Thanks for the review Alexandre!\n\nThe whole idea to use the schema version is that we are trying to work as safe as possible. To enable us to enable/disable features. The schema versioning allow us to achieve that. That is why it was put as requirement to this patch. So, we can control/revert any new feature/option that is enabled in the identity federation integration of Keystone.\n\nIt is not an issue for this one to depend on that. The issue is that these patches, and specially that proposal got stuck. They could have been merged already.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28332,"name":"Alexandre arents","email":"alexandre.arents@corp.ovh.com","username":"aarents"},"change_message_id":"283838885c031cd286a1475d8c76d2a30b061476","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"dd35df8c_9aded1ff","updated":"2022-06-24 13:06:07.000000000","message":"Thks Rafael for submitting this, we also are interested to have this feature on, as we want to plug keystone a centralized IAM service, that will be aware of project/user/role ownership for wide range of customers. Handling service access via projects_json in this case is much more scalable than constantly updating a static huge mapping entry through keystone api.\n\nI\u0027m globaly fine with this specs, except the few comments related to dependancy with another change \u0027honor domain\u0027, which I think is not necessary here.\n\nNote that we propose an alternative implementation here: https://review.opendev.org/c/openstack/keystone/+/844098 (still need few work)that do not require mapping schema versioning.\n\n","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b8dfd51a1af9fdce8ff9edd448af9b7811f431","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"719a9c0a_1ff9a656","in_reply_to":"10c146b7_a0f33ce7","updated":"2024-01-26 17:51:21.000000000","message":"Done","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28595,"name":"Victor Coutellier","email":"victor.coutellier@gmail.com","username":"alistarle"},"change_message_id":"46bf645494b86b2e5cde852a7ce661847b1d0c15","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"10c146b7_a0f33ce7","in_reply_to":"a97fa0cb_38ef9eba","updated":"2022-06-24 13:51:06.000000000","message":"I totally agree that versioning the schema can be handled, and produce a lot of advantage, but I think in this case it is not necessary to put that as a dependency of this particular spec. Indeed, adding a new non breaking field in the API should be transparent for the user, and can only produce a microversion bump like in other Openstack project, or even lately in keystone for v3.14: https://github.com/openstack/keystone/commit/8153a9d5925b0ba60e43329ff6bfb5a4d1a12f97\n\nI just think it is easier for every reviewer to put less dependency between patches, and to take them on their own if possible.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"1295f37bd201c33aa2cef7b2f3cad3c28506f6de","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":8,"id":"a97fa0cb_38ef9eba","in_reply_to":"dd35df8c_9aded1ff","updated":"2022-06-24 13:20:26.000000000","message":"The requirement is on purpose. So, we easily maintain this extensions. The patch that this one depends on is the patch that introduces the schema versioning. It should already have been merged, but it was ignored for a long time. I am trying to reach Keystone folks with core review premission to move on with that patch without success.\n\nP.S. the requirement of schema versioning is not a bad thing. It is a good thing to facilitate further developments. For instance, we already implemented internally extensions of top of this one such as roles \"activation_rules\", which means, rules inside the roles of projects that define when they should/can be assigned to users according to attributes that come from the IdP and the context of the user accessing the system (e.g. time, source IP, and so on).","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"7ed0cd757c2277c42a017e57d6087919551e7a83","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"5ebdabe9_770fc064","updated":"2022-06-24 13:41:54.000000000","message":"Alexandre, \n\nWe also already had a patch open for a very very long time for this spec: https://review.opendev.org/c/openstack/keystone/+/742235","commit_id":"33e032fd865d24b24e4197bbc0740f96fcf513d9"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"8424bd6256b575d2e92cea71eaa599ee48ed5dcb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"064e80f7_66a20418","updated":"2024-01-26 17:47:04.000000000","message":"Now that the initial patch for schema_version is merged, I updated this spec to move on the follow-ups","commit_id":"33e032fd865d24b24e4197bbc0740f96fcf513d9"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"cd9ea6f41a342ec639ce189d8f84e585c301a7dc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"4a1cc2cf_e50b75d3","updated":"2024-01-29 08:22:48.000000000","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.","commit_id":"90ffbc6081dee41196fcda7be249c02c9f0364ea"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"82ae01778f2848772155288f9a47793bc52323d5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"9c5d6485_482ab577","in_reply_to":"2e600f95_cf6fdd1c","updated":"2024-01-29 10:51:48.000000000","message":"Technically speaking, one should not mix federated user management with local user management. Otherwise, we break the control over the user permissions and authentication processes. I know that systems such as Gitlab and others allow such use cases. However, when you look at the identity federation concept, authentication should be handled by the Identity provider (IdP), and authorization by the service provider (SP) with the attributes released by the IdP after the user authentication and consent. Therefore, we should not allow such situation. I will add the sentence in the spec in bold as you suggested.","commit_id":"90ffbc6081dee41196fcda7be249c02c9f0364ea"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"eef898ed575c257053bb7aefc512f11939035abb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"ad3ed5e5_18a515a6","in_reply_to":"4a1cc2cf_e50b75d3","updated":"2024-01-29 10:43:15.000000000","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).","commit_id":"90ffbc6081dee41196fcda7be249c02c9f0364ea"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c9f5d31c08d44318ed5893b3c924719bc4a85f15","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":11,"id":"2e600f95_cf6fdd1c","in_reply_to":"ad3ed5e5_18a515a6","updated":"2024-01-29 10:47:11.000000000","message":"A: 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).\n\nGreat. But what if there are local physical assignments (imagine user is granted admin role on the domain or something similar). So if every time user logs it user gets roles replaces that means ALL roles must be defined in Keycloak and all local roles can not be considered persistent. I think this need to be written in **bold**","commit_id":"90ffbc6081dee41196fcda7be249c02c9f0364ea"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"c178e9b8096b6ed3569b0fc55b3a785d4b40de8c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"3165f5d1_a00946e1","updated":"2024-02-06 13:28:05.000000000","message":"Hello guys, \nToday we have the Keystone meeting, are we going to discuss this spec in the meeting? If you need any help or adjusts here, just let me know.","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"671406634b17d12d1899f441d97c771c471767ea","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"0aea7124_b88b9fc3","updated":"2024-01-31 09:54:12.000000000","message":"I am pretty sure there would be other reviews requiring changes, I just show my support with +1.\n\nbtw, looking at the release cycle I am sadly not sure it is possible to get anything new into 2024.1. If Keystone cores are ok keeping the spec tied to that release while the implementation will most likely land only for next release (as a new feature) I would keep it this way","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"change_message_id":"dfbd1f17ee320116d5d0eb395180b188d5d2d330","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"b161c6ae_dd413581","updated":"2024-02-28 17:40:58.000000000","message":"Nice spec, it will help to enhance the project\u0027s users assignments management in environments with federated authentication. I have only a nit suggestion, but nothing so important, then I am leaving my +1.\nThanks for the spec.","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"cc4d594e5a4855718e81d91abea395cc52c20fd5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"212652cf_3d474e34","updated":"2024-02-28 16:58:54.000000000","message":"Thanks David!\n\nAs soon as this one is merged, I will update the patchset for this spec.","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"d808ecd4c6524452224742c5a18b402c9a0794f2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"31e99f41_71c9574b","updated":"2024-02-28 17:44:08.000000000","message":"Thanks Pedro! I amended the spec.","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"ee93767171fd65cde7f899191d37df30ae19546f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"05de247f_aaf6666b","in_reply_to":"0aea7124_b88b9fc3","updated":"2024-01-31 10:11:15.000000000","message":"Thanks for your support and valuable reviews! If it does not go out on 2024.1, it is not a problem.However, as soon as this one is merged, and we have a picture on the feature to be updated in the patch that we already have, I will update it as soon as possible.","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"8222de0bcf0f935712b25c91aaddc42e57fb82d0","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":14,"id":"f8261293_0dbea575","updated":"2024-03-04 14:56:10.000000000","message":"add explicit -1 to underline suggested mapping schema suggestion","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b7fcc467a0740f1c84f683518a7a2ea3be2e30","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":14,"id":"8ab39215_e781b39e","in_reply_to":"f8261293_0dbea575","updated":"2024-04-09 19:25:32.000000000","message":"I responded to your suggestions, and I did the changes that are necessary only.","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"2449aa8040a8a242f190ed50de20be61e7bd87bf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"ef34a7e6_752cec35","updated":"2024-04-12 11:27:22.000000000","message":"I am really sorry to wrongly blame you for introducing the domain attribute.\nYou touched so much code around it and documented it in a way that immediately\nunderlines the issue for me that I made a conclusion you introduced it without\ndooing a deeper check on git blame (btw, I did not mean that you previous\nchange in whole was unnecessary, it only it uncovered certain issues).\n\nLet me start from describing the issue with the domain as a showcase of\npotential issues what is later deepen by adding of the projects_json. You\ndocumented mapping example (in the domain spec and repeat here) as:\n```\n\"local\": [\n   {\n     \"domain\": {\n       \"name\": \"{2}\"\n     },\n     \"user\": {\n       \"domain\": {\n         \"name\": \"{2}\"\n       },\n       ...\n     },\n     \"projects\": [\n       {\n       \"domain\": {\n         \"name\": \"{2}\"\n         },\n         ...\n       }\n     ]\n   }\n```\n\nThere are 3 places that define the domain name. It enables following bug:\n\n```\n\"local\": [\n   {\n     \"domain\": {\n       \"name\": \"{1}\"\n     },\n     \"user\": {\n       \"domain\": {\n         \"name\": \"{2}\"\n       },\n       ...\n     },\n     \"projects\": [\n       {\n       \"domain\": {\n         \"name\": \"{3}\"\n         },\n         ...\n       }\n     ]\n   }\n```\n\nCan user or even developer tell what will happen in this case without looking\ninto the code?\nThis is very nondeterministic and error-prone (both for keystone developers and\nusers). Even if we skip looking at \"projects\" for now there are 2 places where\nvalue can become different either by accident on the operator side or by the\nkeystone maintainer in the treatment and deciding on what takes precedence. It\ncan be even implemented correctly but later corrupted during some refactoring.\nAnd there is no chance to catch this error with input validation. I am not\nfocusing on the \"domain\" as an issue of this spec, I just describe the issue.\n\nNow lets have a look at \"projects_json\". Is there something what prevents\nfollowing?\n\n\n\"local\": [\n  {\n    \"user\": {\n      \"domain\": {\n        \"name\": \"{1}\"\n      }\n    },\n    \"domain\": {\n      \"name\": \"{2}\"\n    },\n    \"projects\": [\n      {\n        \"name\": \"{3}\",\n      }\n    ],\n    \"projects_json\":\"{4}\"\n  }\n],\n```\n\nThis is even more nondeterministic.\n\n- operator does not know how it is going to be handled\n- no possibility for input validation (without ugly hacks)\n- error prone since it requires \"if\" branches in the code with order of\n  branches playing significant role. Having \"if\" in 2 places in the code where\n  they check \"projects or projects_json\" in different order leads to undefined\n  behavior and bugs. An now imagine there is some support for the mapping api in CLI or other tool where similar validation need to be implemented (and surely it is going to be done there differently because ...)\n- and again - this style differs from ALL other OpenStack apis (at least of the\n  core ones)\n\nInstead making \"projects\" be an object OR a string allows you to be absolutely deterministic and do reasonable input validation (look at Nova/Cinder/Neutron API for exactly same pattern). Also in the code directly the chance of introducing bug is much lower since you more or less cover finite enum kinds. Once doing that I would directly extend the \"projects\" object schema to include \"domain\" similarly to all other places across OpenStack where user/project/group/etc are having direct attribute \"domain\". Later (separately) we could address preventing domain value conflicting or deprecate it as such (on the upper level).\n\nI am not intending to crucify anybody, I am just underlining an API design that is different from everything else in OpenStack and is introducing potential bugs. After spending last 6 years deep in the wild jungle of OpenStack APIs (from the tooling side) I notice such things and want us not to introduce new deviations and error-prone patterns.\n\nI will still keep my \"-1\" due to the reasons outlined above and let Keystone cores decide.","commit_id":"8305797037e04aa67186e4aec1e3ee8adfd25ab9"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"fbc2b9dbdb2078bf679884e1c80794106270a61b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"23247a08_cc07ced4","updated":"2024-04-10 09:47:20.000000000","message":"still -1\n\n- previous change of adding \"domain\" field was unnecessary, since it is already present under the user. Sadly this became clear only after landing the implementation and starting deploying the feature\n- jsonschema was modified in a previous change with an error (see https://review.opendev.org/c/openstack/keystone/+/915401). Sadly also this became clear only accidentally from another initiative\n- all this forces me to become nitpicky. Mapping schema is already over-complicated for understanding (especially having domain property duplicated causes confusion for most parties that started relying on the changed functionality - nobody understands clearly its purpose and side-effects when user.domain !\u003d domain or only one of them set). Adding new field into the schema (projects_json) just to save few lines of code is not a good design and strongly differs from the pattern in all other Keystone APIs and especially in the same api (https://opendev.org/openstack/keystone/src/branch/master/keystone/federation/utils.py#L107 or https://opendev.org/openstack/keystone/src/branch/master/keystone/federation/utils.py#L129 for reference). I am strongly against of adding \"projects_json\" parameter and prefer extending existing \"projects\" field\n\nThe change purpose is good, the API change is bad from my perspective","commit_id":"8305797037e04aa67186e4aec1e3ee8adfd25ab9"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"9ef2fc0cf8b45f1987c4dd2637a7c4be2b3c1bb5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"d192afcb_c899f0c1","in_reply_to":"23247a08_cc07ced4","updated":"2024-04-10 11:41:58.000000000","message":"Hello Artem, \nThe previous normalization of the Domain was necessary. We tried to use that ourselves, and we just found out that it does not work after checking the code. The domain in the user definition was expected to override the domain in the root of the definition, but it was not doing that. It can be used as an override mechanism, as it is already used for other elements, such as group and project. Then, one can have a generic domain defined at the root of the mapping definition, and an override at a specific element (user/project/group).\n\nAgain, we did not introduce that domain at the root, we just made the code to respect/follow the domain defined at the user(object) that is defined in the attribute definition.\n\nRegarding the schema that you pointed out. That indeed slipped by, but that is not used in the code, I checked, and we have that internally. We never saw the problem because we were not adding the schema_version in the attribute mapping itself, we were just passing via the API. I already gave my +1 there in your patch. Sorry for that mistake.\n\nRegarding the field \"projects_json\", what makes you feel so strongly against it? Could you describe/explain in detail?\n\nI mean, just saying that you did not understand/like the use of domain at the root of the attribute mapping schema is not enough to justify something like that. Also, a small mistake made in a patch (that we had to maintain and worked to carry it along 4 years, where we never understood why people were so strong against it) does not justify crucifying somebody; anyways, water under the bridge. \n\nI also would like to stress that the use of \"domain\" at the attribute mapping schema root level was not introduced by us. We just added the support to override it in the user object that is defined in the attribute mapping schema with the very first attribute schema; this in fact was already being done for project and group definitions. That processing of domain in different levels is an override mechanism; if you do not understand what that means, I can try to illustrate for you some more detailed explanation. However, and again, it is not introduced by me, and it is what we understand from the code we can see.","commit_id":"8305797037e04aa67186e4aec1e3ee8adfd25ab9"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"918345bdaa448eb04d068c0b9fb9ef84e437123e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"b788664e_f5c8b476","in_reply_to":"ef34a7e6_752cec35","updated":"2024-04-12 14:43:36.000000000","message":"Thanks for taking this further and debating here. I find these opportunities precious to evolve the project. I understand why you thought we had added that. However, I also do not understand the current structure and its reasoning. Therefore, we have always worked to add on top of it, while maintaining the previous options and behaviors.\n\n\u003e Can user or even developer tell what will happen in this case without looking into the code?\n\nWell, depends on how versed they are. I mean, looking at what you described, I would expect (without looking at the code) that a domain is created with parameter \"{1}\", but not used; then, a user is created on domain \"{2}\", and a project on domain \"{3}\", and the user on domain \"{2}\" will receive permission on a project on domain \"{3}\".\n\nI would not consider it a bug, but rather a flexibility that the current implementation allows. It is not bad, it is just flexible; maybe too flexible for most people. What can be done in these situation, which OpenStack sometimes lack is logs that describe the processing, and that can be used by operators to understand the behaviors of the system. While implementing the initial patch of the schema_version, I worked to add that.\n\nTherefore, what we seem to be lacking is documentation, with some more examples, and not necessarily some other changes. Anyways, if we wish to change that, we can create a new schema_version that removes those options/parameters.\n\n\u003e Now lets have a look at \"projects_json\". Is there something what prevents following?\n\nFor this situation, again, it depends on how the person interprets things. There are two possibilities. Override \"projects\" (the hardcoded one) with \"projects_json\" or complement them. I am the author of the patch, therefore, I prefer the addition, instead of the override in this situation, which is what I implemented [1].\n\n```\noperator does not know how it is going to be handled\n```\n\nFor this one, we can improve/add documentation and work from there. There will never be a clear option/feature set without them.\n\n```\n- no possibility for input validation (without ugly hacks)\n\n```\n\nI did not understand what you mean with that.\n\n```\n- error prone since it requires \"if\" branches in the code with order of\n  branches playing significant role. Having \"if\" in 2 places in the code where\n  they check \"projects or projects_json\" in different order leads to undefined\n  behavior and bugs. An now imagine there is some support for the mapping api in CLI or other tool where similar validation need to be implemented (and surely it is going to be done there differently because ...)\n\n```\n\nWe are not implementing like that adding many more conditionals and so on; ee are using Object orientation. Moreover, we can make clear in the spec that the project_json appends to the hard-coded project definition. That is simple and easy to achieve. And then everybody would be on the same page regarding this behavior.\n\n```\n- and again - this style differs from ALL other OpenStack apis (at least of the core ones)\n\n```\nI also do not understand what you mean by this one as well.\n\n```\n\n\nInstead making \"projects\" be an object OR a string allows you to be absolutely deterministic and do reasonable input validation (look at Nova/Cinder/Neutron API for exactly same pattern). Also in the code directly the chance of introducing bug is much lower since you more or less cover finite enum kinds. Once doing that I would directly extend the \"projects\" object schema to include \"domain\" similarly to all other places across OpenStack where user/project/group/etc are having direct attribute \"domain\". Later (separately) we could address preventing domain value conflicting or deprecate it as such (on the upper level).\nI am not intending to crucify anybody, I am just underlining an API design that is different from everything else in OpenStack and is introducing potential bugs. After spending last 6 years deep in the wild jungle of OpenStack APIs (from the tooling side) I notice such things and want us not to introduce new deviations and error-prone patterns.\n```\n\nWe are validating the project_json with the project schema [2]. I will add this to the spec, but this was already expected. This might be just a problem of communication.\n\n\n[1] https://review.opendev.org/c/openstack/keystone/+/742235/6/keystone/federation/utils.py#1059\n\n[2] https://review.opendev.org/c/openstack/keystone/+/742235/6/keystone/federation/utils.py#1092","commit_id":"8305797037e04aa67186e4aec1e3ee8adfd25ab9"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"3bc9259256200325e435596bfddf1682263bb413","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":16,"id":"cf2a16a6_a66f1dac","updated":"2024-04-12 15:52:38.000000000","message":"\u003e I am the author of the patch, therefore, I prefer the addition, instead of the \u003e override in this situation, which is what I implemented [1].\n\nSure, it\u0027s your right. Same as it is my right to express my opinion.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":14250,"name":"Grzegorz Grasza","email":"xek@redhat.com","username":"xek"},"change_message_id":"b1aba61da6c2d5057cb582ba9953dc45d6c16607","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":17,"id":"ad30d559_2f9d68f8","updated":"2024-06-28 15:11:09.000000000","message":"LGTM!","commit_id":"66f9c28bd4d7a8930e3b9f1fd792e90457e809d1"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"a723348c3e0dffad1e1c691966ddb042e2bcf528","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":17,"id":"9c1e6d2c_6bbce8df","updated":"2024-06-26 11:32:35.000000000","message":"Thank you all for reviewing the patch. I amended the proposal as required.\n\nSorry for the delay, some other pressing matter appeared, and I only had time to return to this topic today. \n\nIf you guys are fine with it now, as soon as this one is merged, I can work on the code to implement the spec.","commit_id":"66f9c28bd4d7a8930e3b9f1fd792e90457e809d1"},{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"74793091f928872e60a1051a71a312f71024a9ab","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":17,"id":"4e35273f_dae62c14","updated":"2024-06-28 15:14:33.000000000","message":"This looks good to me as well, but I\u0027m going to hold off on merging it for a couple of days to give the other reviewers a chance to voice their opinion.","commit_id":"66f9c28bd4d7a8930e3b9f1fd792e90457e809d1"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"442a94513011dec2a76ab315c93b87152dc1b07f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":17,"id":"681eebb8_70ee98d9","in_reply_to":"4e35273f_dae62c14","updated":"2024-06-28 16:00:36.000000000","message":"Thank you all guys! As soon as it is merged we will work on the patch.","commit_id":"66f9c28bd4d7a8930e3b9f1fd792e90457e809d1"}],"specs/keystone/2024.1/federated-identity-mapping-support-project-json-definition.rst":[{"author":{"_account_id":30695,"name":"Pedro Henrique Pereira Martins","email":"phpm13@gmail.com","username":"pedrohpmartins"},"change_message_id":"dfbd1f17ee320116d5d0eb395180b188d5d2d330","unresolved":true,"context_lines":[{"line_number":13,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":14,"context_line":"Currently, the project assignment via the federated identity mapping is rather"},{"line_number":15,"context_line":"static. This happens because of the find/replace mechanism that we have in"},{"line_number":16,"context_line":"place there. Therefore, if the IdP provider generates an attribute that"},{"line_number":17,"context_line":"contains a JSON with project definitions, we are not able to handle it"},{"line_number":18,"context_line":"in Keystone."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"fc92ebc9_0e225928","line":16,"range":{"start_line":16,"start_character":35,"end_line":16,"end_character":43},"updated":"2024-02-28 17:40:58.000000000","message":"IdP or Identity Provider, guess IdP provider is redundant","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"d808ecd4c6524452224742c5a18b402c9a0794f2","unresolved":false,"context_lines":[{"line_number":13,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":14,"context_line":"Currently, the project assignment via the federated identity mapping is rather"},{"line_number":15,"context_line":"static. This happens because of the find/replace mechanism that we have in"},{"line_number":16,"context_line":"place there. Therefore, if the IdP provider generates an attribute that"},{"line_number":17,"context_line":"contains a JSON with project definitions, we are not able to handle it"},{"line_number":18,"context_line":"in Keystone."},{"line_number":19,"context_line":""}],"source_content_type":"text/x-rst","patch_set":13,"id":"17713872_8f67b692","line":16,"range":{"start_line":16,"start_character":35,"end_line":16,"end_character":43},"in_reply_to":"fc92ebc9_0e225928","updated":"2024-02-28 17:44:08.000000000","message":"agree","commit_id":"d44747e2d457f9405e177f1bddfdae5ddc0bd2cf"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"a4bc61a3d6d0d964adb6c93535702be692a0f6b9","unresolved":true,"context_lines":[{"line_number":134,"context_line":"                      \"name\":\"{2}\""},{"line_number":135,"context_line":"                   }"},{"line_number":136,"context_line":"                },"},{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""}],"source_content_type":"text/x-rst","patch_set":14,"id":"d53002b1_fd0fb467","line":137,"updated":"2024-02-28 18:40:14.000000000","message":"I actually suggest to drop this here. User domain is already specified few lines above and works as expected. Specifying it 2 times confuses users (admins) about how to configure it properly.\nI honestly think it was a failure to introduce it previously since domain is an attribute of the user and project (literally everywhere)","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"a332c5225d71a676b2107705acd48e240cb9ccda","unresolved":true,"context_lines":[{"line_number":134,"context_line":"                      \"name\":\"{2}\""},{"line_number":135,"context_line":"                   }"},{"line_number":136,"context_line":"                },"},{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""}],"source_content_type":"text/x-rst","patch_set":14,"id":"ad356ee2_4e078b00","line":137,"in_reply_to":"9d5bb5b7_c47ecb6d","updated":"2024-02-28 19:43:25.000000000","message":"yes, but you describe it here and in the implementation. specifying the same value in 2 different places is confusing (and doc does not really help to understand value impact). specifying domain not under user alone is not correct, while it still works.","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b7fcc467a0740f1c84f683518a7a2ea3be2e30","unresolved":false,"context_lines":[{"line_number":134,"context_line":"                      \"name\":\"{2}\""},{"line_number":135,"context_line":"                   }"},{"line_number":136,"context_line":"                },"},{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""}],"source_content_type":"text/x-rst","patch_set":14,"id":"82914e19_d3207b74","line":137,"in_reply_to":"ad356ee2_4e078b00","updated":"2024-04-09 19:25:32.000000000","message":"I sincerely do not see the problem. This is just an example, and should be taken as such. We do not need to follow it\n\nI added a note to stress that before the example of configuration is shown.","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"d43b5a1e1fd35fb21f83f5fd3f3e143a4b9c186f","unresolved":true,"context_lines":[{"line_number":134,"context_line":"                      \"name\":\"{2}\""},{"line_number":135,"context_line":"                   }"},{"line_number":136,"context_line":"                },"},{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""}],"source_content_type":"text/x-rst","patch_set":14,"id":"9d5bb5b7_c47ecb6d","line":137,"in_reply_to":"d53002b1_fd0fb467","updated":"2024-02-28 19:06:40.000000000","message":"I am not sure I follow. It is just an example. It is not something mandatory for people to use. Each operator should/can/must create their own mapping rules.","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"a4bc61a3d6d0d964adb6c93535702be692a0f6b9","unresolved":true,"context_lines":[{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""},{"line_number":141,"context_line":"             }"},{"line_number":142,"context_line":"          ],"},{"line_number":143,"context_line":"          \"remote\":["}],"source_content_type":"text/x-rst","patch_set":14,"id":"ec2db8f8_90620d33","line":140,"updated":"2024-02-28 18:40:14.000000000","message":"can\u0027t we reuse existing project mapping so that it is always an object which is either defined explicitly or come from idp?","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"a332c5225d71a676b2107705acd48e240cb9ccda","unresolved":true,"context_lines":[{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""},{"line_number":141,"context_line":"             }"},{"line_number":142,"context_line":"          ],"},{"line_number":143,"context_line":"          \"remote\":["}],"source_content_type":"text/x-rst","patch_set":14,"id":"605023b0_734ed84c","line":140,"in_reply_to":"0afd273a_49532ada","updated":"2024-02-28 19:43:25.000000000","message":"\"if isinstance(val, str): val\u003djson.reads(val)\"\n\nthat\u0027s it. Adding new attribute without a real need is making mapping API unnecessary complex (the API client has more parameters to handle where a simple \"type: [str, object]\" does the trick. Otherwise you need to have jsonschema describing that you can have project OR projects_json what makes both client and server more complex. In addition it keeps mapping sane and clear.\n\nI am currently in the madness of jsonschemas of diverse openstack services/resources and what to prevent unnecessary complexity","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b7fcc467a0740f1c84f683518a7a2ea3be2e30","unresolved":false,"context_lines":[{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""},{"line_number":141,"context_line":"             }"},{"line_number":142,"context_line":"          ],"},{"line_number":143,"context_line":"          \"remote\":["}],"source_content_type":"text/x-rst","patch_set":14,"id":"6f208228_f30e2ac9","line":140,"in_reply_to":"605023b0_734ed84c","updated":"2024-04-09 19:25:32.000000000","message":"If we do that, it would not be possible to use both options together. In my current implementation, the hard coded project definition is enriched with the projects that come from the project_json variable. Therefore, I would prefer to maintain such compatibility.","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"d43b5a1e1fd35fb21f83f5fd3f3e143a4b9c186f","unresolved":true,"context_lines":[{"line_number":137,"context_line":"                \"domain\":{"},{"line_number":138,"context_line":"                   \"name\":\"{2}\""},{"line_number":139,"context_line":"                },"},{"line_number":140,"context_line":"                \"projects_json\":\"{3}\""},{"line_number":141,"context_line":"             }"},{"line_number":142,"context_line":"          ],"},{"line_number":143,"context_line":"          \"remote\":["}],"source_content_type":"text/x-rst","patch_set":14,"id":"0afd273a_49532ada","line":140,"in_reply_to":"ec2db8f8_90620d33","updated":"2024-02-28 19:06:40.000000000","message":"Not that easily, the variable comes as a string, which is a JSON encoded string. That is why it is separated in a new element. The ModOIDC used in Keystone makes/causes that behavior.","commit_id":"60ab8d5331b4d275664c810b72aad972a9dda576"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"3bc9259256200325e435596bfddf1682263bb413","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"21bc093f_2ada9c5d","line":103,"updated":"2024-04-12 15:52:38.000000000","message":"IMHO this is even worse. Idea of having project/role info coming from external identity manager is to centralize identity mgmt to avoid splitting data across systems (users in one system vs projects/roles in another system). With this statement you blow whole idea.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"da85507633d01741b86af5cf52b280835cadefe7","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"53fd4d31_3e983ea8","line":103,"in_reply_to":"21bc093f_2ada9c5d","updated":"2024-04-12 15:58:27.000000000","message":"No, we are not blowing anything. I am not sure what you do not understand; would you mind explaining in details?\n\nThe hard-coded projects receive the role definition from the IdP as well. The difference, is that, as explained in the spec, it is a rigid structure, and with the option to receive a JSON, we can have as many projects definitions as we want.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"061b9576a38c2a38be9286b674b4bdb947ee2fe9","unresolved":false,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"80dafb27_832fb1b6","line":103,"in_reply_to":"258deb06_6c1e1e96","updated":"2024-07-03 13:51:37.000000000","message":"Done","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"52a147610b3343d1ab7ad0f9be3bd17254c45f1c","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"8e8310d2_2b4416c8","line":103,"in_reply_to":"2d6f634e_4ef1f62a","updated":"2024-04-15 13:33:52.000000000","message":"I still do not see the issue you mention with having support for both together \"project_json\" and the current \"projects\" definition. The \"projects\" definition is hard coded in structure, but dynamic in content, and there is no issue with this use. If somebody wants to do something different, we can create another schema version for that.\n\nWhat is the issue you see with this proposal? It is not clear yet for me. Again, if it is about the \"domain\" attribute, that can be changed in another schema version, and we are not the ones that introduced it.\n\nCould you rephrase your explanation on why the support of \"projects\" and \"projects_json\" is not interesting to have in this situation here?\n\nThe use of both allow us to smoothly migrate from the current limitation in the mapping to the new one.\n\n```\n{\n  \"local\": [\n    {\n      \"user\": {\n        \"name\": \"{0}\",\n        \"email\": \"{1}\",\n        \"type\": \"ephemeral\",\n        \"domain\": {\n          \"name\": \"{2}\"\n        }\n      },\n      \"domain\": {\n        \"name\": \"{2}\"\n      },\n      \"projects\": [\n        {\n          \"name\": \"{3}\",\n          \"roles\": [\n            {\n              \"name\": \"member\"\n            },\n            {\n              \"name\": \"domadmin\"\n            },\n            {\n              \"name\": \"heat_stack_owner\"\n            },\n            {\n              \"name\": \"load-balancer_member\"\n            }\n          ]\n        }\n      ],\n      \"projects_json\": \"{4}\"\n    }\n  ],\n  \"remote\": [\n    {\n      \"type\": \"OIDC-preferred_username\"\n    },\n    {\n      \"type\": \"OIDC-email\"\n    },\n    {\n      \"type\": \"OIDC-openstack-user-domain\"\n    },\n    {\n      \"type\": \"OIDC-openstack-default-project\"\n    },\n    {\n      \"type\": \"OIDC-openstack-projects-client-mapper\"\n    }\n  ]\n}\n```\n\nMost organization working with the current version, with a hard coded project structure are probably doing something similar to the above mapping. Therefore, by allowing the combination of both, we enable an easier transition for them. The above is an example of mapping that we use in such situations. Of course, with time, all projects, including the default one will be only defined via \"openstack-projects-client-mapper\" attribute. However, is some situation that kind of enabler is quite helpful.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"6c626f2b100bb814f15f0a3f1e602e366bee14dd","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"2d6f634e_4ef1f62a","line":103,"in_reply_to":"53fd4d31_3e983ea8","updated":"2024-04-15 13:22:24.000000000","message":"there is nothing in that spec what I would not understand.\nI explained you very detailed few times my arguments and the issue I see.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"a723348c3e0dffad1e1c691966ddb042e2bcf528","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"258deb06_6c1e1e96","line":103,"in_reply_to":"5b24f383_7cd8acb9","updated":"2024-06-26 11:32:35.000000000","message":"Ok. I will change the spec and use a single field \"projects\". Then, in the proposal, the code must check if the content of field is an object or a json escaped string, and process it accordingly.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"eb6538ea232b028226c7a7f88def0633f7257962","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"dfe92991_859c9a04","line":103,"in_reply_to":"8e8310d2_2b4416c8","updated":"2024-04-17 15:18:35.000000000","message":"Sorry, I have no other words to rephrase (all relates to \"projects\" + \"projects_json\" ONLY):\n\n- not a single OpenStack API uses such pattern for fields supporting different type (i.e. XXX + XXX_str + XXX_json + XXX_bool). Introducing that violates API consistency\n- pattern of XXX + XXX_json is error prone on both server side and client side\n- pattern separates user authorization data between different systems what makes it harder to maintain and audit","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"f554dea300c90f4a94416c0a1d25fa56597b9b08","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"5b24f383_7cd8acb9","line":103,"in_reply_to":"aa9138f2_faba1eec","updated":"2024-04-19 15:46:07.000000000","message":"actually I don\u0027t think there should be any migration. There are deployments definitely willing to stick with defining projects/roles in keystone directly, there are ones willing to get this data from external Idp. Removing current style should not be targeted. But you are right that merging mapping results is extremely error prone and confusing.\n\nAll other OpenStack APIs are relying on polimorphism and support types like \"type: [object, string]\" and a different way (which is widely considered to be error prone and not used because of that anywhere else) would harm OpenStack APIs","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"},{"author":{"_account_id":14250,"name":"Grzegorz Grasza","email":"xek@redhat.com","username":"xek"},"change_message_id":"c3caf7672bd072a3694a4a41f3fcf000461a0457","unresolved":true,"context_lines":[{"line_number":100,"context_line":"data. **This is a mechanism to make the state of the OpenStack federated user"},{"line_number":101,"context_line":"consistent with the Identity provider user attributes.**"},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"If `projects_json` and `projects` are used together, the `projects_json` will"},{"line_number":104,"context_line":"be appended in the list of `projects`."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Attribute mapping schema"}],"source_content_type":"text/x-rst","patch_set":16,"id":"aa9138f2_faba1eec","line":103,"in_reply_to":"dfe92991_859c9a04","updated":"2024-04-19 15:34:11.000000000","message":"My thinking is, that when migrating to the new format, the procedure would look something like:\n1. introduce the new format, so you have both formats as input to keystone\n2. run an additional instance of keystone, with the new mapping\n3. test both old and new instances, comparing results\n4. if the new instance is working as expected, switch to it, updating the mapping configuration\n5. safely remove the old format, since it\u0027s no longer read by keystone\n\nFrom this perspective, having an enforced either/or choice would make things less ambiguous with just one transition path (like the one above). Having a mapping with both, and adding the resulting mapped projects seems more complicated and thus error prone. I don\u0027t see a use case for this additional in-between stage during the transition.","commit_id":"43559b813528604c247f67258e9f6daa81566bb8"}],"specs/keystone/wallaby/federated-identity-mapping-support-project-json-definition.rst":[{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"f29a512979df189b8de7af8a2472413dbe946437","unresolved":false,"context_lines":[{"line_number":26,"context_line":"This PR introduces a new property in the federated identity mapping schema"},{"line_number":27,"context_line":"called `projects_json`. In the schema, this property will accept a JSON"},{"line_number":28,"context_line":"string, that defines all of the projects and their specific roles that the"},{"line_number":29,"context_line":"user must receive when login-in to the OpenStack platform. Moreover, when"},{"line_number":30,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_dfe2a101","line":29,"range":{"start_line":29,"start_character":23,"end_line":29,"end_character":31},"updated":"2020-10-29 11:20:27.000000000","message":"logging in","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"3377584f6c78e08e4a90a44dcfb7e4fd4087eaf4","unresolved":false,"context_lines":[{"line_number":26,"context_line":"This PR introduces a new property in the federated identity mapping schema"},{"line_number":27,"context_line":"called `projects_json`. In the schema, this property will accept a JSON"},{"line_number":28,"context_line":"string, that defines all of the projects and their specific roles that the"},{"line_number":29,"context_line":"user must receive when login-in to the OpenStack platform. Moreover, when"},{"line_number":30,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_ba0ed3e2","line":29,"range":{"start_line":29,"start_character":23,"end_line":29,"end_character":31},"in_reply_to":"1f621f24_dfe2a101","updated":"2020-10-29 11:55:54.000000000","message":"Done","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"f29a512979df189b8de7af8a2472413dbe946437","unresolved":false,"context_lines":[{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":34,"context_line":"(1.2). This new version enables the handling of `project_json` in the"},{"line_number":35,"context_line":"attribute mapping."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_9fe14902","line":34,"range":{"start_line":34,"start_character":49,"end_line":34,"end_character":61},"updated":"2020-10-29 11:20:27.000000000","message":"projects_json","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"6f1e5c2319f0a4fe116db874d212fba83f7caedd","unresolved":false,"context_lines":[{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":34,"context_line":"(1.2). This new version enables the handling of `project_json` in the"},{"line_number":35,"context_line":"attribute mapping."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_1f56d92a","line":34,"range":{"start_line":34,"start_character":49,"end_line":34,"end_character":61},"in_reply_to":"1f621f24_9fe14902","updated":"2020-10-29 11:54:44.000000000","message":"Done","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"f29a512979df189b8de7af8a2472413dbe946437","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Attribute mapping schema"},{"line_number":43,"context_line":"------------------------"},{"line_number":44,"context_line":"Adding the `project_json` attribute:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":".. code-block:: python"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_5fd7b124","line":44,"range":{"start_line":44,"start_character":12,"end_line":44,"end_character":24},"updated":"2020-10-29 11:20:27.000000000","message":"projects_json","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"3377584f6c78e08e4a90a44dcfb7e4fd4087eaf4","unresolved":false,"context_lines":[{"line_number":41,"context_line":""},{"line_number":42,"context_line":"Attribute mapping schema"},{"line_number":43,"context_line":"------------------------"},{"line_number":44,"context_line":"Adding the `project_json` attribute:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":".. code-block:: python"},{"line_number":47,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_9a13170e","line":44,"range":{"start_line":44,"start_character":12,"end_line":44,"end_character":24},"in_reply_to":"1f621f24_5fd7b124","updated":"2020-10-29 11:55:54.000000000","message":"Done","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"f29a512979df189b8de7af8a2472413dbe946437","unresolved":false,"context_lines":[{"line_number":53,"context_line":""},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"By adding ``projects_json`` as a ``string``, we enable operators to use"},{"line_number":56,"context_line":"attributes in the IdP, that are a Json Strings which define the projects where"},{"line_number":57,"context_line":"the users must be placed in. Moreover, This JSON is then validated against the"},{"line_number":58,"context_line":"project definition. The new option will be handled in version ``1.2`` of the"},{"line_number":59,"context_line":"attribute mapping schema."},{"line_number":60,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_9fbae9db","line":57,"range":{"start_line":56,"start_character":34,"end_line":57,"end_character":27},"updated":"2020-10-29 11:20:27.000000000","message":"Can you provide an example in the spec of what this would look like?","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"6f1e5c2319f0a4fe116db874d212fba83f7caedd","unresolved":false,"context_lines":[{"line_number":53,"context_line":""},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"By adding ``projects_json`` as a ``string``, we enable operators to use"},{"line_number":56,"context_line":"attributes in the IdP, that are a Json Strings which define the projects where"},{"line_number":57,"context_line":"the users must be placed in. Moreover, This JSON is then validated against the"},{"line_number":58,"context_line":"project definition. The new option will be handled in version ``1.2`` of the"},{"line_number":59,"context_line":"attribute mapping schema."},{"line_number":60,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_9a2677b7","line":57,"range":{"start_line":56,"start_character":34,"end_line":57,"end_character":27},"in_reply_to":"1f621f24_9fbae9db","updated":"2020-10-29 11:54:44.000000000","message":"Done","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":16465,"name":"Kristi Nikolla","email":"knikolla@bu.edu","username":"knikolla"},"change_message_id":"f29a512979df189b8de7af8a2472413dbe946437","unresolved":false,"context_lines":[{"line_number":91,"context_line":"Dependencies"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"None"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"References"},{"line_number":97,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_5fa5f1b4","line":94,"range":{"start_line":94,"start_character":0,"end_line":94,"end_character":4},"updated":"2020-10-29 11:20:27.000000000","message":"This does actually depend on https://review.opendev.org/#/c/748042/ \n\nYou\u0027re also missing quite a few sections. We usually have a Security Impact section which I\u0027m interested to see in this case.","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"6f1e5c2319f0a4fe116db874d212fba83f7caedd","unresolved":false,"context_lines":[{"line_number":91,"context_line":"Dependencies"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"None"},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"References"},{"line_number":97,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1f621f24_ba59b3ff","line":94,"range":{"start_line":94,"start_character":0,"end_line":94,"end_character":4},"in_reply_to":"1f621f24_5fa5f1b4","updated":"2020-10-29 11:54:44.000000000","message":"Yes, it does depend on https://review.opendev.org/#/c/748042.\nFor two reasons: first,  we need the schema_versioning feature because I would introduce a new schema version with this patch; second, I need Keystone to honor domain definition in the attribute mapping to execute cross-domain assignments.\n\n\nThe other sections you mention, I did not introduce because I did not think that I needed them. Also, about security impacts, I did not see any that was not already there. If you have something in mind, let me know, and then I can incorporate it here.","commit_id":"9fc551bade41c55cf5785675d138858b292eeefd"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"8a24f1884ba33b7d864212a8a7d841b7c06e5e50","unresolved":true,"context_lines":[{"line_number":10,"context_line":"in Keystone identity federation attribute mapping schema"},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"This spec depends on https://review.opendev.org/#/c/748042/, which is the"},{"line_number":13,"context_line":"proposal that enhances the identity mapping schema management. Therefore,"},{"line_number":14,"context_line":"we first need to get that reviewed and merged."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fffc6b78_af5963ff","line":14,"range":{"start_line":13,"start_character":63,"end_line":14,"end_character":46},"updated":"2020-11-22 22:56:32.000000000","message":"This spec will live forever on specs.openstack.org, so ephemeral instructions like this don\u0027t need to be here. Just use Depends-on: in the commit message.","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"ff961699d09b1d83a9d0f6698f330a12a53c1eb4","unresolved":false,"context_lines":[{"line_number":10,"context_line":"in Keystone identity federation attribute mapping schema"},{"line_number":11,"context_line":""},{"line_number":12,"context_line":"This spec depends on https://review.opendev.org/#/c/748042/, which is the"},{"line_number":13,"context_line":"proposal that enhances the identity mapping schema management. Therefore,"},{"line_number":14,"context_line":"we first need to get that reviewed and merged."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Problem Description"},{"line_number":17,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"df18f48c_0ed244ee","line":14,"range":{"start_line":13,"start_character":63,"end_line":14,"end_character":46},"in_reply_to":"fffc6b78_af5963ff","updated":"2020-11-25 14:41:12.000000000","message":"Sure. Done.","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"8a24f1884ba33b7d864212a8a7d841b7c06e5e50","unresolved":true,"context_lines":[{"line_number":19,"context_line":"static. This happens because of the find/replace mechanism that we have in"},{"line_number":20,"context_line":"place there. Therefore, if the IdP provider generates an attribute that"},{"line_number":21,"context_line":"contains a JSON with project definitions, we are not able to handle it"},{"line_number":22,"context_line":"in Keystone."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Proposed Change"},{"line_number":25,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"85c86e5d_df242b29","line":22,"updated":"2020-11-22 22:56:32.000000000","message":"Can you explain more what you mean? Can you use example JSON mappings to show what you would expect or want to happen versus what currently happens?","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"3681d8b657a4c7bbf58a5d851b8f4348ca6a64d9","unresolved":false,"context_lines":[{"line_number":19,"context_line":"static. This happens because of the find/replace mechanism that we have in"},{"line_number":20,"context_line":"place there. Therefore, if the IdP provider generates an attribute that"},{"line_number":21,"context_line":"contains a JSON with project definitions, we are not able to handle it"},{"line_number":22,"context_line":"in Keystone."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Proposed Change"},{"line_number":25,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"8cf9138f_fcbc05d6","line":22,"in_reply_to":"4fa76178_bb29475c","updated":"2020-11-25 19:26:19.000000000","message":"Done","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"ff961699d09b1d83a9d0f6698f330a12a53c1eb4","unresolved":true,"context_lines":[{"line_number":19,"context_line":"static. This happens because of the find/replace mechanism that we have in"},{"line_number":20,"context_line":"place there. Therefore, if the IdP provider generates an attribute that"},{"line_number":21,"context_line":"contains a JSON with project definitions, we are not able to handle it"},{"line_number":22,"context_line":"in Keystone."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Proposed Change"},{"line_number":25,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b3101e3a_63f9a7ff","line":22,"in_reply_to":"85c86e5d_df242b29","updated":"2020-11-25 14:41:12.000000000","message":"Well, it is pretty much what is said there. I mean, if there is an attribute that comes from the IdP, and if this attribute contains a JSON definition with all of the projects where the user should be assigned to (with respective roles), the current implementation cannot handle that.\n\nWhat didn\u0027t you understand? Then, maybe, I can try to address it.","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"dc12da225e6b7b516bbe3c7337ff6e4076f156ca","unresolved":true,"context_lines":[{"line_number":19,"context_line":"static. This happens because of the find/replace mechanism that we have in"},{"line_number":20,"context_line":"place there. Therefore, if the IdP provider generates an attribute that"},{"line_number":21,"context_line":"contains a JSON with project definitions, we are not able to handle it"},{"line_number":22,"context_line":"in Keystone."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"Proposed Change"},{"line_number":25,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"4fa76178_bb29475c","line":22,"in_reply_to":"b3101e3a_63f9a7ff","updated":"2020-11-25 18:29:51.000000000","message":"I\u0027m asking for examples to be written down in the spec.","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"8a24f1884ba33b7d864212a8a7d841b7c06e5e50","unresolved":true,"context_lines":[{"line_number":28,"context_line":"string, that defines all of the projects and their specific roles that the"},{"line_number":29,"context_line":"user must receive when logging in to the OpenStack platform. Moreover, when"},{"line_number":30,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":34,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"56a97bf0_5c5cefcc","line":31,"updated":"2020-11-22 22:56:32.000000000","message":"How is this different from auto-provisioned projects and roles? https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html#auto-provisioning","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b8dfd51a1af9fdce8ff9edd448af9b7811f431","unresolved":false,"context_lines":[{"line_number":28,"context_line":"string, that defines all of the projects and their specific roles that the"},{"line_number":29,"context_line":"user must receive when logging in to the OpenStack platform. Moreover, when"},{"line_number":30,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":34,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3a20757d_94256a7b","line":31,"in_reply_to":"5394e44c_4a827e87","updated":"2024-01-26 17:51:21.000000000","message":"Done","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"ff961699d09b1d83a9d0f6698f330a12a53c1eb4","unresolved":true,"context_lines":[{"line_number":28,"context_line":"string, that defines all of the projects and their specific roles that the"},{"line_number":29,"context_line":"user must receive when logging in to the OpenStack platform. Moreover, when"},{"line_number":30,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":31,"context_line":"on the fly."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":34,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5394e44c_4a827e87","line":31,"in_reply_to":"56a97bf0_5c5cefcc","updated":"2020-11-25 14:41:12.000000000","message":"The auto provision that you mention is static. Even though it is a list, it is a list that is built with a find/replace mechanism with the attributes that come from the IdP, and that are retrieved via the \"remote\" section. That `projects` option there does not scale if we have users with a single project assignment at the same time that we have users with 5, 10, or more.\n\nIn the current implementation, once we define two projects, it will expect two, nothing less, nothing more. Did you understand what I mean?","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"8a24f1884ba33b7d864212a8a7d841b7c06e5e50","unresolved":true,"context_lines":[{"line_number":43,"context_line":"------------------------"},{"line_number":44,"context_line":"Adding the `projects_json` attribute:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":".. code-block:: python"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"    IDP_ATTRIBUTE_MAPPING_SCHEMA_1_2 \u003d copy.deepcopy("},{"line_number":49,"context_line":"    IDP_ATTRIBUTE_MAPPING_SCHEMA_1_1)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6f6df3b4_7899f5e8","line":46,"updated":"2020-11-22 22:56:32.000000000","message":"Please don\u0027t use python code snippets in a spec, specs aren\u0027t for implementation, they are for design and API changes. Explain the feature by explaining the changes to the JSON API that a user would see in https://docs.openstack.org/api-ref/identity/v3-ext/#mappings","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b8dfd51a1af9fdce8ff9edd448af9b7811f431","unresolved":false,"context_lines":[{"line_number":43,"context_line":"------------------------"},{"line_number":44,"context_line":"Adding the `projects_json` attribute:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":".. code-block:: python"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"    IDP_ATTRIBUTE_MAPPING_SCHEMA_1_2 \u003d copy.deepcopy("},{"line_number":49,"context_line":"    IDP_ATTRIBUTE_MAPPING_SCHEMA_1_1)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"41715646_e931fc0e","line":46,"in_reply_to":"50440089_7f600624","updated":"2024-01-26 17:51:21.000000000","message":"Done","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"ff961699d09b1d83a9d0f6698f330a12a53c1eb4","unresolved":true,"context_lines":[{"line_number":43,"context_line":"------------------------"},{"line_number":44,"context_line":"Adding the `projects_json` attribute:"},{"line_number":45,"context_line":""},{"line_number":46,"context_line":".. code-block:: python"},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"    IDP_ATTRIBUTE_MAPPING_SCHEMA_1_2 \u003d copy.deepcopy("},{"line_number":49,"context_line":"    IDP_ATTRIBUTE_MAPPING_SCHEMA_1_1)"}],"source_content_type":"text/x-rst","patch_set":4,"id":"50440089_7f600624","line":46,"in_reply_to":"6f6df3b4_7899f5e8","updated":"2020-11-25 14:41:12.000000000","message":"It is only to illustrate the new property that we are adding. I see no harm in adding this here.","commit_id":"d2a4e3baea48de02625a3e7e67db8d960962ffd6"},{"author":{"_account_id":28332,"name":"Alexandre arents","email":"alexandre.arents@corp.ovh.com","username":"aarents"},"change_message_id":"283838885c031cd286a1475d8c76d2a30b061476","unresolved":true,"context_lines":[{"line_number":81,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":82,"context_line":"on the fly."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":85,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"},{"line_number":86,"context_line":"attribute mapping."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"},{"line_number":89,"context_line":"and removal of roles that are present in OpenStack, but are not in the IdP"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7dc3551d_2eaa8763","line":86,"range":{"start_line":84,"start_character":41,"end_line":86,"end_character":18},"updated":"2022-06-24 13:06:07.000000000","message":"I think we don\u0027t need to introduce mapping schema version for this change, because it is just extending current schema without breaking existing deployment after upgrade.\n\nIn other words, this change must not necessary depends of this specs: https://review.opendev.org/c/openstack/keystone-specs/+/748042/\nIn this change ^^ Rafael introduces mapping schema versioning because \"honoring domain\" may involve a change of behavior in existing deployment. It is not the case here for adding projects_json assertion.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28595,"name":"Victor Coutellier","email":"victor.coutellier@gmail.com","username":"alistarle"},"change_message_id":"46bf645494b86b2e5cde852a7ce661847b1d0c15","unresolved":true,"context_lines":[{"line_number":81,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":82,"context_line":"on the fly."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":85,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"},{"line_number":86,"context_line":"attribute mapping."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"},{"line_number":89,"context_line":"and removal of roles that are present in OpenStack, but are not in the IdP"}],"source_content_type":"text/x-rst","patch_set":8,"id":"7e916adb_fa7d7261","line":86,"range":{"start_line":84,"start_character":41,"end_line":86,"end_character":18},"in_reply_to":"25c67d93_2cdd5019","updated":"2022-06-24 13:51:06.000000000","message":"I don\u0027t really get the point of willing to disable this option on the fly. Indeed, adding a new possible field in this API (mostly admin related btw) doesn\u0027t enforce it anywhere, and operators can still decide to not using it, despite a versioning of the schema. For me, if we want to add more limitation on this field, it should be done through the policy, not a version of the API.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b8dfd51a1af9fdce8ff9edd448af9b7811f431","unresolved":false,"context_lines":[{"line_number":81,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":82,"context_line":"on the fly."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":85,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"},{"line_number":86,"context_line":"attribute mapping."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"},{"line_number":89,"context_line":"and removal of roles that are present in OpenStack, but are not in the IdP"}],"source_content_type":"text/x-rst","patch_set":8,"id":"78d75c8f_00649e87","line":86,"range":{"start_line":84,"start_character":41,"end_line":86,"end_character":18},"in_reply_to":"276d8ea0_aa6055a2","updated":"2024-01-26 17:51:21.000000000","message":"Done","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"1295f37bd201c33aa2cef7b2f3cad3c28506f6de","unresolved":true,"context_lines":[{"line_number":81,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":82,"context_line":"on the fly."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":85,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"},{"line_number":86,"context_line":"attribute mapping."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"},{"line_number":89,"context_line":"and removal of roles that are present in OpenStack, but are not in the IdP"}],"source_content_type":"text/x-rst","patch_set":8,"id":"25c67d93_2cdd5019","line":86,"range":{"start_line":84,"start_character":41,"end_line":86,"end_character":18},"in_reply_to":"7dc3551d_2eaa8763","updated":"2022-06-24 13:20:26.000000000","message":"It can be a case of not wanting to handle projects_json field. For instance, if somebody wants to enable/disable this option on the fly. That is the whole idea behind the schema version, and why we first introduced the schema version before any other feature in Keystone.\n\nThere is no harm in that initial patch. It only facilitates the handling of new options being created in the attribute mapping schema. It should have been merged a very long time ago.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"3ca8f9e11d87b73d0835b6396ba3c9c0d5526aa9","unresolved":true,"context_lines":[{"line_number":81,"context_line":"using this extension, roles (assigned to projects) are added and removed"},{"line_number":82,"context_line":"on the fly."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The extension is quite straight forward. We created a new ``schema_version``"},{"line_number":85,"context_line":"(1.2). This new version enables the handling of `projects_json` in the"},{"line_number":86,"context_line":"attribute mapping."},{"line_number":87,"context_line":""},{"line_number":88,"context_line":"Furthermore, we added code to handle the addition of extra roles for projects"},{"line_number":89,"context_line":"and removal of roles that are present in OpenStack, but are not in the IdP"}],"source_content_type":"text/x-rst","patch_set":8,"id":"276d8ea0_aa6055a2","line":86,"range":{"start_line":84,"start_character":41,"end_line":86,"end_character":18},"in_reply_to":"7e916adb_fa7d7261","updated":"2022-06-24 14:01:07.000000000","message":"We are touching the authorization part of a complex system. If there is an issue with the implementation, we should be able to fallback somehow to the previous one. That is why this one was implemented on top of the schema versioning. I know that if one does not use it, in theory, they can set/remove the new attribute that is coming from the IdP. Or, updating the whole attribute mapping. However, that is one point, being able to activate/deactivate a function/option without changing the attribute mapping.\n\nAnyways, the whole history is now mixed. This patch was only created after the schema versioning was introduced (spec and implementation proposed here). Therefore, when we have that, we should always create a new schema version when adding new option in the attribute schema. That is why it was proposed as schema 1.2. The whole situation like this one only appeared because we were not able to move on that patch, even though it was approved and agreed in its content and form. It is not that we were not putting the effort, but it is that nobody was responding to our pings there.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28332,"name":"Alexandre arents","email":"alexandre.arents@corp.ovh.com","username":"aarents"},"change_message_id":"283838885c031cd286a1475d8c76d2a30b061476","unresolved":true,"context_lines":[{"line_number":95,"context_line":"By adding ``projects_json`` as a ``string``, we enable operators to use"},{"line_number":96,"context_line":"attributes in the IdP, that are a Json Strings which define the projects where"},{"line_number":97,"context_line":"the users must be placed in. Moreover, This JSON is then validated against the"},{"line_number":98,"context_line":"project definition. The new option will be handled in version ``1.2`` of the"},{"line_number":99,"context_line":"attribute mapping schema."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"An example on how the content of the ``projects_json`` variable looks like is"},{"line_number":102,"context_line":"presented as follows."}],"source_content_type":"text/x-rst","patch_set":8,"id":"e28185be_be300258","line":99,"range":{"start_line":98,"start_character":20,"end_line":99,"end_character":25},"updated":"2022-06-24 13:06:07.000000000","message":"same as before, I think we can remove it.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"04b8dfd51a1af9fdce8ff9edd448af9b7811f431","unresolved":false,"context_lines":[{"line_number":95,"context_line":"By adding ``projects_json`` as a ``string``, we enable operators to use"},{"line_number":96,"context_line":"attributes in the IdP, that are a Json Strings which define the projects where"},{"line_number":97,"context_line":"the users must be placed in. Moreover, This JSON is then validated against the"},{"line_number":98,"context_line":"project definition. The new option will be handled in version ``1.2`` of the"},{"line_number":99,"context_line":"attribute mapping schema."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"An example on how the content of the ``projects_json`` variable looks like is"},{"line_number":102,"context_line":"presented as follows."}],"source_content_type":"text/x-rst","patch_set":8,"id":"da17d075_5e07bb01","line":99,"range":{"start_line":98,"start_character":20,"end_line":99,"end_character":25},"in_reply_to":"01cde275_513de741","updated":"2024-01-26 17:51:21.000000000","message":"Done","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"},{"author":{"_account_id":28356,"name":"Rafael Weingartner","email":"rafael@apache.org","username":"rafaelweingartner"},"change_message_id":"1295f37bd201c33aa2cef7b2f3cad3c28506f6de","unresolved":true,"context_lines":[{"line_number":95,"context_line":"By adding ``projects_json`` as a ``string``, we enable operators to use"},{"line_number":96,"context_line":"attributes in the IdP, that are a Json Strings which define the projects where"},{"line_number":97,"context_line":"the users must be placed in. Moreover, This JSON is then validated against the"},{"line_number":98,"context_line":"project definition. The new option will be handled in version ``1.2`` of the"},{"line_number":99,"context_line":"attribute mapping schema."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"An example on how the content of the ``projects_json`` variable looks like is"},{"line_number":102,"context_line":"presented as follows."}],"source_content_type":"text/x-rst","patch_set":8,"id":"01cde275_513de741","line":99,"range":{"start_line":98,"start_character":20,"end_line":99,"end_character":25},"in_reply_to":"e28185be_be300258","updated":"2022-06-24 13:20:26.000000000","message":"same as before.","commit_id":"347a6543e44ea35201c80e206fea1819d741d73a"}]}