Communication Security - Guilin

Use Cases

• Communication security between SOL003/SOL005 Adapters and SVNFM/NFVO

Feature Descriptions

Epic and User Story

Communication Security Architecture for SOL005 and SOL003 APIs

• Requirement: External NFVO and SVNFM need to validate incoming ETSI package
• The SOL003/SOL005 Adapters communicate with the SVNFM and the external NFVO via secured HTTPS protocol with a proper authentication and authorization.
  • Support of HTTPs protocol is a must
  • SOL003/SOL005 Adapters provide security mechanism for authentication and authorization.
  • SVNFM/NFVO provide security mechanism for authentication and authorization.
  • authentication federation between the Adapters and the SVNFM/NFVO is under discussion.
• <describe authentication choices and use of AAF here> 

HTTPS Support

To secure communications between the SOL003/SOL005 Adapter and SVNFM/NFVO, the communication between them will be done via HTTPS protocol.

One-Way TLS configuration 

• SOL003/SOL005 Adapter
  • The following parameters can be set to configure the certificate for the Adapters (as the server side).
    • The values shown below related to the certificate included in the Adapter which has been generated from AAF.
      • If a different certificate is to be used then these values should be changed accordingly.

server:

ssl:

key-alias: so@so.onap.org

key-store-password: 'I,re7WWEJR$e]x370wRgx?qE'

key-store: classpath:org.onap.so.p12

key-store-type: PKCS12

• The following parameters can be set to configure the trust store for the Adapters (as the client-side)
  • http:
    client:
    ssl:
    trust-store: org.onap.so.trust.jks
    trust-store-password: NyRD](z:EJJNIt?},QgM3o7H
  • The values shown above relate to the trust store included in the VNFM adapter jar which has been generated from AAI. If a different trust store is to be used then these values should be changed accordingly.
• Ensure the Adapter endpoint values for the below parameter uses https instead of http

vnfmadapter: 

endpoint: https://so-vnfm-adapter.onap:9092 (for example)

sol005adapter:

endpoint: https://sol005-adapter.onap:9094 (for example)

• Adapter client needs to configure the following endpoints to use https

so:

vnfm:

adapter:

url: https://so-vnfm-adapter.onap:9092/so/vnfm-adapter/v1/

Two-Way TLS Configuration

• Ensure the value for username and password are empty in the AAI entry for the VNFM 
  • The VNFM Adapter will use OAuth instead of two way TLS if the username/password is set.

---------------
VNFM adapter
---------------
Set the following parameter for the VNFM adapter:
server:
    ssl:
        client-auth: need

---------------
Adapter Client (e.g., bpmn-infra or any Adapter client):
---------------
Set the following parameters for adapter client:
rest:
    http:
        client:
            configuration:
            ssl:
                keyStore: classpath:org.onap.so.p12
                keyStorePassword: 'RLe5ExMWW;Kd6GTSt0WQz;.Y'
                trustStore: classpath:org.onap.so.trust.jks
                trustStorePassword: '6V%8oSU$,%WbYp3IUe;^mWt4'

Ensure the value for the below parameter uses https instead of http
so:
    vnfm:
        adapter:
            url: https://so-vnfm-adapter.onap:9092/so/vnfm-adapter/v1/

---------------------------- 
VNFM (or VNFM simulator):
----------------------------
Set the following parameters for the VNFM simulator (if used):
server:
    ssl:
        client-auth: need
    request:
        grant:
            auth: twowaytls

OAuth2 Token-based Authentication

---------------
VNFM adapter:
---------------
Ensure the value for username and password set set in the AAI entry for the VNFM. The VNFM adapter will use this username/password as the client credentials in the request for a token for the VNFM. The token endpoint
for the VNFM will by default will be derived from the service url for the VNFM in AAI as follows: <base of service url>/oauth/token, e.g. if the service url is https://so-vnfm-simulator.onap/vnflcm/v1 then the token url will
be taken to be https://so-vnfm-simulator.onap/oauth/token. This can be overriden using the following parameter for the VNFM adapter:
vnfmadapter:
    temp:
        vnfm:
            oauth:
                endpoint:

The VNFM adapter exposes a token point at url: https://<hostname>:<port>/oauth/token e.g. https://so-vnfm-adapter.onap:9092/oauth/token. The VNFM can request a token from this endpoint for use in grant requests and notifications
to the VNFM adapter. The username/password to be used in the token request are passed to the VNFM in a subscription request. The username/password sent by the VNFM adpater in the subscription request can be configuered using the
following parameter:
vnfmadapter:
    auth: <encoded value>
where <encoded value> is '<username>:<password>' encoded using org.onap.so.utils.CryptoUtils with the key set by the paramter:
mso:
    key: <key>
The default username:password is vnfm-adapter:123456 when vnfm-adapter.auth is not set.

---------------
VNFM simulator:
---------------
Set the following parameters for the simulator:
spring:
    profiles:
        active: oauth-authentication
server:
    request:
        grant:
        auth: oauth

==========================================
To use basic auth for notifications
==========================================
The same username/password is used as for oauth token requests as describe above and passed to the VNFM in the subscription request.

Authentication and Authorization for the VNFM Adapter and the VNFM

• Leverage AAF for authentication and authorization to secure communications among ONAP components and SVNFM and external NFVO (App-to-App AA). The following is input from AT&T. More to discuss…
  • OAuth2 is not yet used in ONAP. Start with HTTP Basic Authentication with HTTPS
  • Update an application pom file and add properties; i.e., no application code changes?
    • Remove Spring Security as well, as we cannot have both in place
  • There is no need to use the CADI Rest Client at all
  • The CADI filter can be configured to handle authorization; that is the method AT&T uses, or the application can enforce the authorization. It supports basic URI matching semantics
  • Generate certificates by AAF for HTTPS is the current gap.
• Authentication and Authorization on SOL003 and SOL005 APIs need to be supported.
  • HTTP Basic Authentication + TLS
  • OAuth2
  • Two-way TLS
• How does ONAP support vendor-specific SVNFM security (authentication/authorization)? It is under discussion.
  • Security between SOL003/SOL005 and SVNFM/NFVO
  • Each SVNFM can use their own security mechanism; i.e., non-AAF based
• Note:
  • Communications between SOL003/SOL005 Adapter and SVNFM/NFVO must be secured through HTTPS
  • SOL002 Adapter is facing the similar security requirements.

AAF-Based Authentication and Authorization

<AT&T AAF input here>