keystone.identity.core module¶

Main entry point into the Identity service.

class keystone.identity.core.DomainConfigs[source]¶

Bases: keystone.common.provider_api.ProviderAPIMixin, dict

Discover, store and provide access to domain specific configs.

The setup_domain_drivers() call will be made via the wrapper from the first call to any driver function handled by this manager.

Domain specific configurations are only supported for the identity backend and the individual configurations are either specified in the resource database or in individual domain configuration files, depending on the setting of the ‘domain_configurations_from_database’ config option.

The result will be that for each domain with a specific configuration, this class will hold a reference to a ConfigOpts and driver object that the identity manager and driver can use.

check_config_and_reload_domain_driver_if_required(domain_id)[source]¶

Check for, and load, any new domain specific config for this domain.

This is only supported for the database-stored domain specific configuration.

When the domain specific drivers were set up, we stored away the specific config for this domain that was available at that time. So we now read the current version and compare. While this might seem somewhat inefficient, the sensitive config call is cached, so should be light weight. More importantly, when the cache timeout is reached, we will get any config that has been updated from any other keystone process.

This cache-timeout approach works for both multi-process and multi-threaded keystone configurations. In multi-threaded configurations, even though we might remove a driver object (that could be in use by another thread), this won’t actually be thrown away until all references to it have been broken. When that other thread is released back and is restarted with another command to process, next time it accesses the driver it will pickup the new one.

configured = False¶

driver = None¶

get_domain_conf(domain_id)[source]¶

get_domain_driver(domain_id)[source]¶

lock = <thread.lock object>¶

reload_domain_driver(domain_id)[source]¶

setup_domain_drivers(standard_driver, resource_api)[source]¶

class keystone.identity.core.Manager(*args, **kwargs)[source]¶

Bases: keystone.common.manager.Manager

Default pivot point for the Identity backend.

See keystone.common.manager.Manager for more details on how this dynamically calls the backend.

This class also handles the support of domain specific backends, by using the DomainConfigs class. The setup call for DomainConfigs is called from with the @domains_configured wrapper in a lazy loading fashion to get around the fact that we can’t satisfy the assignment api it needs from within our __init__() function since the assignment driver is not itself yet initialized.

Each of the identity calls are pre-processed here to choose, based on domain, which of the drivers should be called. The non-domain-specific driver is still in place, and is used if there is no specific driver for the domain in question (or we are not using multiple domain drivers).

Starting with Juno, in order to be able to obtain the domain from just an ID being presented as part of an API call, a public ID to domain and local ID mapping is maintained. This mapping also allows for the local ID of drivers that do not provide simple UUIDs (such as LDAP) to be referenced via a public facing ID. The mapping itself is automatically generated as entities are accessed via the driver.

This mapping is only used when: - the entity is being handled by anything other than the default driver, or - the entity is being handled by the default LDAP driver and backward compatible IDs are not required.

This means that in the standard case of a single SQL backend or the default settings of a single LDAP backend (since backward compatible IDs is set to True by default), no mapping is used. An alternative approach would be to always use the mapping table, but in the cases where we don’t need it to make the public and local IDs the same. It is felt that not using the mapping by default is a more prudent way to introduce this functionality.

add_user_to_group(**kwargs)[source]¶

assert_user_enabled(**kwargs)[source]¶

Assert the user and the user’s domain are enabled.

:raise AssertionError if the user or the user’s domain is disabled.

authenticate(**kwargs)[source]¶

change_password(**kwargs)[source]¶

check_user_in_group(**kwargs)[source]¶

create_group(**kwargs)[source]¶

create_user(**kwargs)[source]¶

delete_group(**kwargs)[source]¶

delete_user(**kwargs)[source]¶

driver_namespace = 'keystone.identity'¶

get_group(**kwargs)[source]¶

get_group_by_name(**kwargs)[source]¶

get_user(**kwargs)[source]¶

get_user_by_name(**kwargs)[source]¶

list_groups(**kwargs)[source]¶

list_groups_for_user(**kwargs)[source]¶

list_users(**kwargs)[source]¶

list_users_in_group(**kwargs)[source]¶

remove_user_from_group(**kwargs)[source]¶

shadow_federated_user(**kwargs)[source]¶

Map a federated user to a user.

Parameters:	idp_id – identity provider id protocol_id – protocol id unique_id – unique id for the user within the IdP display_name – user’s display name email – user’s email
Returns:	dictionary of the mapped User entity

update_group(**kwargs)[source]¶

update_user(**kwargs)[source]¶

class keystone.identity.core.MappingManager[source]¶

Bases: keystone.common.manager.Manager

Default pivot point for the ID Mapping backend.

create_id_mapping(**kwargs)[source]¶

delete_id_mapping(**kwargs)[source]¶

driver_namespace = 'keystone.identity.id_mapping'¶

get_id_mapping(**kwargs)[source]¶

get_public_id(**kwargs)[source]¶

purge_mappings(**kwargs)[source]¶

class keystone.identity.core.ShadowUsersManager[source]¶

Bases: keystone.common.manager.Manager

Default pivot point for the Shadow Users backend.

driver_namespace = 'keystone.identity.shadow_users'¶

keystone.identity.core.domains_configured(f)[source]¶

Wrap API calls to lazy load domain configs after init.

This is required since the assignment manager needs to be initialized before this manager, and yet this manager’s init wants to be able to make assignment calls (to build the domain configs). So instead, we check if the domains have been initialized on entry to each call, and if requires load them,

keystone.identity.core.exception_translated(exception_type)[source]¶

Wrap API calls to map to correct exception.