When calling the s3tokens or ec2tokens API with a
HTTP GET we should get a 405 Method Not Allowed but
we get a 500 Internal Server Error because we enforce
that method.
Closes-Bug: #2052916
Change-Id: I5f60d10dc25551175cc73ca8f3f28b0b95ec9f99
Signed-off-by: Tobias Urdin <tobias.urdin@binero.se>
This patch fixes an inconsistency in the policies for role_assignment
where the target object used for policy enforcement was being created
with different properties depending on the request query string.
This required policies to be written in two differnt ways to validate
domain IDs for domain-scoped requests. e.g. checking for domain reader
was using both:
role:reader and domain_id:%(target.domain_id)s
and
role:reader and domain_id:%(target.project.domain_id)s
With the former only being populated for GET /v3/role_assignments and
the latter only being populated for GET
/v3/role_assignments?scope.project.id=SOME_ID
This patch fixes the target object so that only target.domain_id needs
to be checked for domain-scoped tokens.
Change-Id: Iffbe11c57c61bbd1b045a6567a9249c12dff403c
Introduces domain-scoped filtering of the response list of the
list_domains endpoint when the user is authenticated in domain scope
instead of returning all domains. This aligns the implementation with
other endpoints like list_projects or list_groups and allows for a
domain-scoped reader role.
Changes the default policy rule for identity:list_domains to
incorporate this new behavior for the reader role.
Closes-Bug: 2041611
Change-Id: I8ee50efc3b4850060cce840fc904bae17f1503a9
otherwise the initiator field is missing from the CADF payload,
which misses the point of audit and technically makes these notifications
not valid as CADF events (initiator field is requires by the
CADF spec).
Change-Id: Iae525ee13dec72af6a7d70db2bb59a77c682a177
We propose to extend Keystone identity provider (IdP) attribute mapping
schema to make Keystone honor the `domain` configuration that we have
on it.
Currently, that configuration is only used to define a default domain
for groups (and then each group there, could override it). It is
interesting to expand this configuration (as long as it is in the root
of the attribute mapping) to be also applied for users and projects.
Moreover, to facilitate the development and extension concerning
attribute mappings for IdPs, we changed the way the attribute mapping
schema is handled. We introduce a new configuration
`federation_attribute_mapping_schema_version`, which defaults to "1.0".
This attribute mapping schema version will then be used to control the
validation of attribute mapping, and also the rule processors used to
process the attributes that come from the IdP. So far, with this PR,
we introduce the attribute mapping schema "2.0", which enables
operators to also define a domain for the projects they want to assign
users. If no domain is defined either in the project or in the global
domain definition for the attribute mapping, we take the IdP domain
as the default.
Change-Id: Ia9583a254336fad7b302430a38b538c84338d13d
Implements: https://bugs.launchpad.net/keystone/+bug/1887515
Closes-Bug: #1887515
We shouldn't specify a server default for a configurable option since it
means our initial database schema is not consistently reproducible.
Instead, we should specify the default at runtime. It turns out we
already do this and the server default was overkill. We can remove it.
Change-Id: I74e47a9ed986c7c3af19676ac65f4d290bcb4cc0
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The OAuth2.0 Access Token API is modified, support to get an OAuth2.0
certificate-bound access token from the keystone identity server with
OAuth 2.0 credentials and Mutual-TLS certificates.
Co-Authored-By: Hiromu Asahina <hiromu.asahina.az@hco.ntt.co.jp>
Change-Id: I885527bec61429b1437a046097a16491848b5a0a
Implements: blueprint support-oauth2-mtls
The pep257 dependency does not support Python 3.10 and has been
deprecated in favour of flake8-docstrings. While we're here, we bump the
other linter dependencies and remove a note regarding the order of
dependencies, which is no longer true with the new dependency resolver
introduced in pip 20.3. We also remove an import exception for six.moves
since we no longer use six.
Change-Id: I4aae75f513568126230becf27b2e07d6682d35a1
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
When we check the EC2 signature without the port part of the host value
received, we should properly split host:port. Keep in mind the splitting
should work for values like [fc00::]:123 too.
Change-Id: I1d90dfcea3568e2a9b22069daa428ea6a2a38bd6
Closes-Bug: #1988168
The OAuth2.0 Access Token API is added, support to get an OAuth2.0
access token from the keystone identity server with application
credentials.
Change-Id: I4c54649a51534637be831450afc32d3ef8644ee5
token_bytes is an standard library secrets function ,we can get the information from link https://www.python.org/dev/peps/pep-0506/
Change-Id: I7e6b1df5eac59bac33674934d7b3e8cdd16cea27
Ceph Object Gateway can use keystone for authenticating user requests
to its S3-compatible API, but recent versions also provide two other
AWS-compatible APIs for managing user access: Security Token Service
(STS) and Identity and Access Management (IAM). These attempt to
authenticate requests with Keystone but always receive 403 Access
Denied because _calculate_signature_v4() in api/s3tokens.py only
accepts "s3" as the service name. This patch accepts any of "s3" or
"sts" or "iam" as valid service names.
Change-Id: I69f16ed55dd9852859307b701a8391ba1e71c042
Closes-Bug: #1897280
The application credential policies use the `rule:owner` policy to allow
users to manage their own credentials. The policy engine pulled the
user_id attribute from the request path instead of the actual
application credential. This allowed for users to exploit the
enforcement and view or delete application credentials they don't own.
This commit attempts to resolve the issue by updating the flask
parameters before they're translated to policy arguments and target
data, prior to policy enforcement.
Change-Id: I903d20fa41270499ca1c39d296120dd97cef5405
Closes-Bug: 1901207
This change addresses several issues in the creation and use of EC2/S3
credentials with keystone tokens.
1. Disable altering credential owner attributes or metadata
Without this patch, an authenticated user can create an EC2 credential
for themself for a project they have a role on, then update the
credential to target a user and project completely unrelated to them. In
the worst case, this could be the admin user and a project the admin
user has a role assignment on. A token granted for an altered credential
like this would allow the user to masquerade as the victim user. This
patch ensures that when updating a credential, the new form of the
credential is one the acting user has access to: if the system admin
user is changing the credential, the new user ID or project ID could be
anything, but regular users may only change the credential to be one
that they still own.
Relatedly, when a user uses an application credential or a trust to
create an EC2 credential, keystone automatically adds the trust ID or
application credential ID as metadata in the EC2 access blob so that it
knows how the token can be scoped when it is used. Without this patch, a
user who has created a credential in this way can update the access blob
to remove or alter this metadata and escalate their privileges to be
fully authorized for the trustor's, application credential creator's, or
OAuth1 access token authorizor's privileges on the project. This patch
fixes the issue by simply disallowing updates to keystone-controlled
metadata in the credential.
2. Respect token roles when creating EC2 credentials
Without this patch, a trustee, an application credential user, or an
OAuth1 access token holder could create an EC2 credential or an
application credential using any roles the trustor, application
credential creator, or access token authorizor had on the project,
regardless of whether the creator had delegated only a limited subset of
roles. This was because the trust_id attribute of the EC2 access blob
was ignored, and no metadata for the application credential or access
token was recorded either. This change ensures that the access
delegation resource is recorded in the metadata of the EC2 credential
when created and passed to the token provider when used for
authentication so that the token provider can look up the correct roles
for the request.
Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
EC2 token requests contain a signature that signs the entire request,
including the access timestamp. While the signature is checked, the
timestamp is not, and so these signed requests remain valid
indefinitely, leaving the token API vulnerable to replay attacks. This
change introduces a configurable TTL for signed token requests and
ensures that the timestamp is actually validated against it.
The check will work for either an AWS Signature v1/v2 'Timestamp'
parameter[1] or the AWS Signature v4 'X-Aws-Date' header or
parameter[2].
Although this technically adds a new feature and the default value of
the feature changes behavior, this change is required to protect
credential holders and therefore must be backported to all supported
branches.
[1] https://docs.aws.amazon.com/general/latest/gr/signature-version-2.html
[2] https://docs.aws.amazon.com/general/latest/gr/sigv4-date-handling.html
Change-Id: Idb10267338b4204b435df233c636046a1ce5711f
Closes-bug: #1872737
The repo is Python 3 now, so update hacking to version 3.0 which
supports Python 3.
Fix problems found.
Update local hacking checks for new flake8.
Change-Id: Ic440219814ee0c2b98217e9a821f38f5baf482ec
This patch extends the identity provider API to receive, return
and set the authorization_ttl on an identity provider.
Change-Id: I3c58da290d52149e307280042ed20447da4687f7
Partial-Bug: 1809116
When a federated user authenticates, they are added to their
mapped groups during shadowing.
Closes-Bug: 1809116
Change-Id: I19dc400b2a7aa46709b242cdeef82beaca975ff3
Currently, a keystone IdP does not provide the
groups to which user belong when generating SAML
assertions.This patch adds an additional attribute
called "openstack_groups" in the assertion.
Change-Id: I205e8bbf9a4579b16177f57e29e363f4205a2b48
Closes-Bug: #1641625
This repo does not support Python 2 anymore, so we don't need
six for compatibility between Python2 and 3, convert six usage to Python
3 code.
Change-Id: Icba56808f38277b27af2ae5aac4b8507dee71b3b
Without this patch, project members and readers can list any credentials
with the /v3/credentials API when enforce_scope is false. enforce_scope
is only applicable to project admins due to the admin-ness problem[1],
and this policy is not meant to allow project admins any access to users'
credentials (only system admins should be able to access them). However,
when enforce_scope is false, we need to preserve the old behavior of
project admins being able to list all credentials. This change mitigates
the problem by running the identity:get_credential policy check to
filter out credentials the user does not have access to. This will
impact performance.
Closes-bug: #1855080
[1] https://bugs.launchpad.net/keystone/+bug/968696
Change-Id: I5dd85a6b8368373a27aef2942a64499d020662ef
In 09088690 we mistakenly added E501 to the flake8 ignore list. Since
then, many new violations have been introduced. This patch re-enables
the check and corrects all violations, except in some cases like unit
test names where the subunit output would suffer if we attempted to
shorten the function name.
This may appear to be a pointless no-op that messes with
git-blameability, and it is, but the reason to do this is that if PEP8
violations are introduced in master and then backported to a stable
branch, most stable branches will fail the pep8 job since the flake8
ignore list is correct for those branches. Rather than loosening the
check in older branches or requiring those backports to fix the linter
errors independently of what's been merged in master, we should fix it
now so that we don't introduce more errors in the future and patches can
more easily be backported.
Change-Id: I9f71926105eb448bb0200201d1838b67d4963cd6
This commit adds domain-scope to the scope_types for limit policies,
allowing domain users to access those APIs when enforce_scope is
enabled. This commit also introduces some tests that explicitly show
how domain users are expected to behave with the limits API. A
subsequent patch will do the same for project users.
This commit also modifies the GET /v3/limit policy to allow project
users to filter responses by project_id, which isn't entirely useful
outside of just calling the API with a project-scoped token.
Change-Id: I9b38f3fd2f83efd508b2d9a6c323bbaa7169d4cd
Related-Bug: 1805880
Partial-Bug: 1818736
This commit makes it so that project tags adhere to system-scope and
also incorporates default roles into the policy checks by default.
Change-Id: Ie36df5677a08d7d95f056f3ea00eda05e1315ea5
Closes-Bug: 1844194
Closes-Bug: 1844193
Related-Bug: 1806762
Without this patch, if a project ID is not passed as query argument, a
target of {} is passed to the enforcer and causes a type error to be
raised ("'NoneType' object is not callable") which then is emitted as a
validation error to the user rather than as a server error. This patch
fixes the issue by correctly passing in None as the default target,
which is what the enforcer expects, which then allows the validation to
continue and return a more helpful error message about the required
query parameter.
Change-Id: If7f0fa4dd072b0f00172161da4f7b91f8c1e1f10
This is to add remote_id definition in _perform_auth, otherwise
if no remote_id is found, we'll get "NameError: name 'remote_id'
is not defined" exception.
Change-Id: I2ad7dd6d9e7f74dbeaa87a68472be75b04cef631
Closes-Bug: #1844207
This change updates the minor API version for the new access rules
feature for application credentials, and also adds documentation for
the new feature to the API reference as well as a release note.
bp whitelist-extension-for-app-creds
Change-Id: I8a03223df63877a4f86fbe7e9fa382fdd96c5934
This change adds application credential access rules to the token model
and ensures that only clients (that is, keystonemiddleware) that support
access rule enforcement are allowed to validate tokens containing
access rules.
Depends-on: https://review.openstack.org/633369
bp whitelist-extension-for-app-creds
Change-Id: I301651369cf03e06550bc29eb534506674e56a1f
This change creates a /v3/users/{user_id}/access_rules endpoint to allow
users to view and delete their own access rules. Access rules are not
automatically deleted when an application credential is deleted, so they
can be re-used for other application credentials or explicitly deleted
by the user. Access rules are automatically deleted when the user is
deleted, the same way that application credentials are. Access rules
that are in use by an application credential may not be deleted.
bp whitelist-extension-for-app-creds
Change-Id: I37d243d802cd538189ccfffee6ebf0624b7785d3
This change updates the EC2 credentials policies to understand
the scope types for EC2 credentials. A follow on patch will
Remove obsolete credential policies.
To maintain the compatibility with the old rule the
equivalent ec2_list_credentials and ec2_get_credentials behaves
inconsistently. Same for ec2_create_credentials and the
ec2_delete_inconsistently.
Change-Id: I090e2470726d22b2670a2cca89025063419f5262
Partial-Bug: #1750678