Use Cases

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

Feature Descriptions

Feature

Description

Feature

Description

Secured communication and authentication and authorization support

Secured communication and authentication and authorization support between SOL003/SOL005 Adapter and External NFVO

  • HTTPS protocol
  • Authentication and Authorization support via AAF

Epic and User Story

Epic

User Story

Description

Frankfurt?JIRA
Secured communication

Yes

Secured communication between SOL003 Adapter and SVNFMSecured communication between SOL003 Adapter and SVNFMYesCovered by SOL003 Adapter JIRA

Secured communication between SOL005 Adapter and external NFVOSecured communication between SOL005 Adapter and external NFVOYesCovered by SOL005 Adapter JIRA

Authentication and authorization support between between SOL003 Adapter and SVFNM

Authentication and authorization support between between SOL003 Adapter and SVFNM

  • support of vendor SVNFM authentication and authorization
  • support of SOL003 Adapter authentication and authorization
YesCovered by SOL003 Adapter JIRA

Authentication and authorization support between between SOL005 Adapter and external NFVO

Authentication and authorization support between between SOL005 Adapter and external NFVO

  • support of external NFVO authentication and authorization
  • support of SOL005 Adapter authentication and authorization
YesCovered by SOL005 Adapter JIRA

Authentication and authorization support between between SOL002 Adapter and SVFNM

Authentication and authorization support between between SOL002 Adapter and SVFNM

  • support of vendor SVNFM authentication and authorization - OAuth2 Token-based only
  • support of SOL002 Adapter authentication and authorization - OAuth2 Token-based only
YesCovered by SOL002 Adapter JIRA

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> 


ETSI Secure Communication Architecture


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>





  • No labels