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
Section "OpenID Connect with keystone and horizon"
should use openid endpoint instead of saml2.
Change-Id: I147f3888c42e2d8d25a0ddd20f4e3974c8a38632
Signed-off-by: Arvid Requate <requate@univention.de>
This patch provides Keystone documents for OAuth2.0 client
authorization. The specification about new API is added to API
Reference. Also OAuth2.0 client credentials grant flow is added to
admin guide.
Implement: blueprint oauth2-client-credentials-ext
Change-Id: I6ac5835fb64a4e81f34f7b8631d255b2bb7f66da
Since LDAP is now readonly, the current behavior might be
unexpected. By randomizing the list, we assure a more gradual
failure scenario if the first server on the list (as specified
by the user) fails.
Change-Id: I23f31bd85443784013a6aa158d80c7aeeb343993
Closes-Bug: #1953622
Resolves: rhbz#2024602
This avoids the "String length exceeded." error, when using LDAP
domain specific backend in case the user uses a user id
attribute, which can exceed the previous constraint of 64 chars.
Change-Id: I923a2a2a5e79c8f265ff436e96258288dddb867b
Closes-Bug: #1929066
Resolves: rhbz#1959345
After reading through the documentation, I thought this sentence sounded
funny using 'within' and 'in' so close to each other. I updated it so
that it isn't quite so jarring.
Change-Id: I2619108216035a37823e53efb5a3f9fe6cfe5cbb
This commit updates the documentation for service api protection to
better describe the overall personas for system, domain, and project
users. It also adds some examples that show operators how to list users
with all role assignments on a particular target, which include a
superset of the existing examples.
Change-Id: I40dd33fc0afa0240c6b1cd48322fd988fc5524af
The secure RBAC work propogating throughout the community has led to
some interesting discussions about how to implement support for
``reader``. Specifically, should ``reader`` be used for auditing
deployments?
Some compliance targets, verified by third-party auditors, require
access to sensitive information (e.g., thinking about license keys in
glance images or volume type encryption metadata in cinder). The concern
raised among developers updating their default policies to use
``reader`` roles is if they should be using that role to protect
sensitive information, especially if it's the least-authoritative role
in the hierarchy between reader, member, and admin.
This documentation is supposed to assist deployers in understanding the
various personas that developers are implementing by default, but it
doesn't call out the complicated relationship we have with ``reader``
and auditing.
The change here proposes that we explicitly say that ``reader``
shouldn't be used to protect sensitive information, regardless of the
scope, because ``reader`` was designed to be the least-authoritative
role provided by keystone, by default. Instead, service developers
working to implement these personas consistently in other services
should keep sensitive information, if applicable to their API or
resources, at the ``admin`` tier of the hierarchy. This provides better
protection of sensitive information by not exposing is implicitly.
We can consider supporting a formal default role for auditing in the
future, but building it outside the default implied role tree so that
it's not implied to anyone with a role assignment. This will come at
another time and we can use implied roles to re-use all the work we've
done across OpenStack to implement support for ``reader``.
For now, ``reader`` should be viewed from the perspective of the
least-authoritative permissions grant-able to a given scope (e.g.,
system, domain, or project). Even if ``reader`` has limited use in
auditing deployments, it's still incredibly useful for operators
because they have a role they can grant to users with minimal trust, or
minimal permissions in the deployment.
This commit acknowledges the use-case for an elevated auditor role and
that it's something we can implement as a formal role in keystone in the
future.
Change-Id: Iea28faf1b3e63c7ab07e90808d2bc76ee3ee0612
As per the community goal of migrating the policy file
the format from JSON to YAML[1], we need to do two things:
1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.
2. Deprecate the JSON formatted policy file on the project side
via warning in doc and releasenotes.
Also replace policy.json to policy.yaml ref from doc and tests.
[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Change-Id: Ic65d2fd6ce7215b4a47a6fb41b9cbf991f27773b
In queens we added support for `keystone-manage bootstrap` to
populate a system admin role assignment:
I6b7196a28867d9a699716c8fef2609d608a5b2a2
The end-user/deployer facing documentation doesn't mention this though
and it should because it ensures deployers have a user for system-level
APIs.
Change-Id: I07616c1470cd89130250cc89635a508f48c2be06
this option allows to override the
[security_compliance]disable_user_account_days_inactive setting from
config on per-user basis.
Co-Authored-By: Vishakha Agarwal <agarwalvishakha18@gmail.com>
Change-Id: Ida360e215426184195687bee2a800877af33af04
Closes-Bug: #1827431
When we create a project, using a project scoped token,
without add the domain_id or domain information in the
project creation parameters, this project will be
automatically created on the default domain.
Change-Id: Ib7a2d47c2204b0639f029c3079f4fa86ee78e3a9
We often have operators ask why cache logging isn't included in their
logs despite setting `keystone.conf [DEFAULT] debug=True`. This is
because cache logging requires additional configuration that isn't
obvious unless your familiar with oslo.cache and dogpile already.
This commit adds a section to the caching guide that shows people how to
update their configuration files when they need to debug caching issues.
Change-Id: I33d37366ea9caf320f3738db637dea7386ff6448
This adds support for the "regex" flag for both the "whitelist" and
"blacklist" conditional types. Before, only the "any_one_of" and
"not_any_of" conditionals supported this. Similar to the pre-existing
regex logic, the patterns are matched from the beginning of the string,
meaning you may need prefix them with ".*" if you do not care about the
first characters of the match.
Closes-Bug: #1880252
Change-Id: Ia51f47a58712c7230753f2cfa0c87b83a7339bf9
This patch removes about controller and replaces it with API. It
also add some links to the details mentioned in doc.
Change-Id: I558e6db1e0e920a5a22c1708e35553f1af678476
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
Roles, projects, and domains can accept "immutable" as a resource
option. This change explains the option in the admin guide and updates
the API reference to mention it.
Change-Id: I95926927472f6418f97a08fea0ebd56da04ce7a5
Related-bug: #1823258
Add a note to the ``keystone-manage bootstrap`` documentation about the
behavior of immutable roles.
Change-Id: I1cdbdc8668ed4312660ec269c40e1259517b327c
Depends-on: https://review.opendev.org/705859
This is to fix the duplicated words issue like
"one for each each user_id in the provided group_id".
Change-Id: Iacb8e713253288d203834355f1de12482c2c029e
Rafael Weingärtner