This spec proposes to to add a new keystone middleware that implements
RFC7662 OAuth 2.0 Token Introspection [1] and allows users to optionally
use that middleware when using an external authorization server.
OpenStack services will be able to validate their OAuth2.0 client with
an external authorization server other than Keystone.
[1] https://datatracker.ietf.org/doc/html/rfc7662
Change-Id: Ie1066ab2735205fcb534e7697c3b9a5aa2d23eeb
This spec proposes to Provide the option for users to
proof-of-possession of OAuth2.0 access token based on RFC8705 OAuth 2.0
Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
Users will be able to authenticate their OAuth2.0 client with a client
certificate instead of using Basic authentication with
client_id/client_secret to prevent a token from being used by a
malicious client. This protects Keystone Identity and other OpenStack
services from spoofed OAuth clients.
Change-Id: I67e030c183631bd421cc93ceb767f60fa178238a
This spec proposes to allow users to optionally use an OAuth2.0 Client
Credentials Grant flow to authorize an API client. In order to realize
this, we implement an OAuth2.0 authorization server as an extension of
keystone.
Implements: blueprint oauth2-client-credentials-ext
Change-Id: I4954c1e8f22199deb13031441c46a3565383412d
Add federated users to the groups that they receive from the mapping rules.
This membership is only carried by the token and not persisted in the
database. The membership expires, but can be renewed when the user
authenticates with the same group.
Previously approved for Train, fell into backlog, reproposing for Ussuri.
Change-Id: Ie133c14ffba5e4189265920759bfb5e1391f1189
Partial-Bug: 1809116
* Move uncompleted specs to the backlog (will discuss adding them to
Ussuri in planning meeting)
* Move Train section under "implemented"
* Create new empty section for Ussuri with new roadmap link
Change-Id: Id06bba1512364f8b4daeb3a594ff1e5b896f1b90
These style errors weren't caught before the specs merged because the
linter jobs weren't being run when only RST files were changed. Correct
them now so that a later patch can update the jobs.
Change-Id: I1c24cece2c64c9453698280cc365ac150d2474a4
Add federated users to the groups that they receive from the mapping rules.
This membership is only carried by the token and not persisted in the
database. The membership expires, but can be renewed when the user
authenticates with the same group.
Partial-Bug: 1809116
Change-Id: If376a1ce18f9b628f429f3cac957c76dacd00a34
This spec proposes to allow roles, users, projects, and domains to be
marked as "immutable", and further elaborates on the migration procedure
to make the admin role immutable by default.
Co-authored-by: Lance Bragstad <lbragstad@gmail.com>
Change-Id: I9b537ef7a70fa7e61c8cf0d6811120198a01ab37
The Goals document and the Roadmap document are closely related to each
other and both cover long-term, ongoing work. This change combines the
specs so that a view of the whole policy story can be found in one
document.
Change-Id: Ib6ff52bf6d337bc0390da168ee960644137ef40a
Since there is no active work happening on this improvement, but we
still generally think it's the right direction, move the spec from
"ongoing" to "backlog" so that it can be picked up when we are ready to
plan it into a cycle.
Change-Id: I69403a035bf4540a93f4728f8b795d9c7a85cc6f
As discussed at the PTG, we don't want to focus on expanding the scope
of endpoint filtering, so rather than keep it in the backlog to wait for
someone to pick it up, move it to the attic to signal that this is not
something we want to prioritize. If we decide this is valuable and
someone is willing to pick it up, we can always move it back out of the
attic.
Change-Id: I95c094f4d4df2e44cd23d2715275199a4e6c8200
Resource options for all needed a little more
information about the end user impact. This
change adds that information.
Change-Id: I6131c08cf5730077ab74a47f2806f1d0b0456995
Move the request-helpers backlog spec for keystonemiddleware to the
attic. At the Denver PTG (2019) we discussed this spec. We are in a
very different space from where we were at the time of proposal, and
if there is a desire to revisit this specific specification it can
be brought back from the attic.
Change-Id: I3e1ab025bb998b14c0a71854b9109d9f29b25ee9
As discussed at the Denver (2019) PTG, this spec is not super useful as
proposed. We have started work to improve our testing in a number of
ways. If the specific use-case of functional testing as proposed in the
spec receives interest the spec can be retrieved from the attic.
Change-Id: I238b16a30f131bf9d6a754c4dda48ac8e83a51b0
The work around the object dependency lifecycle spec was completed rocky
when the @depends and associated magic attribute handling for the
managers was eliminated for the single-instnatiation set of managers
directly referenced instead of self.XXXX_api
Change-Id: I5469195ff97bf1a36ce3936c2ad497f70b42470f
At the Denver PTG, it was agreed that the endpoint-enforcement spec for
the endforcement of endpoint filtering in middleware is not something
we are looking to implement. The spec can be recovered from the attic
if there is interest in the work.
Change-Id: I9e13969714f56a166c6394934514d7b95b849e05
Expanding upon the Risk Mitigation section of the spec. Note that
role implications will be created admin->member->reader regardless of
whether or not a new role was created during bootstrap.
Change-Id: Ie5cfd122554ccb06be3a7b165209c6b9c3f453db
Most of the work for this has already been done, and with the move
towards predictable IDs, there is a real need for a mechanism
to prepopulate the users as part of the synchronization process.
https://review.openstack.org/#/c/612099/
Related-Bug: 1816076
Change-Id: I9906a9d76479364134ef21a0cf578ff6d5cf07b9
This patch fixes the url of the flat
enforcement model in the spec
strict_two_level_enforcement_model.rst
Change-Id: Iec9d0a5dcfef268dce5f664075256806c93ee2a6
Specification defining the addition of resource options for all
resources within Keystone isntead of just users.
Change-Id: I6228e503f908b4bc82aa55b908995314e3e6adf7
partial-bug: 1807751
The explicit domain IDs and capabilities/access rules specs were not
finished in Stein but are already in progress and on target to finish
early in the Train cycle.
Change-Id: I052079fcdb11f8e11c854b11d8013fd460f421ec
This is a mechanically generated change to replace openstack.org
git:// URLs with https:// equivalents.
This is in aid of a planned future move of the git hosting
infrastructure to a self-hosted instance of gitea (https://gitea.io),
which does not support the git wire protocol at this stage.
This update should result in no functional change.
For more information see the thread at
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
Change-Id: Idc8ee6859b7c3428014b2e9e905317121412550a
This change brings the spec, which was agreed upon nearly a year ago,
into alignment with the current proposed implementation. It also cleans
up some formatting and style issues.
Change-Id: I0bd99d24517b90f16557aadc3d721ecee9cd8eb5
Rafael Weingärtner