[keystone]improvments in mapping models/support for JWT tokens
pregusia
rafal at pregusia.pl
Thu Apr 1 19:05:32 UTC 2021
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_combinations.html),
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-victoria.patch
Type: text/x-patch
Size: 13182 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210401/65c9948e/attachment-0001.bin>
More information about the openstack-discuss
mailing list