...
Epic | User Story | Description | Frankfurt? | JIRA |
---|---|---|---|---|
Secured communication | Yes | |||
Secured communication between SOL003 Adapter and SVNFM | Secured communication between SOL003 Adapter and SVNFM | Yes | Covered by SOL003 Adapter JIRA | |
Secured communication between SOL005 Adapter and external NFVO | Secured communication between SOL005 Adapter and external NFVO | Yes | Covered by SOL005 Adapter JIRA | |
Authentication and authorization support between between SOL003 Adapter and SVFNM | Authentication and authorization support between between SOL003 Adapter and SVFNM
| Yes | Covered 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
| Yes | Covered by SOL005 Adapter JIRA | |
Authentication and authorization support between between SOL002 Adapter and SVFNM | Authentication and authorization support between between SOL002 Adapter and SVFNM
| Yes | Covered 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 | ||||
---|---|---|---|---|
|
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.
AAF-Based Authentication and Authorization
...