Roadmap Commitments Use Cases We collectively require the

Roadmap Commitments – Use Cases We collectively require the following use cases for 1810/Casablanca: Use case Description Mandatory / Desirable Authentication and Authorisation via CADI/AAF Existing CADI/AAF integration Mandatory-1 Authentication and Authorisation via CADI/ Third Party Provider CADI integration to Standardised Security Service Interface Mandatory-1 Authentication and Authorisation via CADI unified cache Unified Cache for Authentication and Authorisation tokens internal and third party. Desirable Secure Token Propagation Ensure REST calls from one microservice to the next preserve originating identity to support user based authorisation use cases (as well as m 2 m) Mandatory-2 Configuration based authentication Deployments can change authentication tokens without rebuilding ONAP microservices Mandatory-1 1

Authentication and Authorisation – General Flow An upstream user or application invokes a REST endpoint on ONAP microservice (MS 1) supplying one or more credentials or tokens. 1 1 2 2 3 3 1. The request is intercepted by the CADI filter whose responsibilities include: 1. extracting the required tokens/credentials from the request 2. invoking the correct authentication and authorisation providers to validate the supplied tokens and to discover their authorisations 3. optionally caching the result of the authentication and authorisation steps above to optimise performance 4. rejecting requests with invalid credentials. 5. injecting the retrieved authorisation token(s) into a well-known place in the request (for further inspection by the authorisation filter). 2. The request is intercepted by the Authorisation Filter that: 1. extracts the authorisation tokens from the request 2. tests that the tokens have not been tampered with or expired 3. compares the authorisations provided with those required to access the REST endpoint. 4. rejects requests that do not meet the authorisation criteria 3. The request is passed to the application that performs business logic. 1. The application logic may optionally programmatically query the authorisations associated with the request identity/identities 2. The application logic may optionally invoke REST requests on one or more microservices to perform its business. If it does so, it must use the provided REST client to ensure that the provided credentials/tokens are propagated correctly and securely. These tokens are not directly available to the application developer Each subsequent microservice in the transaction performs the same sequence of operations. 2

Authentication and Authorisation via CADI/AAF 1 2 3 1. REST request arrives containing token (or x 509 cert subject) 2. CADI filter intercepts request and retrieves token: 1. If protocol is configured for caching, CADI checks for match in cache a. No match – validates token with supported authentication provider. b. validation result is cached. c. If token is not valid, request is rejected. 2. Retrieves authorisations from AAF a. Caches result 3. Authorisation filter performs admit/reject via authorisation policy: 1. The filter compares the authorisations retrieved by CADI with the configured requirements for the invoked method/URI pattern. 2. If the authorisations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403. 3

Authentication and Authorisation via CADI/ Third Party Provider 1 2 3 1. REST request arrives containing token (or x 509 cert subject). 2. CADI Filter is configured to extract tokens from one or more locations – e. g. headers, X 509 cert subject 1. If protocol is configured for caching, CADI checks for match in cache 1. No match – CADI is configured to forward tokens to external security microservice with AUTH* interface. 2. Security Microservice implementation validates token with Authentication Provider. 3. Security Microservice implementation retrieves authorisations from Authorisation Provider. 4. Security microservice returns authorisations in standard format 2. CADI Filter caches result 3. Authorisation filter performs admit/reject via authorisation policy: 1. The filter compares the authorisations retrieved by CADI with the configured requirements for the invoked method/URI pattern. 2. If the authorisations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403. 4

Dependencies This proposal relies upon the ONAP Credential Management and ONAP Communication Security initiatives to provide: • Secure certificate generation and distribution. • Component->component trust through mutual end point authentication. • TLS communications resistant to: • Spoofing • Replay attacks • Man-in-the-middle attacks • Token theft. This proposal relies upon the Service Provider's security infrastructure (Authorisation and Authentication) to provide: • User administration. • Permissions and role management support 5

Impact ONAP clients: Need to integrate client with Authentication Provider to retrieve credential. 1. Client needs to provide tokenised credential in REST request. ONAP Services: 1. Need to include the CADI and Authorisation Filters in their filter chains. 2. Need to configure CADI client. 3. Need to configure authorisation requirements per URI, per service. Note that this can be as fine or coarse as the service provider's project requires. 4. All new or modified microservices need to use the secured REST client to invoke other microservices for seamless and secure propagation of identity and authorisations* UI Authentication/Authorization (External Authenticator & AAF) 7) VID access ABC granted 9) Get roles and permissions to ensure “ABC” can 8) Create“Create VID VNF” Pluggable Security Microservice 5) Roles and permissio ns Token Service 12, 15, 18, 21) Authorization okay, return token. (OAuth, JWT, etc) 11, 14, 17, 20) Authenticate in CADI using certificates (Cert. Man) send mechid and requested resource to AAF for authorization, return Oauth token to application where it is cached – initial invocation only. 10) Call MSO CADI 13) Call A&AI AAI 16) Call SDN -C SDNC 19) Call Any. App Any App CA DI ONAP Portal CADI 2) Authenticate and authorize “ABC” CA DI 6) Access VID Other Policies 4) Get roles and permissions for “ABC” 3) “ABC” authenticated CA DI 1) Login to Portal AAF Policies CA DI External Authenticato r API Authentication/Authorization (AAF)

s 7

Authentication and Authorisation via CADI unified cache 1 2 3 1. REST request arrives containing token (or x 509 cert subject) 2. CADI Filter is configured to extract tokens from one or more locations – e. g. headers, X 509 cert subject* 1. Checks for match in cache 2. Match found, identity is valid. 3. Checks for matching authorisations in cache 4. Match found 5. Authorisations added to request 3. Authorisation filter performs admit/reject via authorisation policy: 1. The filter compares the authorisations retrieved by CADI with the configured requirements for the invoked method/URI pattern. 2. If the authorisations are satisfied, the filter admits the request. Otherwise the request is rejected with a 403. *Configuration and cache processing is unified between internal and external processing modes 8

Secure token propagation 1. TO DO – ADD Jonathan’s diagram and strawman proposal 1. REST request arrives containing token (or x 509 cert subject) 2. Request is admitted (with an authorisation token) 3. Application developer invokes a REST request on another microservice using CADI API. 4. CADI API transparently inserts the required OAUTH 2/JWT into the request: 1. Make the request with full context (microservice identity + end user identity, if known + newly generated authorisation token, to avoid replay). 5. Qualities of Client: 1. Must be threadsafe 2. Must not allow the application developer direct access to the token. 3. Consistent regardless of whether the token originated from the internal or external process. Note. In future, we may implement additional CADI APIs to support propagation of security context for other request protocols, e. g. DMAAP, DME 2 9

Authorisation flow details – csp cookie 1 2 4 3 5 10

Authorisation flow details – JWT 1 2 11

Authorisation flow details – X 509 (using existing policy file) 1 2 3 12

Proposal 8 th May – Default CADI Token flow - Authorization 1 4 5 2 3 PREREQUISTE: Request MUST have been Validated for Authentication, and have created an FQI (Fully Qualified Identity to continue) 1. Check for Token reference 2. Check Cache for Token 3. If no match, or not exist: 1. Retrieve Token information from Auth (which includes Authorizations) by Client FQI 2. Cache Token Information 4. Attach Authorization Info to Object visible by all remaining elements in flow 1. Example: In J 2 EE, this is the Http. Servlet. Request 5. DECISION POINTS: 1. There are many potential decision points in the code. These include: 1. Whether a call is allowed for a given method a service (i. e. URL “Path. Info”) 2. Any point in the written service code where the service needs to protect a resource 2. For each of these, validation method on an object that returns Boolean if the Authenticated Identity matches the policy string. 1. Example J 2 EE Request Object 13

Proposal 8 th May – CADI Local Token processing 1 2 4 5 1. REST request arrives containing token (or x 509 cert subject) 2. CADI filter intercepts request and retrieves token: 1. Checks for match in cache 2. No match – validates token using local processing 3. Retrieves authorisations from local token 4. Caches result 5. Performs admit/reject via authorisation policy. 3. Local Tokens derive to Principals of the correct sort (aka Token Principal) and Authorizations. 4. Once derived, they are processed in exactly the same manner as if they were “Live” 14

Proposal 8 th May Item 1 Description 2 We extend CADI to provide the following configurable request processing decision point: 1) Process request internally (i. e. do what CADI does today) 2) Process request externally (i. e. call out to a separate security microservice) a. Specify which headers/location to find the security credentials/tokens b. Pass tokens to security service for authentication/authorization via a standardized interface. c. Return agreed authorization token (probably OAUTH 2) d. Perform policy decision to admit request based on authorisations (this last step should be common/aligned with the internal CADI processing – Jonathan can you clarify how this is currently done? We don’t want two mechanisms. ) We adopt the CADI mechanism for token propagation between microservices: 1) We use OAUTH 2 tokens assuming: a. Self-contained representation of the principal’s identity b. Self-contained representation of the principal’s claims/authorisations c. Token is signed (so that we can verify it’s source) d. Token can be configured with TTL 2) Token propagation is consistent between internally and externally processed generation of the token. 3) Token propagation is transparent to the application developer – i. e. the app developer can’t access/modify the token and their only awareness/constraint is that they make their REST calls thru the exposed CADI API Jonathan – please can you provide an example/docs as to how to use this part of CADI, so that we can be clear what is involved? We extend CADI (this sounds like a minimal change) to allow tokens/results for externally processed requests to be cached as first class citizens so as to minimize the need to call out to the security service. ONAP microservices adopt CADI framework for Authentication and Authorisation. 3 4 5 We leave CADI in situ in the microservices where it can be used by Java based microservices as it is today (e. g. DCAE) with its built in support for AAF. 15