OOF Security Framework

Security aspects of OOF fall into two categories: encrypted communications and Role-Based Access Controls (RBAC).
Encryption is based on the use of HTTPS (as opposed to HTTP), and RBAC relies on integration with the ONAP Authentication and Authorization Framework (AAF).

This material considers security aspects for OOF modules OSDF and HAS.

Encrypted communications via HTTPS

OOF components may act as clients and servers
E.g.: client (OOF-HAS) -> server (AAF), client OOF-OSDF -> server OOF-HAS

OOF-HAS and OOF-OSDF each reach out to other ONAP servers via web services. Some servers do not (yet) support HTTPS and therefore do not provide the opportunity to encrypt messaging.
This presents a potential security threat. Note however that servers may require HTTP basic authentication, in which a username/password must be provided when calling the server’s
HTTP endpoints. Such credentials are provisioned by the service, i.e. OOF must obtain credentials by contacting the server’s project team.

Communications via HTTPS may involve server verification, in which the client verifies the authenticity of the server, or bi-lateral verification,
in which the client validates the server, and the server in turn validates the client.

server validation

For those services that support HTTPS, OOF SHOULD, in addition to using basic auth (username/password), implement server validation, by providing a certificate file in the request.
OOF OSDF and HAS use different python packages for making HTTP(S) requests, and therefore the syntax of including the cert file in the request is slightly different.
HAS uses the python requests library, which includes a verify term in its request API. If verify = false, server verification is not performed, yet communicatiosn are still encrypted.
If verify = ‘cert.file’, requests will verify the response from the server. Cert are provisioned by services teams, like usernames and passwords.

E.g. AAF_RootCA.cer is used by HAS to verify responses from AFF

bi-lateral verification

Services that support bi-lateral verification can accept client credentials in requests.
Client credentials include cert and key files. Again, HAS and OSDF use different packages with different APIs, and again, the credentials are provisioned by service teams.

Role Based Access Control (RBAC)

RBAC allows a service to implement fine-grained access controls (AC) to its endpoints, i.e. one set of users may read from an endpoint, and another set may read and write to it).
ONAP AAF encapsulates the users, roles, and permissions a service such as OOF may use to implement fine-grained AC.

AAF supports the constructs of namespace, user, permission, role. Within the domain of a service’s namespace, e.g. OOF-HAS, there may exist users, representing the clients of the service;
users may be associated with one or more roles; and roles may be associated with one or more permissions. A permission indicates a resource (endpoint) and a set of actions (read/write)

E.g, the OOF-HAS namespace defines one user implicitly representing OOF-OSDF, one role, and one permission that allows r/w access to the <>/v1/plans endpoint.

Note: we need to distinguish carefully between two categories of User; one is the ‘users’ of the AAF service, in our case OOF_HAS and OOF-OSDF.
These users access AAF using HTTPS servier validation and basic auth. These entities are not ‘users’ provisioned within the OOF namespace of AAF.
The other set of users are the clients interacting with OOF to whom we apply AC. These are ‘users’ in the AAF database.

E.g.
OOF-HAS is a client of AAF, not a user provisioned in the HAS namespace of AAF
OOF-OSDF is a client of OOF-HAS, and therefore is represented as a user in the HAS namespace in AAF

Specifically: AAF is currently provisioned thusly:

the admin and owner roles are reserved for admin purposes, and the certman permission is not directly used.

To implement fine-grained access controls a server (e.g. HAS) must:
- identify clients that are subject to access controls
- anonymous clients may be allowed to hit some endpoints, e.g to retrieve version information
- clients must be allocated a username/password for their use in basic auth to identify themselves
- Server team must provision AAF with the appropriate users, roles, and permissions
- At runtime
- retrieve client's mechId via Post request to <https://aaf_domain:port>/authn/validate, with client username/password in body
- request permissions from AAF based on user, via GET to <https://aaf_domain:port>/authn/validate/mechId
- assess permissions while preparing a response, e.g. send an HTTP 404 if client is requesting a protected resource with improper permissions

AAF test instance

WinDriver labs hosts an instance of AAF for testing. The data provisioned in this instance is used to bootstrap instances
in other environments.

VPN into Intel test lab to view and modify contents of AAF test instance, to generate tokens, and hit endpoints

Contact Stephen Gooch (stephen.gooch@windriver.com) to request VPN access. on approval, he will send email
w/ vpn config and username/password

Contact Jonathan Gathman (jg1555@att.com) for help with AAF in general including test instance

lab front-end
http://10.12.25.2/project/

point browser (Chrome) to: aaf-onap-test.osaaf.org
username:password can be acquired from contacts above

Test AAF API

from directory containing AAF_RootCA.cer

curl -u aaf_admin@people.osaaf.org:demo123456! --cacert AAF_RootCA.cer --header "Accept: application/Perms+json" https://aaf-onap-test.osaaf.org:8100/authz/perms/user/oof@oof.onap.org | json_pp

To Do

Casablanca release implements some features of encryption and RBAC, however, items remain, including:

HAS endpoints not currently protected:
/release_orders
/triage
/latency_reduction
/latency_country_rules