ONAP must be deployed in different service provider environments in order to be successful. We know that different service providers have requirements for different authentication and authorisation security infrastructures. Additionally while many use cases can be satisfied by component-to-component authentication and authorisation (e.g. orchestration activities) others need the identity and authority of the originating user (e.g. retrieval of data from a source with object level access control). To meet these requirements we need a security framework that is pluggable.
Since ONAP is a micro services architecture we must also address the standard requirements to localize the burdens of configuration and patching.
Goal 1: Alternative Authentication and Authorisation security providers can be integrated without requiring customisation of the underlying ONAP code.
Goal 2: Align with the existing AAF project, so as to promote re-use and to avoid duplication/fragmentation of the security architecture.
Goal 3: Minimise the operational effort required to configure and patch microservices.
Goal 4: Provide a solution that minimises the development impact on microservices written in Clojure, Python etc as well as Java
Goal 5: Support human and non-person entities interacting with the ONAP applications at run-time.
Since CADI/AAF is our open-sourced Authorisation provider, we propose to build a reference implementation of pluggable authentication and authorisation based upon it.
Terminology:
Subject - An entity requesting to perform an operation upon the object. The subject is sometimes referred to as a requestor. The subject may be a human or a non-person entity.
User - Any subject that interacts with a system.
Non-person entity - A subject that is not a human.
Role - 1. A business responsibility that an employee or contractor fulfills.
2. A level of privilege assigned within a resource.
3. A defined set of user accounts for a job function.
This proposal relies upon the ONAP Credential Management and ONAP Communication Security initiatives to provide:
Secure certificate generation and distribution.
Component->component trust through mutual end point authentication.
TLS communications resistant to:
Spoofing
Replay attacks
Man-in-the-middle attacks
Token theft.
This proposal relies upon the Service Provider's security infrastructure (Authorisation and Authentication) to provide:
User administration.
Permissions and role management support
TO DO - insert general security arch diag
Overview
Each subsequent microservice in the transaction performs the same sequence of operations.
In this implementation, we use the same security components outlined above, but externalised in a sidecar (K8S impl described):
Each subsequent microservice in the transaction performs the same sequence of operations.
History of this proposal can be referenced here - Pluggable Security - history archive
– add libr
1.REST request arrives containing token(s) (or x509 cert subject)
2.CADI filter intercepts request and retrieves token:
1.If protocol/token type is configured for caching, CADI checks for match in cache
a. No match – validates token with supported authentication provider.
b. validation result is cached.
c. If token is not valid, request is rejected.
2.Retrieves authorisations from AAF
a. Caches result
3. Authorisation filter performs admit/reject via authorisation policy:
1.The filter compares the authorisations retrieved by CADI with the configured requirements for the invoked method/URI pattern.
2. If the authorisations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403.
1. REST request arrives containing token (or x509 cert subject)
2. CADI Filter is configured to extract tokens from one or more locations – e.g. headers, X509 cert subject
a. No match – CADI is configured to forward tokens to external security microservice with AUTH* interface.
b. Security Microservice implementation validates token with Authentication Provider
c. Security Microservice implementation retrieves authorisations from Authorisation Provider
d. Security microservice returns authorisations in standard format
2. CADI Filter caches result
3. Authorisation filter performs admit/reject via authorisation policy:
2. If the authorisations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403.
WIP
Done - to write up.
The per-microservice configuration of pluggable security includes (but is not limited to):
Impact on primary service developers
The table below describes patterns of behaviour that we have encountered whilst deploying the security sidecar with A&AI components. The table summarises the patterns and the status of support/testing.
Pattern/Feature | Description | Supported | |
---|---|---|---|
DMAAP Integration | A Microservice needs to call out to DMAAP from within a sidecar-enabled POD | Yes - Dublin | |
Database Integration | A Microservice needs to call out to a Database from within a sidecar-enabled POD | Yes - Dublin | |
Application Credential propagation | Microservice 1 to Microservice 2 with 2 way TLS and application credential propagation. This is the archetypal use case for the side car. | ||
Pod readiness probe | Kubernetes uses a readiness probe to check if an MS is up (say for dependency management). This can be implemented via an https GET request. | Yes - Dublin | |
Load balancer health check | Load balancer uses an HTTP poll to check if an MS is up | Yes - Dublin | |
Microservice has embedded authorisation policy file. | When pluggable security is deployed, the subject in the client cert sent by rproxy to resources is used to check against the permissions configured in the amended policy json file. | Yes - Dublin | |
Spring security profile | 3 profiles identified: one-way-ssl This uses one way ssl between the client and the target microservice and the authentication is Basic Auth. aaf-auth In this mode, the microservice communicates with AAF for auth via an active embedded CADI. two-way-ssl In this mode, the microservice uses the CN in client cert to match against a security policy file (e.g. aai_policy.json for authorization. | Yes - Dublin Untested Yes - Dublin |