[OSSA-2018-002] GET /v3/OS-FEDERATION/projects leaks project information (CVE-2018-14432)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | OpenStack Identity (keystone) |
Critical
|
Lance Bragstad | ||
| | Ocata |
Critical
|
Lance Bragstad | ||
| | Pike |
Critical
|
Lance Bragstad | ||
| | Queens |
Critical
|
Lance Bragstad | ||
| | Rocky |
Critical
|
Lance Bragstad | ||
| | OpenStack Security Advisory |
Undecided
|
Matthew Thode | ||
Bug Description
The /v3/OS-
Eventually the /v3/OS-
The /v3/OS-
lbragstad|
clouds:
devstack:
auth:
auth_url: http://
password: nomoresecret
project_
project_name: demo
user_
username: demo
identity_
region_name: RegionOne
volume_
devstack-admin:
auth:
auth_url: http://
password: nomoresecret
project_
project_name: admin
user_
username: admin
identity_
region_name: RegionOne
volume_
devstack-alt:
auth:
auth_url: http://
password: nomoresecret
project_
project_name: alt_demo
user_
username: alt_demo
identity_
region_name: RegionOne
volume_
lbragstad|
+------
| Role | User | Group | Project | Domain | Inherited |
+------
| member | | nonadmins@Default | demo@Default | | False |
| anotherrole | | nonadmins@Default | demo@Default | | False |
| member | | nonadmins@Default | alt_demo@Default | | False |
| anotherrole | | nonadmins@Default | alt_demo@Default | | False |
| admin | | admins@Default | admin@Default | | False |
| admin | admin@Default | | demo@Default | | False |
| admin | admin@Default | | admin@Default | | False |
| admin | admin@Default | | alt_demo@Default | | False |
| admin | admin@Default | | | Default | False |
| member | demo@Default | | demo@Default | | False |
| anotherrole | demo@Default | | demo@Default | | False |
| member | demo@Default | | invisible_
| member | alt_demo@Default | | alt_demo@Default | | False |
| anotherrole | alt_demo@Default | | alt_demo@Default | | False |
| admin | admin@Default | | | | False |
+------
lbragstad|
+------
| Field | Value |
+------
| expires | 2018-06-
| id | gAAAAABbNT8jpqw
| project_id | 44053df0d12f4ba
| user_id | cef2773684114d5
+------
lbragstad|
uuESisyzj36w'
lbragstad|
% Total % Received % Xferd Average Speed Time Time Time Current
100 669 100 669 0 0 20476 0 --:--:-- --:--:-- --:--:-- 20906
{
"links": {
"next": null,
"previous": null,
"self": "http://
},
"projects": [
{
"id": "44053df0d12f4b
},
"name": "demo",
"tags": []
},
{
"id": "8c92de6ab3884f
},
"name": "invisible_
"tags": []
}
]
}
lbragstad|
% Total % Received % Xferd Average Speed Time Time Time Current
100 1270 100 1270 0 0 17528 0 --:--:-- --:--:-- --:--:-- 17638
{
"links": {
"next": null,
"previous": null,
"self": "http://
},
"projects": [
{
"id": "44053df0d12f4b
},
"name": "demo",
"tags": []
},
{
"id": "681b94352ed146
},
"name": "admin",
"tags": []
},
{
"id": "9a742b4684dc4c
},
"name": "alt_demo",
"tags": []
},
{
"id": "8c92de6ab3884f
},
"name": "invisible_
"tags": []
}
]
}
Notice that I used the devstack cloud config, which specifies the demo user who only has the `member` and `anotherrole` assigned on two projects (demo and invisible_
CVE References
| Lance Bragstad (lbragstad) wrote : | #1 |
| description: | updated |
| Changed in keystone: | |
| status: | New → Triaged |
| importance: | Undecided → Critical |
| Kristi Nikolla (knikolla) wrote : | #2 |
Just tested this on our public cloud running Pike.
Using a federated token on /v3/OS-
Using a local token on /v3/OS-
| Morgan Fainberg (mdrnstm) wrote : | #3 |
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.
| description: | updated |
| Changed in ossa: | |
| status: | New → Incomplete |
| Morgan Fainberg (mdrnstm) wrote : | #4 |
<Keystone Developer Hat>This looks like a pretty severe data leak. While usually project info is not really "privileged data", this leaks the entire project structure and all associated attributes. I would develop a fix and propose backports.
<VMT Member Hat>I would likely classify this as a Class A [0] bug due to the severity of data leaking. This should be backportable to all active branches. While this is not directly exploitable (there is no escalation/
Alternatively, this could be a Class D bug since no escalation/
I'll look for further weighing in from the Keystone-Coresec team.
Finally, if the fixes cannot be generated shortly/quickly the fact that this was accidentally released on a public paste site; it would make sense to make public so that cloud operators could modify their policy.json (or load-balancers/
[0] https:/
| Gage Hugo (gagehugo) wrote : | #5 |
Agreed on Class A bug, should definitely fix/backport to all current active branches.
According to the docs, OS-FEDERATION/
| Changed in ossa: | |
| status: | Incomplete → Confirmed |
I confirmed the OSSA task based on above comments.
When was the v1.1 released?
If users are relying on that endpoints, they might already be relying on the full list... Could this OS-FEDERATION/
| Lance Bragstad (lbragstad) wrote : | #7 |
I agree in Morgan's assessment in comment #4, this is a pretty severe data leak.
I'm not sure what the rules are on using redirects, but I wouldn't be opposed to using that as a fix. Especially since it reduces duplication in API that should behave the same.
| Lance Bragstad (lbragstad) wrote : | #8 |
There is another API that is very similar for getting domains (GET /v3/OS-
| Morgan Fainberg (mdrnstm) wrote : | #9 |
I like the idea of a HTTP 301 for this. It may not be handled well by all clients, but it ensures the code is the same and that folks are using the new path.
We could also just wire up the behind the scenes code to be the same code path, which should also solve the problem.
Being as severe a data leak with an alternative path, I would also support making it a 410 (GONE) with a message saying why it was removed.
| Changed in keystone: | |
| milestone: | none → rocky-3 |
| Morgan Fainberg (mdrnstm) wrote : | #10 |
(or simply 404ing it)
| Morgan Fainberg (mdrnstm) wrote : | #11 |
The 410/404 method might be the recommended "emergency" path forward if we make this public. It should be trivial to wire this up behind the scenes (at a cursory glance of the code) to de-dupe divergent (and now insecure) code paths.
| Lance Bragstad (lbragstad) wrote : | #12 |
I was able to recreate this with a test and hacked together a fix that replaces the duplicated logic with a call to the same code that executes GET /v3/auth/projects (the correct API).
I'd like to get opinions from a few others in this thread on the test coverage and solution.
| Lance Bragstad (lbragstad) wrote : | #13 |
FWIW - I wasn't able to recreate this with domains.
| Kristi Nikolla (knikolla) wrote : | #14 |
OS-FEDERATION/
knikolla@smile:~$ curl -H "x-auth-token: <REDACTED_TOKEN>" -H "x-subject-token: <REDACTED_TOKEN>" https:/
% Total % Received % Xferd Average Speed Time Time Time Current
100 394 100 394 0 0 2359 0 --:--:-- --:--:-- --:--:-- 2359
{
"token": {
],
"methods": [
],
"user": {
},
}
},
},
"id": "<REDACTED_ID>",
"name": "<REDACTED_EMAIL>"
}
}
}
knikolla@smile:~$ curl -H "x-auth-token: <REDACTED_TOKEN>" https:/
% Total % Received % Xferd Average Speed Time Time Time Current
100 375 100 375 0 0 1194 0 --:--:-- --:--:-- --:--:-- 1194
{
"domains": [
{
"id": "<REDACTED_ID>",
},
"name": "heat"
}
],
"links": {
"next": null,
"previous": null,
"self": "https:/
}
}
knikolla@smile:~$ curl -H "x-auth-token: <REDACTED_TOKEN>" https:/
% Total % Received % Xferd Average Speed Time Time Time Current
100 124 100 124 0 0 1215 0 --:--:-- --:--:-- --:--:-- 1215
{
"domains": [],
"links": {
"next": null,
"previous": null,
"self": "https:/
}
}
| Lance Bragstad (lbragstad) wrote : | #15 |
Strange... we should expand the patch in comment #12 to include the domain path using the same approach (including a test, too).
| Morgan Fainberg (mdrnstm) wrote : | #16 |
"A Random Domain" is concerning. Lets update (as Lance said) patch in #12 to cover domain cases as well.
| Kristi Nikolla (knikolla) wrote : | #17 |
Updated Lances patch to cover domains in a similar way.
| Lance Bragstad (lbragstad) wrote : | #18 |
The patch in comment #17 looks good. Just double checking, but it doesn't look like we have a test for the random domain bit that Kristi mentioned in comment #14.
Also, in the event we disclose this issue, do we formally agree on the work around? Which is to deactivate the affected APIs via policy.
| Matthew Thode (prometheanfire) wrote : | #19 |
Hi, the VMT are taking on padawans, myself being one of them. Please review this VMT description for accuracy and clarity.
NOTE: https:/
Title: GET /v3/OS-
Reporter: Kristi Nikolla
Products: Keystone
Affects: >=2011.3 <=2015.1.4, >=13.0.0 <13.0.1, >=12.0.0 <12.0.1, <11.0.4
Description:
Kristi Nikolla reported a vulnerability in Keystone federation.
By doing GET /v3/OS-
access control data resulting in a leaks a projects full structure
along with all associated attributes.
Only Keystone with federation enabled is affected.
| Changed in ossa: | |
| status: | Confirmed → Triaged |
| Lance Bragstad (lbragstad) wrote : | #20 |
The API for accessing domains isn't actually affected. Based on what Kristi and I have been able to recreate, only GET /v3/OS-
Kristi did have a case where he was seeing a "domain mismatch" that we should try and include as a testcase in the patch.
| Kristi Nikolla (knikolla) wrote : | #21 |
Also this does affect Keystone where federation is not enabled also.
| Lance Bragstad (lbragstad) wrote : | #22 |
The mismatching domain piece actually won't need a test case because the code that exposed the issue is being removed in the patch.
| Matthew Thode (prometheanfire) wrote : | #23 |
Please review this VMT description for accuracy and clarity. I need the following two points validated specifically.
1. When was this introduced? I'm currently including all keystone releases, but I don't think federation was in 2011.3
2. Is this bug only able to be hit when federation is enabled?
NOTE: https:/
Title: GET /v3/OS-
Reporter: Kristi Nikolla
Products: Keystone
Affects: >=2011.3 <=2015.1.4, >=13.0.0 <13.0.1, >=12.0.0 <12.0.1, <11.0.4
Description:
Kristi Nikolla reported a vulnerability in Keystone federation.
By doing GET /v3/OS-
access control data resulting in a leaks a projects full structure
along with all associated attributes.
Only Keystone with federation enabled is affected.
| Lance Bragstad (lbragstad) wrote : | #24 |
Answers are as follows:
1.) I believe this affects all supported releases. Kristi discovered and confirmed the bug on a deployment running Pike. It looks like this was the original commit that introduced the functionality [0], which doesn't necessarily mean that all those releases are affected. I'm working on standing up an ocata environment to see if that specific release is affected (I assume it is since Pike is affected and not much changed between those two releases).
2.) Correct, the /v3/OS-FEDERATION/ path must be enabled and accessible to users. Although a user doesn't need a federated token in order to expose the vulnerability. A user only needs an unscoped token proving their membership within the deployment. The noted workaround would be to disable those APIs via policy configuration and force users to use the /v3/auth/projects path, which isn't affected.
I have a minor nit on the grammatical wording in the Description above:
"By doing GET /v3/OS-
projects they have no authority to access, leaking all projects
in the deployment and their attributes."
| Gage Hugo (gagehugo) wrote : | #25 |
1. Looking at the history, this is a bit vague. The federation controller was moved sometime in Newton. Will need to dig into this more, but it's definitely all current supported versions afaik.
2. No, (see Kristi's comment above #21)
| Gage Hugo (gagehugo) wrote : | #26 |
Addon 2. Lance's comment "the /v3/OS-FEDERATION/ path must be enabled and accessible to users" is a good thing to include in the description.
| Matthew Thode (prometheanfire) wrote : | #27 |
Please review this VMT description for accuracy and clarity.
NOTE: https:/
Title: GET /v3/OS-
Reporter: Kristi Nikolla
Products: Keystone
Affects: >=2014.1 <=2015.1.4, >=13.0.0 <13.0.1, >=12.0.0 <12.0.1, <11.0.4
Description:
Kristi Nikolla reported a vulnerability in Keystone federation.
By doing GET /v3/OS-
projects they have no authority to access, leaking all projects
in the deployment and their attributes.
Only Keystone with the OS-FEDERATION endpoint enabled is affected.
| Morgan Fainberg (mdrnstm) wrote : | #28 |
As a note, OS-FEDERATION endpoint cannot be disabled short of changes to policy.json even as far back as Ocata. It is not practical to highlight "only keystone with the OS-FEDERATION endpoint enabled is affected".
We should add Kristi's organization (if he wants it) to the report.
With exception of the NOTEs I've provided this is def. headed the right direction for an impact statement.
| Morgan Fainberg (mdrnstm) wrote : | #29 |
Note: My above assertion is incorrect. as this requires a federated token. OS-FEDERATION as a URL is not something that can be disabled. However, if the user is unable to get a federated token (no federation endpoint, aka shibboleth via apache) is setup, the OS-FEDERATION code raises a 500 error (as described by kristi).
We should be more specific in that this only impacts federated auth tokens to avoid confusion (like I just had) regarding what is meant by OS-FEDERATION
| Matthew Thode (prometheanfire) wrote : | #30 |
Please review this VMT description for accuracy and clarity.
NOTE: https:/
Title: GET /v3/OS-
Reporter: Kristi Nikolla
Products: Keystone
Affects: <11.0.4, ==13.0.0, ==12.0.0
Description:
Kristi Nikolla reported a vulnerability in Keystone federation.
By doing GET /v3/OS-
an actor may discover projects they have no authority to access,
leaking all projects in the deployment and their attributes.
Only Keystone with the /v3/OS-FEDERATION endpoint enabled via
policy.json is affected.
| Kristi Nikolla (knikolla) wrote : | #31 |
Morgan, the 500 is what I reported when trying /OS-FEDERATION/
On a Devstack (master branch), it actually worked with any token regardless if it is federated or not.
ubuntu@
WARNING: setting legacy OS_TENANT_NAME to support cli tools.
ubuntu@
ubuntu@
{"links": {"self": "http://
| Kristi Nikolla (knikolla) wrote : | #32 |
Forgot to mention in the previous comment that our public cloud is running Pike
| Morgan Fainberg (mdrnstm) wrote : | #33 |
ack. we will need to be specific. we should try pike without federation setup as well, I wonder when we switched from failing wih a local token to succeeding.
If someone else can't confirm before this weekend, I'll start working on replicating without federation from pike forward. So we can be as accurate as possible.
| Lance Bragstad (lbragstad) wrote : | #34 |
I just got an Ocata deployment up and running. I'm unable to get a list of projects from the v3/OS-FEDERATIO
I believe the KeyError is due to the API assuming that group_ids must be present (e.g. mapping assertions from SAML into group ids and populating them in auth context).
As far as I know, this is inconvenient from a UX perspective. It also doesn't "leak" information like it does on master when handed an unfederated token.
2018-07-12 21:16:19.525 3451 DEBUG keystone.
2018-07-12 21:16:19.526 3451 DEBUG keystone.
2018-07-12 21:16:19.530 3451 DEBUG keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
2018-07-12 21:16:19.530 3451 ERROR keystone.
| Lance Bragstad (lbragstad) wrote : | #35 |
I would adjust the description in comment #30 by removing the term "federated":
"By doing GET /v3/OS-
an actor may discover projects they have no authority to access,
leaking all projects in the deployment and their attributes."
to
"Calling GET /v3/OS-
projects they have no authority to access, leaking all projects
in the deployment and their attributes."
| Matthew Thode (prometheanfire) wrote : | #36 |
Please review this VMT description for accuracy and clarity.
NOTE: https:/
Title: GET /v3/OS-
Reporter: Kristi Nikolla
Products: Keystone
Affects: <11.0.4, ==13.0.0, ==12.0.0
Description:
Kristi Nikolla reported a vulnerability in Keystone federation.
By doing GET /v3/OS-
may discover projects they have no authority to access, leaking
all projects in the deployment and their attributes.
Only Keystone with the /v3/OS-FEDERATION endpoint enabled via
policy.json is affected.
Kristi, is there an affiliation/
Matthew, maybe we could replace "with a token an actor may" by "an authenticated user may" ?
The description looks good to me, thanks.
| Matthew Thode (prometheanfire) wrote : | #38 |
Sure, I'll wait before editing again though (for the company). Don't want too many in a day.
| Kristi Nikolla (knikolla) wrote : | #39 |
Hi Tristan,
Please use "Boston University" for affiliation.
| Matthew Thode (prometheanfire) wrote : | #40 |
Please review this VMT description for accuracy and clarity.
NOTE: https:/
Title: GET /v3/OS-
Reporter: Kristi Nikolla with Boston University
Products: Keystone
Affects: <11.0.4, ==13.0.0, ==12.0.0
Description:
Kristi Nikolla with Boston University reported a vulnerability
in Keystone federation. By doing GET /v3/OS-
an authenticated user may discover projects they have no
authority to access, leaking all projects in the deployment and
their attributes.
Only Keystone with the /v3/OS-FEDERATION endpoint enabled via
policy.json is affected.
| Jeremy Stanley (fungi) wrote : | #41 |
Thanks Matthew! Other than making sure the Affects header is sorted in a chronologically increasing order, that impact description looks great. We should be able to proceed with privately requesting a CVE assignment from MITRE, and assuming Kristi/
| Lance Bragstad (lbragstad) wrote : | #42 |
The description in comment #41 looks good. The patch is pretty trivial and it won't take much to get it proposed to the affected releases. Just for clarity though, here is the summary of proposing the patch from comment #17 to all supported branches:
master: Developed for Rocky, no conflicts.
stable/queens: Patch cleanly cherry-picked from master.
stable/pike: Patch didn't apply cleanly due to internal changes to use a different dependency registry. The fix should still be trivial to apply since it's not using the old or new dependency registry directly (but it won't be exactly like the patch applied to master).
stable/ocata: Same conflict as noted with stable/pike.
Thoughts on the cases for stable/pike and stable/ocata?
Since we have at least 4 keystone folks on this thread, I think we can schedule a time to fast-track the fix and backport it through the supported branches as soon as the VMT gives us the nod. I'd also like to get at least two keystone cores to +2/+A the patch in comment #17 prior to proposals to gerrit (in order to keep review time to a minimum after public disclosure).
| Jeremy Stanley (fungi) wrote : | #43 |
If there is to be progressive downstream disclosure under embargo, we'd need the clean backports attached to this bug in advance so that we can put them in the pre-OSSA notification to other registered stakeholders. Then at the scheduled public disclosure time the same patches would be proposed to Gerrit (immediately after this bug report is made public) and an official advisory would be issued linking to them. https:/
| Lance Bragstad (lbragstad) wrote : | #44 |
Attached is the resolved cherry-pick for stable/pike.
| Lance Bragstad (lbragstad) wrote : | #45 |
Attached is the resolved cherry-pick for stable/pike.
| Lance Bragstad (lbragstad) wrote : | #46 |
Disregard the patch in comment #45. The patch attached here is the correct patch for stable/pike.
| Lance Bragstad (lbragstad) wrote : | #47 |
Apparently I had a second patch locally I kept uploading... sorry for the spam :(
This should be the correct patch for stable/pike (third time is a charm)
| Lance Bragstad (lbragstad) wrote : | #48 |
Attached is the patch with conflicts resolved for stable/ocata.
| Gage Hugo (gagehugo) wrote : | #49 |
The patches look alright, looks like things got moved around between ocata/pike/
| Kristi Nikolla (knikolla) wrote : | #50 |
Looks good to me.
| Lance Bragstad (lbragstad) wrote : | #51 |
Thanks Kristi and Gage for the reviews. We'll wait for the nod from the VMT before proposing anything to gerrit. Once we get a time and date for the disclosure, we'll make sure we have at least a couple cores around to fast-approve the reviews.
| Morgan Fainberg (mdrnstm) wrote : | #52 |
I just wanted to swoop in and as a Keystone core offer a +2 for the current patches (as a VMT member everything is looking good).
When we are ready to publish the changes:
Lance: you, I, Kristi, or Gage can push the patches in and approve them in one swoop (as keystone-cores) referencing this bug for approvals.
| Matthew Thode (prometheanfire) wrote : | #53 |
We have a potential disclosure date of Wednesday, 25-07-2018, 1500UTC. Are Keystone cores available at that time/date?
| Gage Hugo (gagehugo) wrote : | #54 |
I should be available at that time.
| Changed in ossa: | |
| status: | Triaged → Fix Committed |
| assignee: | nobody → Matthew Thode (prometheanfire) |
| Lance Bragstad (lbragstad) wrote : | #55 |
Matthews, I'll be available at that time. I'll wait for confirmation from Kristi and Morgan to make sure we have appropriate core coverage, including stable branches. Thanks for being available, Gage.
| Kristi Nikolla (knikolla) wrote : | #56 |
I will be available at that time also.
| information type: | Private Security → Public Security |
Fix proposed to branch: master
Review: https:/
| Changed in keystone: | |
| assignee: | nobody → Lance Bragstad (lbragstad) |
| status: | Triaged → In Progress |
Fix proposed to branch: stable/queens
Review: https:/
Fix proposed to branch: stable/pike
Review: https:/
Fix proposed to branch: stable/ocata
Review: https:/
| summary: |
- GET /v3/OS-FEDERATION/projects leaks project information + [OSSA-2018-002] GET /v3/OS-FEDERATION/projects leaks project information + (CVE--2018-14432) |
| Changed in ossa: | |
| status: | Fix Committed → Fix Released |
| status: | Fix Released → Fix Committed |
| description: | updated |
| summary: |
[OSSA-2018-002] GET /v3/OS-FEDERATION/projects leaks project information - (CVE--2018-14432) + (CVE-2018-14432) |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/queens
commit 7b1b6a6fc8bdbd2
Author: Lance Bragstad <email address hidden>
Date: Wed Jul 25 15:07:16 2018 +0000
Reduce duplication in federated auth APIs
The GET /v3/OS-
APIs were introduced to handle tokens from federated users, but now
that GET /v3/auth/projects and GET /v3/auth/domains know how to handle
federated tokens, they're just duplicate APIs.
In the past we deprecated these federated auth APIs, but they still
used separate code paths from GET /v3/auth/projects and GET
/v3/
don't expect to differ over time and should provide the same user
experience.
Instead of running the risk that comes with two code paths that do the
same thing, we should consolidate them.
Co-Authored-By: Kristi Nikolla <email address hidden>
Closes-Bug: 1779205
Change-Id: Ib906c42e1dd2c2
(cherry picked from commit df5d75571ed274b
| tags: | added: in-stable-queens |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/ocata
commit ade177ad357d287
Author: Lance Bragstad <email address hidden>
Date: Wed Jul 25 15:07:16 2018 +0000
Reduce duplication in federated auth APIs
The GET /v3/OS-
APIs were introduced to handle tokens from federated users, but now
that GET /v3/auth/projects and GET /v3/auth/domains know how to handle
federated tokens, they're just duplicate APIs.
In the past we deprecated these federated auth APIs, but they still
used separate code paths from GET /v3/auth/projects and GET
/v3/
don't expect to differ over time and should provide the same user
experience.
Instead of running the risk that comes with two code paths that do the
same thing, we should consolidate them.
Conflicts:
keystone/
code used a different dependency framework. This was reworked in
the Queens release, causing a conflict with this patch since it
touches the same code.
keystone/
similar naming and placement within the same test module.
Co-Authored-By: Kristi Nikolla <email address hidden>
Closes-Bug: 1779205
Change-Id: Ib906c42e1dd2c2
(cherry picked from commit df5d75571ed274b
| tags: | added: in-stable-ocata |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: master
commit df5d75571ed274b
Author: Lance Bragstad <email address hidden>
Date: Wed Jul 25 15:07:16 2018 +0000
Reduce duplication in federated auth APIs
The GET /v3/OS-
APIs were introduced to handle tokens from federated users, but now
that GET /v3/auth/projects and GET /v3/auth/domains know how to handle
federated tokens, they're just duplicate APIs.
In the past we deprecated these federated auth APIs, but they still
used separate code paths from GET /v3/auth/projects and GET
/v3/
don't expect to differ over time and should provide the same user
experience.
Instead of running the risk that comes with two code paths that do the
same thing, we should consolidate them.
Co-Authored-By: Kristi Nikolla <email address hidden>
Closes-Bug: 1779205
Change-Id: Ib906c42e1dd2c2
| Changed in keystone: | |
| status: | In Progress → Fix Released |
Reviewed: https:/
Committed: https:/
Submitter: Zuul
Branch: stable/pike
commit ce46cc25dc4d967
Author: Lance Bragstad <email address hidden>
Date: Wed Jul 25 15:07:16 2018 +0000
Reduce duplication in federated auth APIs
The GET /v3/OS-
APIs were introduced to handle tokens from federated users, but now
that GET /v3/auth/projects and GET /v3/auth/domains know how to handle
federated tokens, they're just duplicate APIs.
In the past we deprecated these federated auth APIs, but they still
used separate code paths from GET /v3/auth/projects and GET
/v3/
don't expect to differ over time and should provide the same user
experience.
Instead of running the risk that comes with two code paths that do the
same thing, we should consolidate them.
Conflicts:
keystone/
code used a different dependency framework. This was reworked in
the Queens release, causing a conflict with this patch since it
touches the same code.
Co-Authored-By: Kristi Nikolla <email address hidden>
Closes-Bug: 1779205
Change-Id: Ib906c42e1dd2c2
(cherry picked from commit df5d75571ed274b
| tags: | added: in-stable-pike |
| Changed in ossa: | |
| status: | Fix Committed → Fix Released |
This issue was fixed in the openstack/keystone 13.0.1 release.
This issue was fixed in the openstack/keystone 11.0.4 release.
This issue was fixed in the openstack/keystone 12.0.1 release.
| Abhishek Sharma M (abhi.sharma) wrote : | #68 |
Description part in http://
| Guang Yee (guang-yee) wrote : | #69 |
As far as I can tell, this problem seem to impact stable/queens and master (Rocky) only. It does NOT seem to impact the older branches. My assessment was based on devstack with federation enabled. i.e.
# only enable the services we care about
disable_
enable_plugin keystone git://git.
enable_service mysql rabbit keystone keystone-
KEYSTONE_
KEYSTONE_
I setup K2K federtation with the same instance acting as both IdP and SP. btw,
keystone-
fresh vagrant. So far I tested the following branches:
newton-eol
stable/ocata
stable/pike
stable/queens
master
Here's what I found.
1. The problem does NOT impact the federated tokens. Using a federated token, /v3/OS-
2. Using a local user token (i.e. demo/demo), /v3/OS-
Aug 1 11:18:27 ubuntu <email address hidden>[19553]: ERROR keystone.
Aug 1 11:18:27 ubuntu <email address hidden>[19553]: ERROR keystone.
Aug 1 11:18:27 ubuntu <email address hidden>[19553]: ERROR keystone.
| Guang Yee (guang-yee) wrote : | #70 |
The original problem may've caused by a couple of things.
1. This patch basically automatically added the 'group_ids' attribute in the auth_context regardless whether there are any groups or not.
https:/
It landed in Queens. This patch basically enabled the /v3/OS-
2. This could be a another bug. When listing assignments for groups, we should be using the groups filter, not 'source_
https:/
'source_
https:/
So it appears that if 'source_
Related fix proposed to branch: master
Review: https:/
This issue was fixed in the openstack/keystone 14.0.0.0rc1 release candidate.
Change abandoned by Lance Bragstad (<email address hidden>) on branch: master
Review: https:/
Kristi came to me with this today in a private IRC discussion. We confirmed the bug, but we accidentally put the results in paste.openstack.org [0][1]. Someone could discover this issue by scrubbing paste (including for full disclosure).
[0] http://
[1] http://