Keystone/IdentityProvidersServiceCatalog

Introduction

This document outlines proposed changes to the Keystone Service Catalog to  add Identity Providers to the supported services. We will use examples from the SQL backend option but the added support should be independent  of the actual backend used. It will outline the current design and then describe the proposed design. Identity Providers as services require a few more details to be stored in the Keystone database but the  capability is already there to add these without modifying the service  catalog API. Finally, the changes required to achieve the proposed design will be described.

Current Design
The current service stores information about services in a database  backend. In the SQL backend the data is stored in two tables, service and endpoint. Endpoint has a foreign key ‘service-id’ to the service relation. Endpoint information such as the associated URLS is stored in the extra field of the endpoint table (see figure 1). The contents of this field is in a JsonBlob format which is parsed to a JSON array and  added to the response with its associated service or endpoint when a  request is made to the catalog API for access to one of these.



Figure 1

Proposed Design
The proposed design would make use of the fact that the capability exists  in Keystone to store extra data about an endpoint. We define a new type of service, an Identity Provider (IdP), so that additional information  for the IdP can be stored alongside the URL data (see Figure 2). As such no changes are required to the keystone service itself, as the extra  parameters would be automatically appended to the response. This means the onus is on clients or middleware using the catalog to handle the  extra parameters if desired.



Figure 2

Required Modifications
As mentioned previously no changes to the Keystone service would be  required to store and retrieve the extra data. However, the Keystone Client would have to be modified to allow administrators to specify the  additional information when creating an endpoint. We also propose a change of semantic to the type field, so that it can be encoded as. which will provide flexibility in the future, and allow clients to request all services of a particular type  or subtype.

We specify a new type of service, called “IDP.SAML”, which is of type IDP  and subtype SAML. This requires the following arguments to be added to the endpoint-create function:

·      --certdata – the identity provider certificate data for signing and verification.

·      (optional) –display-name – the name to present to users when offering this IdP as a choice for authentication.

The entity ID of the identity provider would be stored in the name field of  the service data and as such would require no modifications to support.