Difference between revisions of "Peer2PeerKeystones"

Revision as of 16:50, 6 June 2014

Peer-to-Peer Keystones

or

P2P Support for Virtual Organizations (or Virtual Projects)

Goal: Enable one Keystone to "import" services from other Keystones, i.e., federate at the service level.

Premise: In a completely general deployment, Federated Identity Management (FIM) would have to be done on the "front-end". This blueprint assumes that identity has been established (say by the Kent approach), and focuses on Federated Resource Management at the service level.

Premise: A Virtual Organization (VO) can be considered a general security and collaboration context that is not "owned" by any one organization. (This could alternatively be called a Virtual Project, but we will stick with the "VO" terminology for now.) A VO could be used to manage access to application-level services, as well as OpenStack infrastructure services. For this blueprint, support for all service types is possible. Whether the same service catalog is used for both service types, or whether two separate service catalogs are used is a design decision that is not considered here.

Premise: A VO Management Service (VOMS) can be implemented in a centralized or distributed manner. KeyVOMS (ext ref needed) is an example of a centralized, external, third-party VOMS. (KeyVOMS is separate instance of Keystone v3 that was re-purposed to function as a VOMS). If we want to have a VO capability "completely within" Keystone (rather than using an external, third-party), then we must examine what a peer-to-peer Keystone VOMS would require. Any services that a Keystone could "import" or access from another Keystone would be managed in the context of a VO.

Ground rules:

• As with any P2P system, there will be significant performance and scalability concerns. These will be considered at a later time.
• There will also be significant trust and governance issues that must be thoroughly addressed. In this blueprint, we are just trying to identify the major architectural elements and design choices.
• This blueprint presents a general solution. Many simplifications could be made to trade generality for tractability.

The Current Keystone Model: The Keystone v3 model includes domains, projects, users, roles, services and endpoints. Projects and users are domain-specific, while roles, services and endpoints are Keystone-instance-wide. Users can be assigned roles and given project membership(s). Endpoints can also be associated with projects, thereby enabling endpoint filtering.

Hierarchical projects are currently being considered by Keystone. While not incompatible with the VO concept, they are not critical to this initial VO discussion. Hence, to simplify this blueprint, they are not considered here.

Observation: Keystone A does not start by immediately importing services from Keystone B -- it starts by joining a Keystone P2P network (or some other type of collaboration mechanism).

This P2P network enables Keystones to access remote services that are managed through a Virtual Organization (or Virtual Project) abstraction.

A VO is a security and collaboration context for securely managing the sharing of resources (services) among participating Keystones. (See the Object Model diagram.) A VO Domain consists of a set of Roles and a set of Projects. Roles and Projects are the tools whereby user access to services is managed. This management is done by managing the associations between objects, i.e., Users-Roles, Users-Projects, and Projects-Endpoints. (Some representative object associations are shown in the diagram.)

To allow its local users to "join a VO", the local keystone must import the VO domain, i.e., its projects and roles from another Keystone that is already participating in that VO. This requires that roles (like projects) have domain-scope, rather than system scope. Also, users (like service and endpoints) would not have to have domain-scope. Rather, the semantics of all CRUD operations (like "list") could be properly managed through the associations between the VO Domain objects (roles and projects) and the users, services and endpoints.

Design Issue: Who initially decides this project set and role set? Is it static over the VO lifecycle or can it change?

Each site has a local admin that can

(a) assign (VO) roles to local users,

(b) make a user a member of a VO project, and

(c) assign local services to VO projects (to enable endpoint filtering).

(This local admin is tantamount to a combined vo_admin/vo_site_admin in the KeyVOMS model.)

Design Issue: If each site has its own local (VO) admin, there must be mutual trust among them that each will assign roles and project memberships to their local users and services properly.

When a user authenticates to their local Keystone -- with (VO) project scope -- the local Keystone queries the P2P network for all other services mapped to this project at other Keystones. (See next diagram.)

The service endpoints returned in the Service Catalog are filtered according to which VO projects the services are assigned to, and which VO project the user is a member of.

Design Issue: Who issues the AUTH_TOKEN(s) with this Service Catalog? The Keystone that "owns" the user, or the Keystone that "owns" the service?

If the User's Keystone issues the token:

• The Service PEP must know which Keystone to use for token validation.
• The Service Owner must delegate token validation to remote Keystone,
• This blueprint seems to argue for this approach: keystone-to-keystone-federation

If the Service's Keystone issues the token:

• User's Keystone must provide a token for potentially each service returned in the VO Svc Catalog. Could possibly do this on-demand(lazy evaluation).
• User must know which token to use for which service invocation.

Third Option: A user's local Keystone acts as a broker to the service's remote Keystone. The user authenticates to the local Keystone. The local Keystone then acts as a user to the remote Keystone: it authenticates to the remote Keystone and then calls the service on behalf of the local user. The local Keystone must assume the user's identity and authorization attributes, i.e., roles. That is to day, the user must _delegate_ this authorization to it's local Keystone.

• Pros: This reduces the number of tokens that have to be issued. These tokens only have to be issued among a trusted set of entities, i.e., Keystone servers
• Cons: This introduces more layers of sfw to go through, network hops, and latency.
• This blueprint seems to argue for this type of approach: keystone-federated-security

In all cases, once the user's token is validated, the service PEP must make the final authorization decision based the user's roles. After all this, the service executes and returns a result.