OpenStack Identity (keystone)

keystone federation mapping rules with blacklist

Bug #1693690 reported by yangweiwei
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Low
Lance Bragstad
OpenStack Identity (keystone) pike-rc1 "pike-rc1"

Bug Description

When I create a rule like:
[
{
    "local": [
        {
            "user": {
                "name": "user_test",
                 "id": "faced82c29e24b10b14ea64366b4653d"
            },
            "group": {
                "name":"group1",
                "domain": {
                     "name":"domain1"
                           }
            }
        }
    ],
    "remote":[
              {
              "type":"openstack_user",
              "blacklist": [
                        "bob"
                    ]
              }
]
        }
]

And 'bob' logins to the SP, the result is OK. But actually, bob is in the blacklist, he should has no right to login to SP. ('bob' is a user of idp.)

Tags: office-hours
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/468278

Changed in keystone:
assignee: nobody → yangweiwei (496176919-6)
status: New → In Progress
Revision history for this message
Lance Bragstad (lbragstad) wrote : Re: keystone fedeartion mapping rules with blacklist

Can you confirm that the assertion has openstack_user? We have test cases that exercise blacklists [0], but I'm wondering what is different between the test and what you're doing.

[0] https://github.com/openstack/keystone/blob/e415fdcaadc806b0b12804e95601e29510fa60d8/keystone/tests/unit/contrib/federation/test_utils.py#L357-L383

Revision history for this message
Colleen Murphy (krinkle) wrote :

Copying my comment on the review to here:

I've verified this, and after digging into it I believe it's actually intended behavior. You can see from the test_rule_engine_no_groups_allowed test that broke in this patch what its intention is, and it's explained in the spec that added the behavior: http://specs.openstack.org/openstack/keystone-specs/specs/keystone/kilo/mapping-enhancements.html

The usecases behind whitelist and blacklist are to map remote groups to local groups, so if no remote groups match, it is supposed to map to an empty list of local groups. The logic breaks down when you try to apply it to usernames, since it returns an empty list of usernames but doesn't cause a validation error.

If you understand it from this angle, the description in the documentation makes a little more sense: "The rule allows all except a specified set of groups. Condition result is the argument(s) passed as input minus what was matched in the blacklist." -- we should probably enhance this because it is very unclear.

So I believe this is a documentation bug, not a functional bug. To get the behavior your are expecting, you can use not_any_of instead of blacklist.

Revision history for this message
Lance Bragstad (lbragstad) wrote :

Add this to office-hours since a documentation patch should be pretty easy to land in a single session.

tags: added: office-hours
Lance Bragstad (lbragstad)
Changed in keystone:
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/487583

Changed in keystone:
assignee: yangweiwei (496176919-6) → Lance Bragstad (lbragstad)
Lance Bragstad (lbragstad)
summary: - keystone fedeartion mapping rules with blacklist
+ keystone federation mapping rules with blacklist
Changed in keystone:
importance: Undecided → Low
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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

commit 0331a11842740ab3566a16ca3531bdeeed26ab37
Author: Lance Bragstad <email address hidden>
Date: Wed Jul 26 20:48:19 2017 +0000

    Clarify documentation on whitelists and blacklists

    Some references to whitelisting and blacklisting was confusing in the
    mapping documentation. This commit attempts to clarify the wording
    and purpose for both whitelists and blacklists.

    Change-Id: I09f4762f03824acc689600c8561fe99ea113ad9a
    Closes-Bug: 1693690

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on keystone (master)

Change abandoned by yangweiwei (<email address hidden>) on branch: master
Review: https://review.openstack.org/464933

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Change abandoned by yangweiwei (<email address hidden>) on branch: master
Review: https://review.openstack.org/468278

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

Other bug subscribers

Remote bug watches

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