Workflow Logic the Assignment service.
keystone.assignment.controllers.
GrantAssignmentV3
[source]¶Bases: keystone.common.controller.V3Controller
The V3 Grant Assignment APIs.
check_grant
(request, *args, **kwargs)[source]¶Check if a role has been granted on either a domain or project.
collection_name
= 'roles'¶create_grant
(request, *args, **kwargs)[source]¶Grant a role to a user or group on either a domain or project.
list_grants
(request, *args, **kwargs)[source]¶List roles granted to user/group on either a domain or project.
member_name
= 'role'¶keystone.assignment.controllers.
ImpliedRolesV3
(*args, **kwargs)[source]¶Bases: keystone.common.controller.V3Controller
The V3 ImpliedRoles CRD APIs. There is no Update.
keystone.assignment.controllers.
ProjectAssignmentV3
[source]¶Bases: keystone.common.controller.V3Controller
The V3 Project APIs that are processing assignments.
collection_name
= 'projects'¶member_name
= 'project'¶keystone.assignment.controllers.
Role
(*args, **kwargs)[source]¶Bases: keystone.common.controller.V2Controller
The Role management APIs.
keystone.assignment.controllers.
RoleAssignmentV2
(*args, **kwargs)[source]¶Bases: keystone.common.controller.V2Controller
The V2 Role APIs that are processing assignments.
add_role_to_user
(*args, **kwargs)[source]¶Add a role to a user and tenant pair.
Since we’re trying to ignore the idea of user-only roles we’re not implementing them in hopes that the idea will die off.
create_role_ref
(*args, **kwargs)[source]¶Used for adding a user to a tenant.
In the legacy data model adding a user to a tenant required setting a role.
delete_role_ref
(*args, **kwargs)[source]¶Used for deleting a user from a tenant.
In the legacy data model removing a user from a tenant required deleting a role.
To emulate this, we encode the tenant and role in the role_ref_id, and if this happens to be the last role for the user-tenant pair, we remove the user from the tenant.
get_role_refs
(*args, **kwargs)[source]¶Ultimate hack to get around having to make role_refs first-class.
This will basically iterate over the various roles the user has in all tenants the user is a member of and create fake role_refs where the id encodes the user-tenant-role information so we can look up the appropriate data when we need to delete them.
keystone.assignment.controllers.
RoleAssignmentV3
(*args, **kwargs)[source]¶Bases: keystone.common.controller.V3Controller
The V3 Role Assignment APIs, really just list_role_assignment().
collection_name
= 'role_assignments'¶list_role_assignments_wrapper
(request)[source]¶Main entry point from router for list role assignments.
Since we want different policy file rules to be applicable based on whether there the include_subtree query parameter is part of the API call, this method checks for this and then calls the appropriate protected entry point.
member_name
= 'role_assignment'¶keystone.assignment.controllers.
RoleV3
[source]¶Bases: keystone.common.controller.V3Controller
The V3 Role CRUD APIs.
To ease complexity (and hence risk) in writing the policy rules for the role APIs, we create separate policy actions for roles that are domain specific, as opposed to those that are global. In order to achieve this each of the role API methods has a wrapper method that checks to see if the role is global or domain specific.
NOTE (henry-nash): If this separate global vs scoped policy action pattern becomes repeated for other entities, we should consider encapsulating this into a specialized router class.
collection_name
= 'roles'¶member_name
= 'role'¶keystone.assignment.controllers.
TenantAssignment
(*args, **kwargs)[source]¶Bases: keystone.common.controller.V2Controller
The V2 Project APIs that are processing assignments.
Main entry point into the Assignment service.
keystone.assignment.core.
Manager
(*args, **kwargs)[source]¶Bases: keystone.common.manager.Manager
Default pivot point for the Assignment backend.
See keystone.common.manager.Manager
for more details on how this
dynamically calls the backend.
add_implied_roles
(*args, **kwargs)[source]¶Expand out implied roles.
The role_refs passed in have had all inheritance and group assignments expanded out. We now need to look at the role_id in each ref and see if it is a prior role for some implied roles. If it is, then we need to duplicate that ref, one for each implied role. We store the prior role in the indirect dict that is part of such a duplicated ref, so that a caller can determine where the assignment came from.
add_user_to_project
(*args, **kwargs)[source]¶Add user to a tenant by creating a default role relationship.
Raises: |
|
---|
driver_namespace
= 'keystone.assignment'¶get_roles_for_groups
(*args, **kwargs)[source]¶Get a list of roles for this group on domain and/or project.
get_roles_for_user_and_domain
(*args, **kwargs)[source]¶Get the roles associated with a user within given domain.
Returns: | a list of role ids. |
---|---|
Raises: | keystone.exception.DomainNotFound – If the domain doesn’t exist. |
get_roles_for_user_and_project
(*args, **kwargs)[source]¶Get the roles associated with a user within given project.
This includes roles directly assigned to the user on the project, as well as those by virtue of group membership or inheritance.
Returns: | a list of role ids. |
---|---|
Raises: | keystone.exception.ProjectNotFound – If the project doesn’t exist. |
list_role_assignments
(*args, **kwargs)[source]¶List role assignments, honoring effective mode and provided filters.
Returns a list of role assignments, where their attributes match the provided filters (role_id, user_id, group_id, domain_id, project_id and inherited). If include_subtree is True, then assignments on all descendants of the project specified by project_id are also included. The inherited filter defaults to None, meaning to get both non-inherited and inherited role assignments.
If effective mode is specified, this means that rather than simply return the assignments that match the filters, any group or inheritance assignments will be expanded. Group assignments will become assignments for all the users in that group, and inherited assignments will be shown on the projects below the assignment point. Think of effective mode as being the list of assignments that actually affect a user, for example the roles that would be placed in a token.
If include_names is set to true the entities’ names are returned in addition to their id’s.
source_from_group_ids is a list of group IDs and, if specified, then only those assignments that are derived from membership of these groups are considered, and any such assignments will not be expanded into their user membership assignments. This is different to a group filter of the resulting list, instead being a restriction on which assignments should be considered before expansion of inheritance. This option is only used internally (i.e. it is not exposed at the API level) and is only supported in effective mode (since in regular mode there is no difference between this and a group filter, other than it is a list of groups).
In effective mode, any domain specific roles are usually stripped from the returned assignments (since such roles are not placed in tokens). This stripping can be disabled by specifying strip_domain_roles=False, which is useful for internal calls like trusts which need to examine the full set of roles.
remove_user_from_project
(*args, **kwargs)[source]¶Remove user from a tenant.
Raises: |
|
---|
keystone.assignment.core.
RoleManager
(*args, **kwargs)[source]¶Bases: keystone.common.manager.Manager
Default pivot point for the Role backend.
driver_namespace
= 'keystone.role'¶WSGI Routers for the Assignment service.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.