Skip to content

federation 4.1 Region Federation Architectural Analysis

Jump to bottom
Steve Jones edited this page Sep 7, 2017 · 1 revision

Region Federation PRD-219 JIRA (eucalyptus.atlassian.net)

ARCH-67 JIRA (eucalyptus.atlassian.net)

Overview & Key Characteristics

  • This feature is about identity federation, not synchronization or centralization of identity, nor does it include globalized namespace (e.g., for buckets) but should be done w/ an eye towards the latter.

  • There are AWS APIs supporting federation: SAML-based federation, See SAML Providers. Security Tokens via STS, See Delegation & Federation.

  • Identity in Eucalyptus consists of: Accounts, Users, Groups, Roles. Authentication bits are: Access Keys, Login Profiles, and Certificaties. Policies can be associated with any of the above and are evaluated as described here.

  • Observation #1: The approach taken has opportunity to be foundational to supporting hybrid identity by adopting the same basic mechanisms as used by AWS.

    • Observation #1.a.: There exist a number of candidates for providing implementations of SAML2, OAuth2, and OpenID support which are mature and possible to integrate.
    • Observation #1.b.: The approach of inventing a federation protocol has the downside of being inherently complicated, most likely a dead-end wrt interoperability and IDM integration, and difficult to evaluate for soundness.
    • Observation #1.c.: The existing candidates offer support for integrating other backend IDM systems and

  • Observation #2: Federation implies authentication has a local-region (normal) and a federated-region (new, remote) path.

  • Observation #3: For an identity authenticated by a federated region's identity provider, full subject information (account, user, policies) need to be delivered as part of the authentication token (as these are not synchronized).

  • Observation #4: Of the parts of identity, there is a need for mutual exclusion between region assignments of access key identifiers and certificates

  • Observation #5: There is no implied topology; be it mesh, hub-and-spoke, etc. The approach should identify the default, but not preclude other topologies.

  • Question #1: Is the existing STS-driven transient identity the right integration point?

  • Question #2: Of the candidates which exist is there one which: is functionally sufficient, suitable for integration, supports future efforts?

Use Cases

Per PRD-219 above.

Admin Use Cases

  • Configure Region to be Federated with another Region

    • Configure this region to trust another region for purposes of authentication (establish trusted provider relationship)
    • Configure this region to allow another region to use it for purposes of authentication (establish relying party relationship)

  • Delete Region's federation relationship with another region

    • Delete this region's trust provider relationship with another region
    • Delete this region's relying party relationship with another region

  • Describe Regions (with Federation information)

    • Status, Credentials establishing trust

User Use Cases

  • User is trying to perform SomeOperation (any operation) against
    • First, an initial region (lets say it is the region of record for the user's identity)
    • Second, another region which is federated with the initial region

Elements & Interactions

  • TODO

Workflows & Coordination

  • Federation Configuration & Management
  • Authentication
  • Account/User/Policy Management

Abstractions & Behaviours

TODO

Architecture Skeleton

Distributed Workflows & APIs

TODO

Federation Software & Protocols

tag:confluence tag:rls-4.1 tag:federation

Clone this wiki locally