6.1 Multi-Factor Authentication

Keystone currently only supports the use of a single authentication method. In certain circumstances, it may be desirable to require multiple methods of authentication to be utilized to ensure authentication requirements are satisfied. The use of multiple authentication mechanisms is typically referred to as multi-factor authentication. With multi-factor authentication, a user not only needs to provide a valid password but also must perform some other form of authentication, such as entering a personal identification number (PIN) that is sent by text message. As OpenStack and Keystone adoption continues to grow, we anticipate that there will be usage environments in which multi-factor authentication is desired.

6.2 Integration with Horizon for Multi-Region Keystone to Keystone Federation Support

Keystone to Keystone (K2K) Federation is a relatively nascent enhancement, and its ease of use increases when its capabilities are more tightly integrated into OpenStack’s dashboard (Horizon). One such opportunity for increased consumability is the addition of multi-region K2K support to Horizon. In this scenario, Horizon is enhanced to support multiple federated OpenStack regions via a pull-down list. As such, the user is provided with a relatively straightforward way of directing Horizon about which region it should be displaying without having to expose to the user the complexity of the multiple Keystones that are working together to provide support for federated regions.

6.3 Using LDAP as a Federated Identity Provider

The LDAP support described in this book uses Keystone’s driver architecture to make the users and groups in the corporate directory accessible via the Keystone API. This works well for environments where users need to be articulated through Keystone.  For companies that evolve to a federated model, there is an alternative to using LDAP that might fit better in that environment—basically to use LDAP as a pseudo-IDP. This would work by using something like the mod_lookup_identity Apache module to look up the user in LDAP, and then pass that on to Keystone. In this model, none of the LDAP users would appear in Keystone (just like in Federation), and Keystone’s Identity store would just store Groups to which these LDAP users could be mapped (using the Federation mapping capabilities described in Chapter 5).

6.4 Replacement of Service Users with X.509 Certificates and Barbican Integration

Traditionally, Keystone required the other OpenStack projects to create service user accounts as their means for interacting with and invoking operations on Keystone. The use of service accounts can add complexity to managing an OpenStack environment, as in some enterprises it can problematic to get these fictitious users added to identity-management systems such as LDAP. Moreover, this approach requires a service user password in the Keystone configuration file and a token to be issued.

As an alternative to the service user account approach, it is possible to replace service users with X.509 certificates. There are many advantages to this approach. First, it no longer requires a password. Furthermore, the approach no longer requires a token to be issued because an authorization credential can be directly created by examining the identity data in the X.509 certificate. Finally, this approach increases security for the services, as the use of X.509 certificates provides the equivalent of a non-bearer token, as the SSL client must possess the corresponding private key.

As Keystone evolves to embrace increased utilization of X.509 certificates, whether they are used to replace service users or used for federation, it will need to worry about the secure storage, provisioning, and management of the X.509 certificates. Fortunately, the mission of the OpenStack Barbican project is to provide this exact set of capabilities. Thus, in the future we anticipate greater integration between the Keystone and Barbican projects.

6.5 Centralized Policy and Distribution

In OpenStack, a key feature of many of the OpenStack services is to use a policy engine to determine access management (this is what the roles in a token are eventually used for). The policy engines rely on policy files to specify the access management policy for the different types of users and the various operations. Currently, the process of distributing these policy files throughout all the OpenStack services running across the cloud is done by operators using an out-of-band mechanism, such as a configuration-management system. Having to perform this activity with a separate tool may be seen by some as unnecessary overhead. As an alternative, Keystone may look into providing its own API for allowing services to obtain these policies directly from Keystone (along with performing associated cache management on the policies). Indeed, some basic APIs for this have been available in Keystone for a number of releases, but are not yet used by any of the services. Having this foundation in place would enable Keystone to start providing more robust policy support—for instance, a common name space across policies for different services where they could share rules. The discussions around this as to how far this support should be taken (and how the services should utilize it) are probably some of the most controversial in Keystone today—and we anticipate substantial future discussions on this topic and would like to invite the audience reading this book to participate.

6.6 Integrating with Other Technologies

In many cloud environments, the OpenStack Infrastructure-as-a-Service is typically combined with a Platform-as-a-Service environment such as IBM Bluemix, which is Cloud Foundry based. In addition, many cloud environments provide some notion of support for Container Technologies such as Docker.

In these types of environments, it is critical to keep the necessary user authentication and authorization as streamlined as possible. For example, if an enterprise customer has already performed the necessary federation to integrate Keystone with their federated identity management system they may want to avoid having to repeat this integration with Bluemix’s authentication system. Because both Bluemix and Keystone support standard federated identity protocols such as OpenId Connect, it would be fairly straightforward to ensure these to two technologies integrate together to provide a more seamless authentication and authorization environment for customers.

In a similar fashion, it may be worthwhile to investigate how Keystone’s authentication, authorization, and integration support for federated identity management systems could be utilized by Container Technologies such as Docker.