yahoo-eng-team team mailing list archive

[Pavlo Shchelokovskyy <1978833@xxxxxxxxxxxxxxxxxx>]

Closing this as invalid - setting authorization_ttl for the IdP in
Keystone (or default_authorization_ttl in config) allows the appcreds to
be created and work for this amount of time after the federated user has
logged in.

May be not ideal for some applications, but clearly security
considerations win here (user changed properties in 'upstream' IdP that
would remove the roles passed to it thru mapping, or deleted from
'upstream' IdP altogether).

** Changed in: keystone
       Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1978833

Title:
  can not create application credential for federated user when mapping
  uses group

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  Tested on devstack/master + SAML2 and victoria + OpenIDConnect.

  Setup on devstack + SAML:
  - install devstack as per keystone-dsvm-py3-functional-federation-ubuntu-focal job
  - run the test keystone_tempest_plugin.tests.scenario.test_federated_authentication.TestSaml2FederatedExternalAuthentication.test_request_scoped_token to ensure it works as expected
  - get the scoped token for the federated user
    - (fwiw I failed to use openstackclient with v3samlpassword, so I resorted to some cheating)
    - commented out the cleanups in that test, and logged the scoped token, used it then with the openstackclient

  try to create application credentials with that token:

  openstack --debug application credential create test

  fails with not finding roles:

  Invalid application credential: Could not find role assignment with
  role: 71a233e8d3f54a08a94ef260a39ce870, user or group:
  055a4f727a3358c9037831569fc46aab98e6e2d4be5a6597ec7cc19fd5afbc91,
  project, domain, or system: df0d47600acd46428321899a65e47157. (HTTP
  400) (Request-ID: req-429314bf-3060-4e94-ab78-69a10bdbd660)

  even while roles are there per debug output of access info:

  {"token": {"methods": ["token", "mapped"], "user": {"domain": {"id":
  "c4235afadccd49ec8e2ea0bb013f930c", "name":
  "c4235afadccd49ec8e2ea0bb013f930c"}, "id":
  "055a4f727a3358c9037831569fc46aab98e6e2d4be5a6597ec7cc19fd5afbc91",
  "name": "morty", "OS-FEDERATION": {"groups": [{"id":
  "1660ce0da8694cc99d9ad0ccba6102e6"}], "identity_provider": {"id":
  "samltest"}, "protocol": {"id": "mapped"}}}, "audit_ids":
  ["8yA8ngZRRZaYj99VfsLDkg"], "expires_at":
  "2022-06-15T14:48:14.000000Z", "issued_at":
  "2022-06-15T13:48:14.000000Z", "project": {"domain": {"id":
  "8f611bd7fca24b43b837e46205115279", "name": "federated_domain"}, "id":
  "df0d47600acd46428321899a65e47157", "name": "federated_project"},
  "is_domain": false, "roles": [{"id":
  "71a233e8d3f54a08a94ef260a39ce870", "name": "member", "domain_id":
  null, "description": null, "options": {"immutable": true}}, {"id":
  "fd6a812d75d340d2b46c04681ca69774", "name": "reader", "domain_id":
  null, "description": null, "options": {"immutable": true}}],
  "catalog": [{"endpoints": [{"id": "1c0b1188496e4b4a991ef655dade6919",
  "interface": "public", "region_id": "RegionOne", "url":
  "http://192.168.100.58/identity";, "region": "RegionOne"}], "id":
  "d859f6754830449c997fd10cc21ace7c", "type": "identity", "name":
  "keystone"}]}}

  In the keystone there's the following trace:
  https://paste.openstack.org/show/814941/

  Note that when using a mapping with concrete role assignments (via
  auto-provision of projects and explicitly assigning roles to them)
  everything works and app creds can be created as expected.

  Also a piece of a puzzle is that `openstack group contains user` does
  not show this user
  "055a4f727a3358c9037831569fc46aab98e6e2d4be5a6597ec7cc19fd5afbc91"
  belonging to the group "1660ce0da8694cc99d9ad0ccba6102e6", and
  `openstack role assignment list --user ... --effective` does not show
  any assignments too (while it does for a usual, non-federated user
  that only gets its roles thru a group membership).

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1978833/+subscriptions