summaryrefslogtreecommitdiff
path: root/keystone
Commit message (Collapse)AuthorAgeFilesLines
* Fix host:port handlingstable/victoriaBence Romsics2022-09-081-2/+4
| | | | | | | | | | | | | 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 (cherry picked from commit 6c35b366e3c8c6d7f47471b93f5315582301c5ef) (cherry picked from commit d39790ac4e9dc25af09cdddc6217e36bacbc2bb1) (cherry picked from commit 0bb9cdee71805af1a7cb0a7db110b336eae5da1e) (cherry picked from commit aa50b963cce20a76db0c4834b3716d3658c784af)
* Merge "Fix issue with LDAP backend returning bytes instead of string" into ↵Zuul2022-06-081-2/+17
|\ | | | | | | stable/victoria
| * Fix issue with LDAP backend returning bytes instead of stringGrzegorz Grasza2022-02-071-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When connecting to some LDAP server software, the ldap client returns bytes instances instead of the expected strings. This can result in either being transparently converted to strings, when the data is inserted via sqlalchemy into the database, or could be used as input to other functions, and/or cached, which causes unexpected results. Closes-Bug: #1952458 Resolves: rhbz#1964872 Change-Id: I77148641715efe09e3adc2e9432e66e50fb444b4 (cherry picked from commit 1e0cd90191663c100c165d4c6a2b1ca796b5af25)
* | Update local_id limit to 255 charactersGrzegorz Grasza2022-06-077-3/+107
|/ | | | | | | | | | | | 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 (cherry picked from commit ce6031ca12156620cec214a49d162ec7bb30752f) (cherry picked from commit 2700adaadcd19baf4ee6edf9b41ff9e6e4009edc)
* Merge "Fix typos in application credential policies" into stable/victoriavictoria-em18.1.0Zuul2021-10-111-2/+2
|\
| * Fix typos in application credential policiesLance Bragstad2021-10-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We updated these policies when we introduces system scope and default roles, but the policy names accidentally changed, which makes the policy files render with an alias because oslo.policy thinks the names are changing. Conflicts: keystone/common/policies/application_credential.py in later releases the deprecated parameters were moved from the DocumentedRuleDefault object to the DeprecatedRule object, which is a non-functional change. Change-Id: I1121f1abe769ee83ffc285103a95ee95540ce727 (cherry picked from commit 60e898c47038667e66a54e0a9a6cd7b91e115f55) (cherry picked from commit 7b28f1b3b47d0e4a22afe99c64d047016a772da5) (cherry picked from commit 14d2f5944ce9ef0cc881b91463df7cf3a1114d5b)
* | Merge "Fix typos in ec2 credential policies" into stable/victoriaZuul2021-10-081-6/+6
|\ \
| * | Fix typos in ec2 credential policiesLance Bragstad2021-10-071-6/+6
| |/ | | | | | | | | | | | | | | | | | | | | There was a trailing s in two of these policies and it caused the policy names to mismatch, which causes confusion with the rendered policy files and potentially causes uses with deprecation logic. Change-Id: I54021986d17c57d7733d53caa4032c2767eaf25e (cherry picked from commit 82da8824df0f56ef4e137805bf32d647cef1ea59) (cherry picked from commit 6dff22b5baa1a19842aca435782fe1f9789f72cc) (cherry picked from commit a57ae85c9699e7a560b7ffe9786ed0a6453c1e86)
* | Fix typo in identity provider policiesLance Bragstad2021-10-071-4/+4
|/ | | | | | | | | | | | | | | This cause the sample generated policy file to alias the old name with the new policy name, which isn't needed since we're not renaming these policies at all and it was likely a typo. Conflicts: keystone/common/policies/identity_provider.py In later releases the deprecation parameters were moved up to the deprecated options and not in the DocumentedRule defaults. Change-Id: Idfd9adbbe800bbc21814d94002a2b61524cce28a (cherry picked from commit c10d5c88ef40e63d4dfefb792d6c3d68acd72dd9) (cherry picked from commit bdd8f82f60d2e46e5f6951c4407366b89591cde5)
* Hide AccountLocked exception from end usersGage Hugo2021-05-103-6/+8
| | | | | | | | | | | | | | | | This change hides the AccountLocked exception from being returned to the end user to hide sensitive information that a potential malicious person could gain insight from. The notification handler catches the AccountLocked exception as before, but after sending the audit notification, it instead bubbles up Unauthorized rather than AccountLocked. Co-Authored-By: Samuel de Medeiros Queiroz <samueldmq@gmail.com> Change-Id: Id51241989b22c52810391f3e8e1cadbf8613d873 Related-Bug: #1688137 (cherry picked from commit ac2631ae33445877094cdae796fbcdce8833a626)
* Retry update_user when sqlalchemy raises StaleDataErrorsLance Bragstad2021-03-292-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | Keystone's update_user() method in the SQL driver processes a lot of information about how to update users. This includes evaluating password logic and authentication attempts for PSI-DSS. This logic is evaluated after keystone pulls the user record from SQL and before it exits the context manager, which performs the write. When multiple clients are all updating the same user reference, it's more likely they will see an HTTP 500 because of race conditions exiting the context manager. The HTTP 500 is due to stale data when updating password expiration for old passwords, which happens when setting a new password for a user. This commit attempts to handle that case more gracefully than throwing a 500 by detecting StaleDataErrors from sqlalchemy and retrying. The identity sql backend will retry the request for clients that have stale data change from underneath them. Change-Id: I75590c20e90170ed862f46f0de7d61c7810b5c90 Closes-Bug: 1885753 (cherry picked from commit ceae3566e83b26fd6a1679154eae9b0cef29da64) (cherry picked from commit f47e635b8041542faa05e64606e66d2fbbc5f284)
* Support bytes type in generate_public_ID()Keigo Noha2021-02-032-2/+25
| | | | | | | | | | | | python-ldap3.0 or later running on python3 uses str or bytes data type according to what fields are returned. local_id may be a bytes data type. To handle it properly, mapping[key] needs to be examined for identifying its data type and what python version is used. Closes-Bug: #1901654 Change-Id: Iac097235fd31e166028c169d14ec0937c663c21c (cherry picked from commit f7df9fba828328d8b20e85d711c1d27c77089632)
* Merge "Delete system role assignments from system_assignment table" into ↵Zuul2021-01-262-0/+24
|\ | | | | | | stable/victoria
| * Delete system role assignments from system_assignment tableVishakha Agarwal2020-10-302-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch ensures to delete the system role assignments from all the assignment tables in keystone after deleting the role user has over the system. This also make sure of deleting stale role assignments before deleting role for the deployments that are already in this state. Closes-Bug: #1878938 Change-Id: I4df19c45c870ff3fb78578ca1fb7dd0d35da3c82 (cherry picked from commit c1dcbb05b4488f1fa3e7af4d9171d11702d94119) (cherry picked from commit b83170a386ba8da2195c7494d04d832ce9b6d7b0)
* | Use app cred user ID in policy enforcementLance Bragstad2021-01-082-2/+111
|/ | | | | | | | | | | | | | | | 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 (cherry picked from commit 2d7bf10a5a145ed3b6e34c3cb95e05fb7e33e0d1)
* Implement more robust connection handling for asynchronous LDAP callsLance Bragstad2020-10-021-38/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Keystone's paging implementation contains a memory leak. The issue is noticeable if you integrate keystone with an LDAP server that supports paging and set `keystone.conf [ldap] page_size` to a low integer (e.g., 5). Keystone's LDAP backend uses `python-ldap` to interact with LDAP servers. For paged requests, it uses `search_ext()`, which is an asynchronous API [0]. The server responds with a message ID, which the client uses to retrieve all data for the request. In keystone's case, the `search_ext()` method is invoked with a page control that tells the server to deliver responses in increments according to the page size configured with `keystone.conf [ldap] page_size`. So long as the client has the original connection used to fetch the message ID, it can request the rest of the information associated to the request. Keystone's paging implementation loops continuously for paged requests. It takes the message ID it gets from `search_ext()` and calls `result3()`, asking the server for the data associated with that specific message. Keystone continues to do this until the server sends an indicator that it has no more data relevant to the query (via a cookie). The `search_ext()` and `result3()` methods must use the same LDAP connection. Given the above information, keystone uses context managers to provide connections. This is relevant when deploying connection pools, where certain connections are re-used from a pool. Keystone relies on Python context managers to handle connections, which is pretty typical use-case for context managers. Connection managers allow us to do the following (assuming pseudocode): with self.get_connection as conn: response = conn.search_s() return format(response) The above snippet assumes the `get_connection` method provides a connection object and a callable that implements `search_s`. Upon exiting the `with` statement, the connection is disconnected, or put back into the pool, or whatever the implementation of the context manager decides to do. Most connections in the LDAP backend are handled in this fashion. Unfortunately, the LDAP driver is somewhat oblivious to paging, it's control implementation, or the fact that it uses an asynchronous API. Instead, the driver leaves it up to the handler objects it uses for connections to determine if the request should be controlled via paging. This is an anti-pattern since the backend establishes the connection for the request but doesn't ensure that connection is safely handled for asynchronous APIs. This forces the `search_ext()` and `result3()` implementations in the PooledLDAPHandler to know how to handle connections and context managers, since it needs to ensure the same connection is used for paged requests. The current code tried to clean up the context manager responsible for connections after the results are collected from the server using the message ID. I believe it does this because it needs to get a new connection for each message in the paged results, even though it already operates from within a connection established via a context manager and the PooledLDAPHandler almost always returns the same connection object from the pool. The code tries to use a weak reference to create a callback that tears down the context manager when nothing else references it. At a high-level, the idea is similar to the following pseudocode: with self.get_connection as conn: while True: ldap_data = [] context_manager = self.get_connection() connection = context_manager.__enter__() message_id = connection.search_ext() results = connection.result3(message_id) ldap_data.append(results) context_manager.__exit__() I wasn't able to see the callback get invoked or work as described in comments, resulting in memory bloat, especially with low page sizes which results in more requests. A weak reference invokes the callback when the weak reference is called, but there are no other references to the original object [1]. In our case, I don't think we invoke that path because we don't actually do anything with the weak reference. We assume it's going to run the callback when the object is garbage collected. This commit attempts to address this issue by using the concept of a finalizer [2], which was designed for similar cases. It also attempts to hide the cleanup implementation in the AsynchronousMessage object, so that callers don't have to worry about making sure they invoke the finalizer. An alternative approach would be to push more of the paging logic and implementation up into the LDAP driver. This would make it easier to put the entire asynchronous API flow for paging into a `with` statement and relying on the normal behavior of context managers to clean up accordingly. This approach would remove the manual cleanup invocation, regardless of using weak references or finalizer objects. However, this approach would likely require a non-trivial amount of design work to refactor the entire LDAP backend. The LDAP backend has other issues that would complicate the re-design process: - Handlers and connection are generalized to mean the same thing - Method names don't follow a convention - Domain-specific language from python-ldap bleeds into keystone's implementation (e.g., get_all, _ldap_get_all, add_member) at different points in the backend (e.g., UserApi (BaseLdap), GroupApi (BaseLdap), KeystoneLDAPHandler, PooledLDAPHandler, PythonLDAPHandler) - Backend contains dead code from when keystone supported writeable LDAP backends - Responsibility for connections and connection handling is spread across objects (BaseLdap, LDAPHandler) - Handlers will invoke methods differently based on configuration at runtime, which is a sign that the relationship between the driver, handlers, and connection objects isn't truely polymorphic While keeping the logic for properly handling context managers and connections in the Handlers might not be ideal, it is a relatively minimal fix in comparison to a re-design or backend refactor. These issues can be considered during a refactor of the LDAP backend if or when the community decides to re-design the LDAP backend. [0] https://www.python-ldap.org/en/python-ldap-3.3.0/reference/ldap.html#ldap.LDAPObject.search_ext [1] https://docs.python.org/3/library/weakref.html#weakref.ref [2] https://docs.python.org/3/library/weakref.html#finalizer-objects Closes-Bug: 1896125 Change-Id: Ia45a45ff852d0d4e3a713dae07a46d4ff8d370f3
* Merge "Spelling Fix"Zuul2020-09-141-2/+2
|\
| * Spelling FixVishakha Agarwal2020-08-061-2/+2
| | | | | | | | | | | | This Patch fixes the 'middleware' spelling. Change-Id: I6659ca49db86e5c20ecf80e4c4fff93328616eb6
* | Fix gate by running l-c job on BionicGhanshyam Mann2020-09-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | l-c job template moved the l-c jobs running on Focal and currently fails on many constraints. Let's keep running l-c job on bionic as it was before and we can move it to Focal once issues are identified and fixed. - Fixing the hacking tests which are behaving differently between < 3.8.0 (until Ubuntu Bionic) and 3.8.2 (Ubuntu Focal). Squashing below review also - https://review.opendev.org/#/c/750786/ Co-Author: Lance Bragstad <lbragstad@gmail.com> Change-Id: If733e9824d87d8c73797f753e4daf95489bed9c2
* | Write a symptom for checking memcache connectionsLance Bragstad2020-08-262-0/+82
| | | | | | | | | | | | | | | | | | This makes it easier for operators to troubleshoot connection issues to Memcached. Related-Bug: 1332058 Change-Id: I6e67363822480314b93608bb1eae3514f1480f6d
* | Merge "NIT: Spelling Fix"Zuul2020-08-251-1/+1
|\ \ | |/
| * NIT: Spelling FixVishakha Agarwal2020-08-061-1/+1
| | | | | | | | | | | | This patch fixes spelling "project" in test_sql_upgrade.py file. Change-Id: I8b1a8dbea5fb17707e59fae8605cc615f1b51f2c
* | Merge "Remove an assignment from domain and project"Zuul2020-08-252-3/+8
|\ \
| * | Remove an assignment from domain and projectVishakha Agarwal2020-06-222-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you setup a user with a role assignment on a domain and then a role assignment on a project "acting as a domain", you can't actually remove them. The database throws you the error "Multiple rows were found for one()" since it gets two results for "actor_id" with the same "target_id". This patch fixes this problem by filtering the database query by "type" field to determine whether it is a user domain relation or a user project and then removing the assignment. Change-Id: Ife92a3c9e0982baafb4224882681c0855f573580 Closes-Bug: #1754677
* | | Merge "Properly handle octet (byte) strings when converting LDAP responses"Zuul2020-08-242-1/+25
|\ \ \
| * | | Properly handle octet (byte) strings when converting LDAP responsesLance Bragstad2020-08-052-1/+25
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If LDAP returns a UUID as an octet string the LDAP driver will fail to convert it to something meaningful. The error usually looks something like: ID attribute objectGUID not found in LDAP object Microsoft AD's `objectGUID` parameter is stored and transmitted as an octet string [0]. If you attempt to use the `objectGUID` to generate user or group IDs, you'll get an HTTP 404 because keystone can't decode it properly. This is unfortunate because `objectGUID` are a fixed length, UUID format, and ideal for generating IDs in keystone. As opposed to using the object's CN, which is variable length, and can generate hashes that are larger than keystone's database table limit for user IDs. [0] https://docs.microsoft.com/en-us/windows/win32/ad/reading-an-objectampaposs-objectguid-and-creating-a-string-representation-of-the-guid Change-Id: Id80b17bdff015e10340e636102576b7435bd564f Closes-Bug: 1889936
* | | Follow-up for bug-1891244Vishakha Agarwal2020-08-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | This patch closes the review comments of [1]. [1]https://review.opendev.org/#/c/745752/ Change-Id: I06b02b2ebfed35d4e82c5fc35ce8eb0bb20b2fc5
* | | Support format for msgpack < 1.0 in token formattermelanie witt2020-08-111-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | msgpack v1.0 changed its data format [1] and during a rolling upgrade, attempts to unpack cached tokens with old data format with the new default raw=False result in the following error: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x87 in position 3: invalid start byte This passes raw=True to support backward-compat with the old format until we are guaranteed to have msgpack >= 1.0 in the N-1 release of a rolling upgrade. Closes-Bug: #1891244 [1] https://github.com/msgpack/msgpack-python/blob/v1.0.0/README.md#major-breaking-changes-in-msgpack-10 Change-Id: I6c61df6c097fef698c659c79402c4381ec7f3586
* | | Skip tests to update u-c for PyMySql to 0.10.0Vishakha Agarwal2020-08-101-0/+8
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the new version of PyMySql the error > 1000, will be operational error [1], which is failing keystone migration test cases [2] for backend mysql because we raise dberror [3] which does not handle operational error. PyMySQL hasn't been raised to 0.10.0 in the upper-constraints yet, so this patch isn't going to be able to install it. We can't raise the u-c since the current keystone jobs are failing with it. This patch overrides the test cases for backend SQL and skips the same. This is so to make sure that failed test cases are skipped because Once the upper-constraints are updated to 0.10.0 for PyMySql and merged, will revert the skip and handle for 0.10.0. [1]https://github.com/PyMySQL/PyMySQL/commit/c3e5a63514c57d1f4c9d5e7bf4b7e10b0608b0e1 [2]https://da7bb9864083b9045f13-6176f3344d2541229da3be8329641f28.ssl.cf5.rackcdn.com/741837/2/check/cross-keystone-py36/d1a2e73/testr_results.html [3]https://github.com/openstack/keystone/blob/033e7aff870f2ccd4dec607e9c47efff630ece29/keystone/tests/unit/test_sql_upgrade.py#L1867 Related-Bug: #1890325 Change-Id: I207bb816affcb3e2725321de9a90a40c027a9f87
* | Merge "Stop to use the __future__ module."Zuul2020-07-316-12/+0
|\ \
| * | Stop to use the __future__ module.Hervé Beraud2020-06-026-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The __future__ module [1] was used in this context to ensure compatibility between python 2 and python 3. We previously dropped the support of python 2.7 [2] and now we only support python 3 so we don't need to continue to use this module and the imports listed below. Imports commonly used and their related PEPs: - `division` is related to PEP 238 [3] - `print_function` is related to PEP 3105 [4] - `unicode_literals` is related to PEP 3112 [5] - `with_statement` is related to PEP 343 [6] - `absolute_import` is related to PEP 328 [7] [1] https://docs.python.org/3/library/__future__.html [2] https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html [3] https://www.python.org/dev/peps/pep-0238 [4] https://www.python.org/dev/peps/pep-3105 [5] https://www.python.org/dev/peps/pep-3112 [6] https://www.python.org/dev/peps/pep-0343 [7] https://www.python.org/dev/peps/pep-0328 Change-Id: I2f9d2114b2c5eb66f241646f1896ea17a160e3f3
* | | Merge "Fix invalid assertTrue which should be assertEqual"Zuul2020-07-311-1/+1
|\ \ \
| * | | Fix invalid assertTrue which should be assertEqualzhufl2020-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | self.assertTrue(len(user['federated']), 1) should be self.assertEqual(len(user['federated']), 1). Change-Id: If6bdfb074cb68271e69f8436111149d3aa312e6d
* | | | Merge "Fix "allow expired" feature for JWT"Zuul2020-07-292-3/+22
|\ \ \ \ | |/ / / |/| | |
| * | | Fix "allow expired" feature for JWTVishakha Agarwal2020-07-082-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GET /v3/auth/tokens?allow_expired=1 works fine with fernet tokens returning the expired token data, whereas it returns exception TokenNotFound for JWT. This patch fixes the same. Change-Id: I03f6c58dce7d140d62055a97063aeb480498e5e6 Closes-Bug: #1886017
* | | | Merge "Support regexes in whitelists/blacklists"Zuul2020-07-163-23/+144
|\ \ \ \
| * | | | Support regexes in whitelists/blacklistsJason Anderson2020-05-263-23/+144
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Merge "Add ignore_user_inactivity user option"Zuul2020-07-153-1/+50
|\ \ \ \ | |_|/ / |/| | |
| * | | Add ignore_user_inactivity user optionPavlo Shchelokovskyy2020-07-073-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Merge "NIT: Fix Spelling in auth_context.py"Zuul2020-07-021-1/+1
|\ \ \ \ | |/ / / |/| | |
| * | | NIT: Fix Spelling in auth_context.pyVishakha Agarwal2020-06-011-1/+1
| | | | | | | | | | | | | | | | Change-Id: I83bd63e9f576041ffdb995fe441f1a3b0b371db2
* | | | Merge "New config option 'user_limit' in credentials"Zuul2020-06-234-1/+37
|\ \ \ \
| * | | | New config option 'user_limit' in credentialsVishakha Agarwal2020-06-124-1/+37
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch allows adds new config option 'user_limit' to credentials to set maximum number of credentials a user is permitted to create. Closes-Bug: #1872732 Change-Id: Ic9dc9a4a9ec1ecbf01842c865e19a7a100e5041d
* | | | Merge "ldap: fix config option docs for *_tree_dn"Zuul2020-06-221-2/+4
|\ \ \ \ | |_|_|/ |/| | |
| * | | ldap: fix config option docs for *_tree_dnMohammed Naser2020-06-101-2/+4
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The user_tree_dn and group_tree_dn configurations claim that they use the value for prefix as-is, when they don't, as they get DEFAULT_OU appended[1] which is different depending on the resource[2][3]. To all the future people who will save countless hours, you're all welcome <3 [1]: https://opendev.org/openstack/keystone/src/commit/4530041931ff23b6d7347000d59703093f7d657a/keystone/identity/backends/ldap/common.py#L1148 [2]: https://opendev.org/openstack/keystone/src/commit/4530041931ff23b6d7347000d59703093f7d657a/keystone/identity/backends/ldap/core.py#L236 [3]: https://opendev.org/openstack/keystone/src/commit/4530041931ff23b6d7347000d59703093f7d657a/keystone/identity/backends/ldap/core.py#L357 Change-Id: Id14bc7d9770188c242f809752624f683fe3a6d7b
* | | Imported Translations from ZanataOpenStack Proposal Bot2020-06-191-2/+9
| | | | | | | | | | | | | | | | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: I8910eccab6d14c2ce6b6496b18b4987aff64fc9b
* | | Merge "Disable EC2 credentials access_id update"Zuul2020-06-182-1/+30
|\ \ \ | |/ / |/| |
| * | Disable EC2 credentials access_id updateVishakha Agarwal2020-05-192-1/+30
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this patch user can alter EC2 credential access_id and user cannot use it anymore as an ec2 auth token since EC2 credential access ID is used to calculate an ID of the "credential" [1] and it doesn't update the EC2 credential ID with new access ID. This leads to unwanted EC2 credentials stored in database. As per the discussion of keystone team [2] we decided to block patching of "access_id" attribute. [1] https://github.com/openstack/keystone/blob/7bb6314e40d6947294260324e84a58de191f8609/keystone/api/users.py#L363 [2]http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2020-05-12.log.html#t2020-05-12T17:45:20 Closes-Bug: #1872753 Change-Id: I1f6ce3927c2881d9a2d7dcda3ccd29e0a82e45a9
* | Fix UserNotFound exception for expiring groupsColleen Murphy2020-05-101-1/+1
|/ | | | | | | | | | | | | | Without this patch, if this exception is reached, it won't be properly formed and will result in a log message like this: Failed to insert replacement values into translated message Could not find user: %(user_id)s. (Original: 'Could not find user: %(user_id)s.'): 'user_id' This patch adds the right parameters to ensure the exception properly logs the user ID and the translation doesn't fail. Change-Id: I3229d9a237633cda8f6a25f396a75b8310757d9d
* Fix security issues with EC2 credentialsColleen Murphy2020-05-025-59/+537
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
View Lorry Controller Status