Identity Service in Keystone- OpenStack Tutorial

As I have mentioned in my previous blog, in the next blog we will cover remaining topics related to the Keystone like its identity service and different types of identity backends. We will also be discussing the capabilities of authentication and authorization of keystone.

As mentioned earlier, Actors are provided by the Identity Service. From various locations, these identities present in the cloud come but they are not restricted to SQL, Associated Identity Providers and LDAP.

Let’s discuss these in detail one by one:

1.       SQL

As we have already discussed, Keystone consists of various options for storing actors i.e. users and groups and one of them is the SQL, which provides support through databases that involve MySQL, PostgreSQL, and DB2. The configuration file of the Keystone should contain the settings for the databases, as it also stores the information like name, password as well as the description. For enterprise customers, Keystone acting as an Identity Provider is not considered as the best condition.

There are some advantages and disadvantages of utilizing SQL identity option.

Advantages of utilizing SQL identity option:

1.      Easily setup.

2.      OpenStack APIs are used for managing the users and the user groups.

Disadvantages of utilizing SQL identity option:

1. As discussed earlier the identity provider should not be Keystone.
2. Provides support to the weak password.
3. Not possible to rotate the password.
4. Not possible to recover the password.
5. The LDAP server is present in most of the enterprises and they also want to use it.
6. Users should remember another username and password due to the identity silo.

2.       LDAP:

It is possible for the Keystone to revoke as well as store the users and the user groups in Lightweight Directory Access Protocol because Keystone can fetch the LDAP in the similar way some other applications use it like Email, logging in to system and web applications.

As mentioned earlier, the settings required for connecting to the LDAP are mentioned in the configuration file of the Keystone. This file also contains the information that, it is possible for the Keystone to write to the LDAP or whether it can only read the LDAP data. Preferably it is considered that LDAP should execute the read operations only like user and the user group lookup through search and also the authentication through bind.

Keystone requires fewer amounts of privileges for using the LDAP if LDAP is used only as a read-only identity backend. For example, The Keystone requires the read privilege for the user and the user group attributes which are specified in the Keystone’s configuration file i.e. keystone.conf, it also requires anonymous access i.e. an unprivileged account and the access to the password hashes is not required for the Keystone.

LDAP identity option also has some advantages and disadvantages as mentioned below:

Advantages:

1. It is not required to retain the copies of the user accounts.
2. It is required that the keystone should not work as an Identity Provider.

Disadvantages:

1. It is required to store the service accounts somewhere and it may happen that the admin of the LDAP may not want to store these service accounts in the LDAP.
2. As the passwords are in the authentication request, Keystone can only be able to see these passwords of the users. But preferably it is found that the Keystone never wants to see the user’s password at any point and it only forwards those requests.

3.      Multiple Identity Backends:

The multiple identity backends for the V3 Identity API are supported by the Keystone due to which an arrangement can have only one backend or the identity source for each keystone domain. SQL backend is the default domain and it is normally used for host service accounts, which are the accounts that are used by different OpenStack services for interacting with the Keystone.

It is possible to host different additional LDAP backend in their personal domain. The inspiration behind supporting multiple identity backends is that the LDAP administrators could not be the same organization like the OpenStack deployment team in an enterprise setting, therefore, constructing service accounts in the LDAP is mostly unexpected.

It is found that LDAP is mostly limited to be used just for employee information. It is now possible to use multiple LDAPs due to the advantage of a systematical separation between domain and the identity backends. Therefore in the situation of a company merger or if the different LDAPs are used by the different departments then also it will represent the same enterprise.

Following are the advantages and the disadvantages of the multiple identity backends:

Advantages:

1. It is capable of supporting multiple LDAPs for different user accounts and also for the SQL backends for the service accounts at the same time.
2. It will not affect the present identity LDAP.

Disadvantages:

1. A little bit more complex to setup.
2. The verification of the user accounts should be domain inspected.

4. Identity Providers:

For more than one dependable identity providers it is possible for the Keystone to use up associated authentication through Apache modules. Keystone stores these users and these users are treated as temporary. The users who are associated, their attributes are linked into role assignments which are group based. If considered from the point of view of the Keystone, an identity provider is an origin of identities which may direct to the software which is supported by different backends like MongoDB, LDAP, etc. or by different Social media logins like Facebook, Twitter, etc.

Especially, an Identity provider is software, for example, Tivoli Federated Identity Manager by IBM, which extracts the backends and converts the different attributes of the user into the format of a commonly associated identity protocol like SAML, etc. This connects very well with the Keystone’s higher plan of offloading the authentication and related to the identity parts of a service which previously carries out in an enterprise.

The identity provider approach offers many advantages and minimum disadvantages. These are as follows:

 Advantages:

1. The identity provider is capable of influencing current configuration and software for authenticating the users and revoking the data about the users.
2. Additionally the split between Keystone and managing the identity details.
3. It gives a boost for the latest opportunities in the associated areas like just one sign on and also the hybrid cloud.
4. As mentioned earlier Keystone never ever sees any of the user passwords.
5. An identity provider is capable of handling entire authentication therefore even if it is a password or certificate or based on two factors, it is not related to the Keystone.

Disadvantages:

1. The setup of identity sources is extremely complex.

Authentication of Keystone:

As mentioned earlier, for authenticating with the Keystone service, different ways are used and undoubtedly there are two most popular ways are:

1. providing the password and

2. with the help of token.

Here we are emphasizing these two ways of authentication with the help of presenting the data needed in a Keystones’ POST request and also their normal movement between the user, Keystone, and additional OpenStack services.

• By providing Password:

Providing a password is the most popular method used by a user or a service for authentication. Below we have shown a payload which is just an example POST request to the Keystone. This information is about the complete payload which will be useful to the readers so that they will identify the information which is required for authentication.

Information about the payload, and domains:

It is important to remember that the payload related to the request should consist of sufficient information to locate where does the user exists, how to authenticate the user and alternatively, on the basis of the user’s permissions based on the project revoke the service catalog.

The succeeding user must have domain related information like either the domain name or the ID so that the user section will identify him, or the users’ widely distinct ID can be used in this scenario which is enough for identifying the user. It is allowed because, in more than one domain installment, it may be possible that there is more than one user with similar names, so appropriate observation is required to check which user is authenticated.

As mentioned already, the scope section is optional but still, it is used often because a user will not be capable of retrieving a service catalog without the scope and it also represents which project the user wants to work up against. The request gets rejected if the user doesn’t have any role on that specific project.

Same as the user section, the scope section should have sufficient information regarding the project for identifying it therefore also the differences throughout the domain. Also, we have already seen that the project ID is always unique and if that is specified then the domain information is not required.

• Token:

Same as above, it is possible for a user to request a new token by allotting the existing token. As compared to the password equivalent, the payload of token POST request involves minimum code. Different reasons are there for why a token would be used for revoking another like if a token will soon expire then it needs to be refreshed or for changing an unscoped token into a scoped token.

Authorization:

One of the important reasons for Keystone being important to the OpenStack is controlling access and authorizing which APIs can be used by a user. How the Keystone deals with this problem are by creating an RBAC i.e. Role-based Access Control policy which is being imposed on every endpoint of public API. A file named policy.json stores these RBAC policies on the disk.

Let’s better understand this concept, with an example:

The following is an example of Keystone’s policy.json file, which is composed of the targets and rules:

The left-hand key is referred to as a target and the right-hand value is referred to rules. The targets are stated at the top of the file which is used for estimation of different targets and here only we describe what is an admin, an owner or anyone.

The rule that controls the API starts with “identity:” and states a secured controller.

For securing the new targets, we take help of already setup targets.

We use the already established targets to protect the new targets. It is necessary to know the minute difference between categorizing all the projects and categorizing only a user’ projects i.e. categorizing all projects must be an admin only operation and the policy associated with it is written as per that. Categorizing all the projects a user has permission to, must not be limited only to the admins, but also to the user which has a role related to that project.

• Different Identity Backends and services:

The identity backends and services are summarized in the following picture, in which the green part denotes the backends which are normally SQL, the pink part indicates backends which are normally LDAP or SQL, the blue part indicates SQL or Memcache and at last, the policy is served from a file. These are the most popularly used Keystone services, regardless of these services, there are some other Keystone services.

Also read:-