idp deletion should trigger token revocation

Bug #1291157 reported by Steve Martinelli on 2014-03-12
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Lance Bragstad

Bug Description

When a federation IdP is deleted, the tokens that were issued (and still active) and associated with the IdP should be deleted. To prevent unwarranted access. The fix should delete any tokens that are associated with the idp, upon deletion (and possibly update, too).

Changed in keystone:
importance: Undecided → High
milestone: none → icehouse-rc1
Dolph Mathews (dolph) on 2014-03-12
summary: - idp deletion should trigger token deletion
+ idp deletion should trigger token revocation
Changed in keystone:
status: New → Triaged
Dolph Mathews (dolph) wrote :

As discussed in today's keystone meeting, keystoneclient.middleware.auth_token can track valid IdPs on GET /v3/OS-FEDERATION/identity_providers and compare them to tokens to test for validity.

Changed in python-keystoneclient:
status: New → Triaged
importance: Undecided → High
Changed in keystone:
milestone: icehouse-rc1 → next
Changed in python-keystoneclient:
milestone: none → 0.7.0
Dolph Mathews (dolph) on 2014-03-24
Changed in python-keystoneclient:
milestone: 0.7.0 → none
Navid Pustchi (npustchi) on 2014-05-29
Changed in keystone:
assignee: nobody → Navid Pustchi (npustchi)
Changed in python-keystoneclient:
assignee: nobody → Navid Pustchi (npustchi)
Victor Silva (victorsilva) wrote :

For anyone who tries to tackle this in the future, @rodrigods, @raildo, @tellesnobrega and I gave it a try and this is where we got:

As discussed on #keystone, this seems to be fairly easy to solve for UUID tokens, and should be done on the server (keystone), as indicated by @ayoung.

For PKI tokens, however, we might still need to do some more work elsewhere. The validation step in keystonemiddleware doesn't have access to the entire token, just its id, and the same approach of simply double checking a token's IdP against the list of valid IdPs won't work.

There is an ongoing discussion about things that might help, with mentions to revocation events, decreasing the lifespan of tokens and fixing up mappings between IdP and domains. Whoever solves this should watch out for these changes and figure out another approach!

Dolph Mathews (dolph) wrote :

The IdP ID was included in federated tokens specifically to support IdP IDs appearing in revocation events (and being able to match the two together in keystonemiddleware.auth_token). I don't see a need for an alternative solution (with or without regard to UUID vs PKI).

Changed in keystone:
assignee: Navid Pustchi (npustchi) → nobody
Changed in python-keystoneclient:
assignee: Navid Pustchi (npustchi) → nobody
Changed in keystone:
assignee: nobody → Paweł Pamuła (pawel-pamula)
Changed in python-keystoneclient:
assignee: nobody → Paweł Pamuła (pawel-pamula)

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

Changed in keystone:
status: Triaged → In Progress
David Chadwick (d-w-chadwick) wrote :

I fully understand why IDP deletion should delete/revoke tokens, but why should an update to the IDP trigger the same thing? E.g. suppose the SAML meta data for an IDP is updated. This should not mean that users tokens are invalidated. e.g. key update is a perfectly normal event as keys have a natural life span

Marek Denis (marek-denis) wrote :

metadata would be upgraded in apache module, so there is no direct link with revocation events.
Speaking of updating, token should be invalidated only when the idp is set to disabled. Other than that, there are configuration changes, but as David pointed out, the IdP is still deemed enabled.

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

Change abandoned by Paweł Pamuła (<email address hidden>) on branch: master
Review: https://review.openstack.org/212047
Reason: Duplicate change.

Changed in keystone:
assignee: Paweł Pamuła (pawel-pamula) → Marek Denis (marek-denis)
Dolph Mathews (dolph) on 2015-08-28
tags: added: federation
Steve Martinelli (stevemar) wrote :

unassigning due to inactivity and failing patch sets, also this doesn't affect keystoneclient

Changed in python-keystoneclient:
status: Triaged → Invalid
Changed in keystone:
status: In Progress → Confirmed
assignee: Marek Denis (marek-denis) → nobody
Changed in python-keystoneclient:
assignee: Paweł Pamuła (pawel-pamula) → nobody
Changed in keystone:
milestone: next → none
Changed in python-keystoneclient:
importance: High → Medium
Changed in keystone:
importance: High → Medium
tags: added: revoke
Changed in keystone:
assignee: nobody → Sean Perry (sean-perry-a)
status: Confirmed → In Progress

Change abandoned by Morgan Fainberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/210456
Reason: This change has not seen love in quite a number of months. Abandoning. It can be restored if someone would like to take another stab at it.

Steve Martinelli (stevemar) wrote :

unassigning due to inactivity

Changed in keystone:
assignee: Sean Perry (sean-perry-a) → nobody
status: In Progress → Confirmed
no longer affects: python-keystoneclient
Changed in keystone:
assignee: nobody → Anthony Washington (anthony-washington)
Changed in keystone:
status: Confirmed → Invalid
assignee: Anthony Washington (anthony-washington) → nobody
Lance Bragstad (lbragstad) wrote :

I'm not sure https://review.openstack.org/#/c/414720/29 complete fixes the issue. I don't think that patch (list federated attributes for users) adds a revocation event of any kind when an Identity Provider is deleted.

There are a couple proposed solutions that have been abandon that we can pick and try to move forward through [0].

[0] https://review.openstack.org/210456

Changed in keystone:
status: Invalid → Confirmed
Steve Martinelli (stevemar) wrote :

@Lance, i think the referenced patch was incorrect, https://review.openstack.org/#/c/415906/ may have fixed the issue.

Lance Bragstad (lbragstad) wrote :

Aha - I read that as https://review.openstack.org/#/c/414720/ (federated attributes for user) as fixing the issue. https://review.openstack.org/#/c/415906/ should have a different impact on this bug.

Lance Bragstad (lbragstad) wrote :

I was able to recreate this using master, so the bug is still present. Pushing a patch to expose the behavior.

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

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: Confirmed → In Progress
Lance Bragstad (lbragstad) wrote :

this patch exposes the issue https://review.openstack.org/#/c/512872/

Reviewed: https://review.openstack.org/512872
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8f2273a54e5349b5e7f94924f54297bb9b0164fe
Submitter: Zuul
Branch: master

commit 8f2273a54e5349b5e7f94924f54297bb9b0164fe
Author: Lance Bragstad <email address hidden>
Date: Tue Oct 17 21:41:21 2017 +0000

    Deleting an identity provider doesn't invalidate tokens

    This commit exposes a bug where it's possible to continue using a
    federated token even after the identity provider is deleted.

    Change-Id: Id19ff4f7823bdc2b078f27f9dc544f7a5ff9ea99
    Partial-Bug: 1291157

tags: added: office-hours
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers