type: local must be set in order to get domain parsed when mapping federated users

Bug #1673157 reported by Aurelien Joga
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Low
Colleen Murphy

Bug Description

Both the identity specs[1] and the federation guide[2] are stating : "Federated will be displayed if no domain is specified in the local rule. User is deemed ephemeral and becomes a member of service domain named Federated. If the domain is specified the local domain’s id will be displayed."

I understand this as specifying a domain is enough for the user type to be set as "local" by the mapping engine. However, with the current implementation, setting a domain is useless unless "type" is set to "local".

I believe the responsible code is here : https://github.com/openstack/keystone/blob/169e66ab8800148c4052a46d2cb321af33e44f77/keystone/federation/utils.py#L582-L597

Is this an implementation issue or a documentation issue ?

TO REPRODUCE
============
$ cat input.txt
HTTP_OIDC_ISS: https://dummy/

$ # see the attached rules.json file

$ keystone-manage mapping_engine --rules /tmp/rules.json --input ajoga/test-input.txt
{
  "group_ids": [],
  "user": {
    "domain": {
      "id": "targetdomain"
    },
    "type": "local",
    "id": "test",
    "name": "test"
  },
  "projects": [],
  "group_names": []
}
$ # remove the line '"type": "local"' from rules.json
$ keystone-manage mapping_engine --rules /tmp/rules.json --input ajoga/test-input.txt
{
  "group_ids": [],
  "user": {
    "domain": {
      "id": "Federated"
    },
    "type": "ephemeral",
    "id": "test",
    "name": "test"
  },
  "projects": [],
  "group_names": []
}

[1] https://developer.openstack.org/api-ref/identity/v3-ext/index.html#os-federation-api
[2] https://docs.openstack.org/developer/keystone/federation/federated_identity.html

Revision history for this message
Aurelien Joga (aurelienjoga) wrote :
summary: - type: local must be set in order to get domain parse when mapping
+ type: local must be set in order to get domain parsed when mapping
federated users
Revision history for this message
David Stanek (dstanek) wrote :

I believe that you are correct in that the code requires a type:local in order to map back to a local user. In the federation doc [1] we say "``local`` is displayed if the user has a domain specified." which in wrong according to how I read the code. It really should read "``local`` must be specified in order to provide a domain and map to a local user."

The other option is to change the code to infer type. I'd rather not do this for two reasons:
explicit is better than implicit and this could in theory break existing mappings where they are specified, but ignored.

Revision history for this message
David Stanek (dstanek) wrote :
Changed in keystone:
status: New → Confirmed
Changed in keystone:
importance: Undecided → Low
milestone: none → pike-rc1
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/491478

Changed in keystone:
assignee: nobody → Colleen Murphy (krinkle)
status: Confirmed → In Progress
tags: added: federation
tags: added: documentation office-hours
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

Reviewed: https://review.openstack.org/491478
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=d10908caa9909b9f178a59551f004a80a722cf2e
Submitter: Jenkins
Branch: master

commit d10908caa9909b9f178a59551f004a80a722cf2e
Author: Colleen Murphy <email address hidden>
Date: Mon Aug 7 14:17:20 2017 +0200

    Document required `type` mapping attribute

    In order for a federated user to be mapped to a local user that exists
    in the identity backend, the user object in the local mapping rule must
    have the property "type": "local" set, in addition to having a keystone
    domain provided. This was probably not the original intention of the
    local user mapping spec[1], but this is how it ended up being
    implemented. We could choose to change the behavior of the code, but
    it has been around long enough that it is possible that deployments are
    depending on this behavior, and moreover making rules explicit rather
    than implicit reduces the risk of bugs and mistakes.

    This patch updates the api-ref documentation and the standard federation
    documentation to include the "type" property when mapping to local
    users. In addition, since we now have two keywords called "local" that
    mean somewhat different things, we expand the context of some of the
    mapping examples so that both the rule name "local" and the value
    "local" of the attribute "type" appear in the example, for clarity.

    Change-Id: Ib35e57e33903de14f9cac1f919c32dfe923ef884
    Closes-bug: #1673157

Changed in keystone:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone 12.0.0.0rc1

This issue was fixed in the openstack/keystone 12.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.