[keystone]improvments in mapping models/support for JWT tokens
Hello members! Please direct your attention to some keystone modyfications - to be more precisly two of them: (1) extension to mapping engine in order to support multiple projects and assigning project by id (2) extension to authorization mechanisms - add JWT token support Ad (1): Currently mapping engine can map multiple projects for user (as stated in https://docs.openstack.org/keystone/pike/advanced-topics/federation/mapping_...), but this support lacks from (a) dynamic mapping projects from assertion (for ex. projects ids are in assertion) and (b) mapping engine cannot map to list from assertion (if in asertion we have "some_field": [ id1, id2, ..., idN ] - then using this field by substitution - eg "{1}" wont map this to whole needed structure of projects in mapping). In patch I extend mapping schema by adding new field "projects_spec" of type string. This field contains string formated like project1ID:role1:role2:..:roleN,project2ID:role1:...:roleN,... and this is mapped into proper structure { "projects": [ { "id": .., "roles": [ ... ] }, ... ] } this allows the identity provider to supply permission-like informations about what projects user should have access to. The implementation is not ideal, and some work shoud be do to make it more user-friendly (for ex. configuration options for auto-creating projects by ID, and options for allowing user to log-in if project-by-id not exists etc) This is only proof of concept and question if this direction is proper according to keystone development. Ad (2) This patch adds new authorization protocol - jwt_token. It allows to access endpoint '/v3/OS-FEDERATION/identity_providers/{IDP_NAME}/protocols/jwt_token/auth' (and obtain keystone auth token) using JWT token in Authorization header field. Header value is checked against proper formating and JWT token is extracted from it. Then, token is validated against public key (RS256/RS512 algorithms only supported), against issuer and expiration date and others. Then, if this end with success, payload from token is supplied to mapping engine, when new user (and according to (1), it's permission to projects for ex.) is created and given access to proper projects/roles. Happy reviewing! pregusia
On 2021-04-01 21:05:32 +0200 (+0200), pregusia wrote:
Please direct your attention to some keystone modyfications - to be more precisly two of them: (1) extension to mapping engine in order to support multiple projects and assigning project by id (2) extension to authorization mechanisms - add JWT token support [...]
This is pretty exciting stuff. But please be aware that for an OpenStack project to merge patches they'll need to be proposed into the code review system (Gerrit) by someone, preferably by the author of the patches, which is the easiest place to discuss them as well. Also we need some way to confirm that the author of the patches has agreed to the Individual Contributor License Agreement (essentially asserting that the patches they propose are their own work or that they have permission from the author or are proposing patches consisting of existing code distributed under a license compatible with the Apache License version 2.0), and the usual way to agree to the ICLA is when creating your account in Gerrit. Please see the OpenStack Contributor Guide for a general introduction to our code proposal and review workflow: https://docs.openstack.org/contributors/ And feel free to ask questions on this mailing list if you have any. -- Jeremy Stanley
Thanks for the answer. I submitted patches to review: https://review.opendev.org/c/openstack/keystone/+/784553 https://review.opendev.org/c/openstack/keystone/+/784558 but it looks like some problem with python version https://zuul.opendev.org/t/openstack/build/45a04fb21bf14806a3a32b83c18b8120 Can You advice what is wrong here ? On 4/1/21 9:22 PM, Jeremy Stanley wrote:
On 2021-04-01 21:05:32 +0200 (+0200), pregusia wrote:
Please direct your attention to some keystone modyfications - to be more precisly two of them: (1) extension to mapping engine in order to support multiple projects and assigning project by id (2) extension to authorization mechanisms - add JWT token support [...]
This is pretty exciting stuff. But please be aware that for an OpenStack project to merge patches they'll need to be proposed into the code review system (Gerrit) by someone, preferably by the author of the patches, which is the easiest place to discuss them as well. Also we need some way to confirm that the author of the patches has agreed to the Individual Contributor License Agreement (essentially asserting that the patches they propose are their own work or that they have permission from the author or are proposing patches consisting of existing code distributed under a license compatible with the Apache License version 2.0), and the usual way to agree to the ICLA is when creating your account in Gerrit.
Please see the OpenStack Contributor Guide for a general introduction to our code proposal and review workflow:
https://docs.openstack.org/contributors/
And feel free to ask questions on this mailing list if you have any.
participants (2)
-
Jeremy Stanley
-
pregusia