Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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> 

...


Gliffy
nameETSI Secure Communication Architecture
pagePin6


HTTPS Support

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

...

---------------
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.

Image Added

AAF-Based Authentication and Authorization

...