PAGE STATUS: UNDER CONSTRUCTION

STATUS: Project Approved (next step is Architecture Approval)

AAF (Application Authorization Framework):

1 High Level Component Definition and Architectural Relationships 

(If agreed the below figure is to be removed in order to align with a common look and feel for the functional archtiecture.  The AAF internals are below)

The AAF functional entity provides authentication, authorization and certificate management services for ONAP components. It provides the capability to:

• Allow each ONAP component to create a namespace to set up their authentication and authorization elements:
  
  • Permissions
  • Roles
  • Credentials
• Access to organizational identities
  • There is a default set of identities each ONAP component for use in ONAP Test Systems
• Store credentials for organizational identities
  
  • Passwords
    
    • AAF provides secure password storage for test/lab use only
    • AAF has ability to delegate authentication to external authenticator
  • Certificates
    • These certificates have unique Authorized Identity embedded, which supports 2 way TLS Authentication
    • These certificates can also be used as Server side certificates
• Manage fine grained permissions
• Provide ONAP components or other enforcement points with APP configured permissions
• Manage roles
  • AAF provides roles for identities that include any granted permissions
• Validate and provide introspection of OAuth tokens
  
  • Currently unused by ONAP
• Provide locator services through the AAF Locator
  
  • AAF Components and ports can be found globally
  • Locator facts
    
    • Locator is not technically restricted to AAF.  It can register (protected by Authentication/Authorization) any running process/port/interface 
    • Registrations include global coordinates, allowing clients to pick the "closest" one
    • Locator is independent of any cluster or container mechanisms, which gives accessibility to any network accessible component
      • Global - Components can reside anywhere in the world
      • Scalable - A new instances can be started anywhere and instantly increase capacity and usage
        • "For best results", use Cassandra scaling
      • Resilient - VMs, clusters, data centers, K8S could go down, and AAF is still accessible.
• Provide a globally accessible file server to get public security information. For example,
  
  • RCLs
  • Root Certificates (any the Organization wants to publish)
  • Organizational approved truststores
• Process approvals
• Authorize UI and API requests (REST interface)
• Authenticate users (human and application) (REST interface)
• Manage AAF components (REST interface)
• Auto-Generation of ONAP certificates
  • For ONAP test/lab use, AAF Certman provides a local certificate authority (CA)
  • AAF Certman can integrate with any certificate authority (CA) that supports the Simple Certificate Enrollment Protocol (SCEP). ONAP does not test this functionality
• Auto-configuration of ONAP certificates for ONAP clients
  
  • as part of "Bare Metal"
  • on Docker volumes

Additionally, AAF provides a Java client called CADI, which simplifies AAF use by an ONAP component. The CADI framework is a Java client that:

• • Includes all AAF interactions: authentication, authorization, management
  • Provides the following authentications: X509, BasicAuth and OAuth
  • Provides adapter interfaces for external authenticators
  • Includes a Shiro adapter to support ONAP use of ODL

2. API definitions

AAF provides the following interfaces:

Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interface

AAF Consumes no Interfaces:

The current API documents can be found at:

• AAFE-1 (to be added)

• AAFE2 (to be added)
• AAFE3 (to be added)

3. Component Description: (IN PROGRESS)

The Next level of the AAF functional architecture is below:

Code Access Data Identity (CADI) is a client framework included in a web GUI or API that invokes AAF to provide AAF authentication and authorization services to containers and standalone services.

• Authenticate with one or more Authentication Protocols
• Authorize in a FINE-GRAINED manner using AAF Components
• CADI has three types of clients
  • CADI AAF TAF (J2EE) - integrates with a web GUI
  • CADI AAF TAF (J2EE Filter) - integrates with a REST API
  • CADI AAF TAF (Java Client) - integrates with a database

AAF Service - TBD

AAF Cassandra Database - TBD

Certificate Manager (CertMan) - provides CA services (X.509 certificate generation/renewal, root and intermediate cert delivery), secure key pair generation, and keystore creation and delivery to applications. CertMan can also integrate with an external CA that supports the Simple Certificate Enrollment Protocol (SCEP).

1. Browser client goes to GUI using for instance SSO plugin or Basic Auth
2. App authenticates to App Service API using x509 or Basic Auth or OAuth
3. CADI Filter (CADI AAF TAF) coverts credential to “Principal”. If not in cache, AAF is contacted for Permissions protecting GUI with Service ID/Credential (ApplicationID/Pass or X.509 Client Cert (preferred)).
4. AAF does provide User/Password features, or can be delegated to other credential service via Plugin
5. If information is not in Service Cache, AAF’s DB is contacted using AAF Service ID/Credential.
6. Client App uses Permission Attributes delivered by AAF/AAF Cache for protecting data/functions (using J2EE method).
7. If not in Cache, Client contacts App Service, using App ID/Credential.
8. CADI Filter converts App ID/Credential to Principal. If not in cache, contacts with AAF (with App ID/Credential) for Permissions of Client.
9. App protects data based on Client Permissions.
10. Component contacts next layer using Service ID/Credential.
11. If ID or Permissions of AppServer are not in Cache, contact AAF using AAF Security Plugin for Cassandra, which uses AAF Java Client.
12. Cassandra protects Cluster/Keyspace/ColumnFamily w/Permissions.

4. known system limitations: (IN PROGRESS)

Runtime: None

5. Used Models: (N/A)

6. System Deployment Architecture:

AAF consists of the following containers:

• aaf-cass – A Cassandra container that preloads itself with AAF data
• base – an intermediate container that sets up jre-alpine, adds users, additional tools (e.g., openssl) to all AAF containers
• core – an intermediate container containing all AAF java parts
• aaf-config – a job-based container that sets up all AAF container volumes with certificate authority (CA) configurations, key pairs, certificates and configurations.  It can be stand alone, but also is used as an initContainer
• aaf-agent – a job-based container for clients that sets up a client volume with key pairs, certificates and configurations
• Service based Containers – these all use the aaf-config setup
  • aaf-service – core API Service
  • aaf-locate – tracks all AAF Service internally and globally
  • aaf-oauth – supports Oauth2 behaviors of “token” and “introspect”
  • aaf-cm – Certificate Manager – Reference Certificate Authority – in ONAP Test, also functions as CA
  • aaf-gui – Management GUI for Apps to add Permissions, roles, etc.
  • aaf-fs – HTTP service, required primarily to service certificate revocation lists (CRL), but can also be loaded with AAF relevant files for download (e.g., root.intermediate certificates)
• aaf-hello – example app used to showing client how to use AAF Agent containers, CADI J2EE filters, etc.

7. New Capabilities in this Release

This release, AAF adds the following capabilities:

• AAF Locator differentiates public fully qualified domain name (FQDN) from Kubernetes FQDN

  • Internal Kubernetes FQDN generated when client declares its container namespace
  • Public FQDN are accessible for both:
    
    • GUIs/Management outside cluster
    • Non-ONAP entities outside the cluster
    • Other clusters
• Improved documentation and enhanced configuration
  
  • Example "Helm" init containers to setup volumes
• Refactored maintenance processes, including
  
  • Analysis of expiring credentials and Roles
  • Generation of approval records
  • Notification of approvals, credentials and roles to support configurable integration with external services.

8. References

1.  AAF Overview & User Guide: https://onap.readthedocs.io/en/latest/submodules/aaf/authz.git/docs/index.html