Also includes a release note. Change-Id: I72a5d461488b50f20b59d1288016514a2b8f71e5 Closes-Bug: 1816076
9.4 KiB
- tocdepth
-
3
Identity API v3 (CURRENT)
The Identity service generates authentication tokens that permit access to the OpenStack services REST APIs. Clients obtain this token and the URL endpoints for other service APIs by supplying their valid credentials to the authentication service.
Each time you make a REST API request to an OpenStack service, you supply your authentication token in the X-Auth-Token request header.
Like most OpenStack projects, OpenStack Identity protects its APIs by defining policy rules based on a role-based access control (RBAC) approach.
The Identity service configuration file sets the name and location of a JSON policy file that stores these rules.
Note that the V3 API implements HEAD for all GET requests. Each HEAD request contains the same headers and HTTP status code as the corresponding GET API.
For information about Identity API protection, see Identity API protection with role-based access control (RBAC) in the OpenStack Cloud Administrator Guide.
What's New in Version 3.14 (Ussuri)
- New attribute
authorization_ttl
for identity providers - New attribute
membership_expires_at
when listing groups for a user - Ability to persist group memberships carried through mapping for a federated user
- Added the ability to create, update and delete federated attributes for a user
What's New in Version 3.13 (Train)
- New parameter access_rules for application credentials
- New read-only API /v3/users/{user_id}/access_rules for viewing access rules
What's New in Version 3.12 (Stein)
- New optional multi-factor auth process involving auth receipts
What's New in Version 3.11 (Rocky)
- New endpoint /v3/limits-model for discovering the limit model in effect
- New description field in registered and project limits
- New project_id filters for project limits
- New parameter include_limits for project detail query
What's New in Version 3.10 (Queens)
- Introduction of the Application Credentials API.
- Introduction of an experimental Unified Limits API.
- Ability to grant system role assignments and obtain system-scoped tokens.
What's New in Version 3.9 (Queens)
- Addition of
tags
attribute to project. - New APIs to interact with the
tags
attribute.
What's New in Version 3.8 (Ocata)
- Allow a service user to fetch a token that has expired.
- Add a
password_expires_at
query parameter to user list and users in group list.
What's New in Version 3.7 (Newton)
- Addition of the
password_expires_at
field to the user response object. - Introduce a flag to bypass expiration and revocation checking.
What's New in Version 3.6 (Mitaka)
- Listing role assignments for a tree of projects.
- Setting the project
is_domain
attribute enables a project to behave as a domain. - Addition of the
is_domain
field to project scoped token response that represents whether a project is acting as a domain. - Enable or disable a subtree in the project hierarchy.
- Delete a subtree in the project hierarchy.
- Additional identifier for tokens scoped to the designated
admin project
. - Addition of
domain_id
filter to list user projects - One role can imply another via role_inference rules.
- Enhance list role assignment to optionally provide names of entities.
- The defaults for domain-specific configuration options can be retrieved.
- Assignments can be specified as inherited, causing the assignment to be placed on any sub-projects.
- Support for domain specific roles.
- Support
enabled
andid
as optional attributes to filter identity providers when listing.
What's New in Version 3.5 (Liberty)
- Addition of
type
optional attribute to list credentials. - Addition of
region_id
optional attribute to list endpoints. - Addition of
is_domain
optional attribute to projects. Setting this currently has no effect, it is reserved for future use.
What's New in Version 3.4 (Kilo)
- For tokenless authorization, the scope information may be set in the request headers.
- Addition of
parent_id
optional attribute to projects. This enables the construction of a hierarchy of projects. - Addition of domain specific configuration management for a domain entity.
- Removal of
url
optional attribute forregions
. This attribute was only used for the experimental phase of keystone-to-keystone federation and has been superseded by making service provider entries have its own entry in the service catalog. - The JSON Home support now will indicate the status of resource if it is not stable and current.
What's New in Version 3.3 (Juno)
These features are considered stable as of September 4th, 2014.
- Addition of
name
optional variable to be included from service definition into the service catalog. - Introduced a stand alone call to retrieve a service catalog.
- Introduced support for JSON Home.
- Introduced a standard call to retrieve possible project and domain scope targets for a token.
- Addition of
url
optional attribute forregions
.
What's New in Version 3.2 (Icehouse)
These features are considered stable as of January 23, 2014.
- Introduced a mechanism to opt-out from catalog information during token validation
- Introduced a region resource for constructing a hierarchical container of groups of service endpoints
- Inexact filtering is supported on string attributes
- Listing collections may indicate only a subset of the data has been provided if a particular deployment has limited the number of entries a query may return
What's New in Version 3.1 (Havana)
These features are considered stable as of July 18, 2013.
- A token without an explicit scope of authorization is issued if the user does not specify a project and does not have authorization on the project specified by their default project attribute
- Introduced a generalized call for getting role assignments, with filtering for user, group, project, domain and role
- Introduced a mechanism to opt-out from catalog information during token creation
- Added optional bind information to token structure
What's New in Version 3.0 (Grizzly)
These features are considered stable as of February 20, 2013.
- Former "Service" and "Admin" APIs (including CRUD operations previously defined in the v2 OS-KSADM extension) are consolidated into a single core API
- "Tenants" are now known as "projects"
- "Groups": a container representing a collection of users
- "Domains": a high-level container for projects, users and groups
- "Policies": a centralized repository for policy engine rule sets
- "Credentials": generic credential storage per user (e.g. EC2, PKI, SSH, etc.)
- Roles can be granted at either the domain or project level
- User, group and project names only have to be unique within their owning domain
- Retrieving your list of projects (previously
GET /tenants
) is now explicitly based on your user ID:GET /users/{user_id}/projects
- Tokens explicitly represent user+project or user+domain pairs
- Partial updates are performed using the HTTP
PATCH
method - Token ID values no longer appear in URLs
Relationships
The entries within the operations below contain a relationship link, which appears as a valid URI, however these are actually URN (Uniform Resource Name), which are similar to GUID except it uses a URI syntax so that it is easier to be read. These links do not resolve to anything valid, but exist to show a relationship.
Identity API Operations
This page lists the Identity API operations in the following order:
- Authentication and token management
- Application Credentials
- Credentials
- Domains
- Domain configuration
- Groups
- Policies
- Projects
- Project Tags
- Regions
- Roles
- System Role Assignments
- Service catalog and endpoints
- Unified Limits
- Users
- OS-INHERIT
- OS-PKI (DEPRECATED)