Jump to: navigation, search

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 <type>.<subtype> 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.

Version Date Author(s)
0.1 14/11/2012 Kristy
0.2 16 November 2012 David
0.3 17 November Kristy
0.4 19 November 2012 David