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
|
Epic and User Story
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 | ||
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 |
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.
- The values shown below related to the certificate included in the Adapter which has been generated from AAF.
- The following parameters can be set to configure the certificate for the Adapters (as the server side).
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.
- http:
- 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>