[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