General Security Architecture

Introduction

Subutai uses an object oriented security model.

Subutai Console Security Architecture

The whole system is comprised of entities owned by users.

(AOK: below is confusing .. you say can have, then next sentence that each does have a key pair: which is it?) Entities can have child elements and PGP key pairs. All entities are identified by PGP Key Pairs and entities have TRUST relations (between owners and child elements) using PGP Key signed relation documents. ROOT entities are Users. (AOK: this is confusing - does every entity have a pgp key pair?)

The diagram below shows the high level (general) architecture of the Subutai Social Console:

Diagram shows that all the services are not dependent on any client and services can call another service to handle some user operations. So how do we secure the system and when Object-Oriented-Security comes in?!

Subutai Console security, has three main actor roles:

1. User
2. Role-Manager
3. Relation-Manager

User requests SERVICEs and Role-Manager controls the REQUEST(Controls which Service can be accessed by the User) and Relation-Manager controls OBJECTS and relations (Controls which Objects are accessible for the User).

Below diagram shows overall security arch. :

Currently Console Security arch. contains following objects:

1. User
2. Peer
3. Environment
4. Container-Host
5. Resource-Host
6. Repository (Kurjun)
7. Template

Every user has (internal) UserDelegate object that delegates all the responsibilities of the User inside the Console system. All the object relations and ownership is handled by UserDelegate.
UserDelegate is only used inside the system. it's a hidden object and doesn't appear for external services. All external relationship is done via User and any relationship can be verified by the Users KeyPair. For example, Relationship between User and Environment , for external services can be verified by the User security keys. Every trust verification step goes through , User <---> UserDelelgate <----> Object.

Security Object Relations hierarchy and structure:

and related Roles are:

1. Identity-Management ( Manages RBAC ( Users, Roles and Permissions)
2. Peer-Management ( Manages Peer2Peer relations and overall Management-Host configurations )
3. Environment-Management ( Manages Environments)
4. Resource-Management ( Manages Resource-Hosts)
5. Template-Management ( Kurjun and Template Manager )
6. Karaf-Management ( Manages Karaf Console )

Access to the system is managed by Identity-Manager module. JAAS is used to control access. RESTs can be accessed by TOKENS (JWT) or login parameters (username, password). The structure of the JWT token:

header	claims	signature	Result
{"alg": "HS256","typ": "JWT" }	{"iss": "Issuer","exp": expiration datetime, . . .}	Signature is create by header and claims signed by HMAC SHA256	Base64 String:header.claims.signature(For ex: eyJhb9.eyJleHAiOjN2xfQ.uKqdTBHw_IWuA5)

Tokens in Console use HMAC-SHA256 algorithm to create token signatures and use single shared secret key both for signing and verification. (JWTs can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA.). Also HMAC-SHA can be replaced with any RSA keypairs. There can be used PGP-KeyPairs (Console object KeyPairs) to do Key Based authentication.

• HUB and Subutai Commucations

Bazaar and Console can communicate with 2 ways:

1. Direct request from Bazaar to Console REST endpoints.
2. Console Bazaar module requests to Bazaar, Bazaar communicates only with responses.

How it works:

When Bazaar uses Console REST, it uses same RESTs with MH Console.

• Heartbeat trigger
• Authenticate with signed AuthID
• Authenticate with JWT Token Console Bazaar Module is specific for Bazaar, where Console can communicate to Bazaar and get responses.
• Bazaar Module uses both Console API Console REST.
• Creates account for Bazaar users.
• Environment Build
• Registration, heartbeats, sending RH info, RH monitoring, etc.