Communication Security - Guilin
- 1 Use Cases
- 2 Feature Descriptions
- 3 Epic and User Story
- 4 Communication Security Architecture for SOL005 and SOL003 APIs
- 4.1 High-Level View
- 4.2 Detailed View
- 5 HTTPS Support
- 6 OAuth2 Token-based Authentication
- 7 Authentication and Authorization for the VNFM Adapter and the VNFM
- 8 AAF-Based Authentication and Authorization
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 | Guilin Plan? | JIRA |
---|---|---|---|---|
Secured communication | Support Secure communication for ONAP Internal components and ONAP External components | Yes | ||
SO needs to a common security communication solution for ONAP internal components | SO needs to a common security communication solution | 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
ONAP ETSI-Alignment API security conforms to ETSI NFV SEC022 Security specification (SEC022 GS).
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>
High-Level View
The following diagram depicts a high-level view of ONAP ETSI-Alignment API security.
Detailed View
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?},QgM3o7HThe 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>