8a66ef6354
This is the first step of several to remove PKI token support in keystone. A large issue in removing PKI support is support for the revocation list must be maintained. This patch removes support for the token format, it's surrounding tests and examples that are generated. Additionally, some wording has been changed around the CLI and config options to make the distinction between keys and certs used for PKI tokens and those used for getting the revocation list (a list of tokens that are revoked, which is signed). Future patches will: - Remove the keystone-manage commands for generating certs - Modify the revocation list (at /auth/tokens/OS-PKI/revoked) to return a 403 if pki is not configured (instead of raising a 500). We cannot remove the API as that would break an API contract. - Options to configure PKI will be marked as deprecated - If PKI is configured a normal signed list will be returned (same behavior as today) - Follow up patch to keystonemiddleware will make sure auth_token does not rely on the revocation api at all. Related-Bug: 1626778 Related-Bug: 1626779 Co-Authored-By: Boris Bobrov <bbobrov@mirantis.com> bp removed-as-of-ocata Change-Id: Icf1ebced44a675c88fb66a6c0431208ff5181574
158 lines
6.0 KiB
INI
158 lines
6.0 KiB
INI
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
# not use this file except in compliance with the License. You may obtain
|
|
# a copy of the License at
|
|
#
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
#
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
# License for the specific language governing permissions and limitations
|
|
# under the License.
|
|
|
|
# This file contains a specification of what feature capabilities each driver
|
|
# is able to support. Feature capabilities include what API operations are
|
|
# supported, what backend behaviors features can be used and what aspects of
|
|
# the driver implementation can be configured. The capabilities can be
|
|
# considered to be structured into nested groups, but in this file they have
|
|
# been flattened for ease of representation. The section names represent the
|
|
# group structure. At the top level there are the following groups defined:
|
|
#
|
|
# - operation: Public API operations.
|
|
# - feature: Features of the token format.
|
|
#
|
|
# When considering which capabilities should be marked as mandatory, consider
|
|
# the following guiding principles.
|
|
#
|
|
# The 'status' field takes possible values:
|
|
#
|
|
# - mandatory: Unconditionally required to be implemented.
|
|
# - optional: Optional to support, but nice to have.
|
|
# - choice(group): At least one of the options within the named group
|
|
# must be implemented.
|
|
# - conditional(cond): Required, if the referenced condition is met.
|
|
#
|
|
# The value against each 'driver-impl-XXXX' entry refers to the level of the
|
|
# implementation of the feature in that driver:
|
|
#
|
|
# - complete: Fully implemented, expected to work at all times.
|
|
# - partial: Implemented, but with caveats about when it will work.
|
|
# For example, some configurations or hardware or guest OS may not
|
|
# support it.
|
|
# - missing: Not implemented at all.
|
|
#
|
|
# In the case of the driver being marked as 'partial', then
|
|
# 'driver-notes-XXX' entry should be used to explain the caveats around the
|
|
# implementation.
|
|
#
|
|
# The 'cli' field takes a list of client commands, separated by semicolon.
|
|
# These CLi commands are related to that feature.
|
|
# Example:
|
|
# cli=openstack domain list;openstack domain show <domain>
|
|
#
|
|
[targets]
|
|
# List of driver implementations for which we are going to track the status of
|
|
# features. This list only covers drivers that are in tree. Out of tree
|
|
# drivers should maintain their own equivalent document, and merge it with this
|
|
# when their code merges into core.
|
|
driver-impl-uuid=UUID tokens
|
|
driver-impl-fernet=Fernet tokens
|
|
|
|
[operation.create_unscoped_token]
|
|
title=Create unscoped token
|
|
status=mandatory
|
|
notes=All token providers must be capable of issuing tokens without an explicit
|
|
scope of authorization.
|
|
cli=openstack --os-username=<username> --os-user-domain-name=<domain>
|
|
--os-password=<password> token issue
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[operation.create_project_scoped_token]
|
|
title=Create project-scoped token
|
|
status=mandatory
|
|
notes=All token providers must be capable of issuing project-scoped tokens.
|
|
cli=openstack --os-username=<username> --os-user-domain-name=<domain>
|
|
--os-password=<password> --os-project-name=<project>
|
|
--os-project-domain-name=<domain> token issue
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[operation.create_domain_scoped_token]
|
|
title=Create domain-scoped token
|
|
status=optional
|
|
notes=Domain-scoped tokens are not required for all use cases, and for some use
|
|
cases, projects can be used instead.
|
|
cli=openstack --os-username=<username> --os-user-domain-name=<domain>
|
|
--os-password=<password> --os-domain-name=<domain> token issue
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[operation.create_trust_scoped_token]
|
|
title=Create trust-scoped token
|
|
status=optional
|
|
notes=Tokens scoped to a trust convey only the user impersonation and
|
|
project-based authorization attributes included in the delegation.
|
|
cli=openstack --os-username=<username> --os-user-domain-name=<domain>
|
|
--os-password=<password> --os-trust-id=<trust> token issue
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[operation.create_token_using_oauth]
|
|
title=Create a token given an OAuth access token
|
|
status=optional
|
|
notes=OAuth access tokens can be exchanged for keystone tokens.
|
|
cli=
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[operation.create_token_with_bind]
|
|
title=Create a token with a bind attribute
|
|
status=optional
|
|
notes=Tokens can express a binding to an additional authentication method, such
|
|
as kerberos or x509.
|
|
cli=
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=missing
|
|
|
|
[operation.revoke_token]
|
|
title=Revoke a token
|
|
status=optional
|
|
notes=Tokens may be individually revoked, such as when a user logs out of
|
|
Horizon. Under certain circumstances, it's acceptable for more than just a
|
|
single token may be revoked as a result of this operation (such as when the
|
|
revoked token was previously used to create additional tokens).
|
|
cli=openstack token revoke
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[feature.online_validation]
|
|
title=Online validation
|
|
status=mandatory
|
|
notes=Keystone must be able to validate the tokens that it issues when
|
|
presented with a token that it previously issued.
|
|
cli=
|
|
driver-impl-uuid=complete
|
|
driver-impl-fernet=complete
|
|
|
|
[feature.offline_validation]
|
|
title=Offline validation
|
|
status=optional
|
|
notes=Services using Keystone for authentication may want to validate tokens
|
|
themselves, rather than calling back to keystone, in order to improve
|
|
performance and scalability.
|
|
cli=
|
|
driver-impl-uuid=missing
|
|
driver-impl-fernet=missing
|
|
|
|
[feature.non_persistent]
|
|
title=Non-persistent
|
|
status=optional
|
|
notes=If a token format does not require persistence (such as to a SQL
|
|
backend), then there is no scalability limit to the number of tokens that
|
|
keystone can issue at once, and there is no need to perform clean up
|
|
operations such as `keystone-manage token_flush`.
|
|
cli=
|
|
driver-impl-uuid=missing
|
|
driver-impl-fernet=complete
|