Peer2PeerKeystones

Support for Virtual Organizations (or Virtual Projects)

Goal: Enable one Keystone to "import" services from other Keystones.

Premise: This is tantamount to a P2P KeyVOMS, rather than an external, third-party KeyVOMS. Any services that a Keystone can "import" or access from another Keystone are managed in the context of a VO. This could alternatively be called a Virtual Project, but we will stick with "VO" for now.

Premise: For this blueprint, all service types will be considered; not just OpenStack infrastructure services.

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.

Key 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.

To allow its local users to "join a VO", the local keystone must import the VO project and its associated rule set from another Keystone that is already participating in that VO. This project and role set are the tools whereby user access to services is managed.

Design Issue: Who initially decides this project hiearchy 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) project roles to local users, (b) make a user a member of a VO project (in the hierarchy), 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.

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,

If the Svc'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.

Third Option 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.

Third Option Cons: This introduces more layers of sfw to go through, network hops, and latency.

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.