PAGE STATUS: UNDER CONSTRUCTION

STATUS: Project Approved (next step is Architecture Approval)

AAF (Application Authorization Framework):

1 High Level Component Definition and Architectural Relationships 

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 real-time REST  interfaces for

• Authorization
• Authentication, if local AAF authentication is used
• Management API for all AAF components, protected by strong authentication and authorization

CLAMP provides the following REST interfaces: TO BE UPDATED

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

The current API documents can be found at:

• The provided UI interfaces are found at: CLAMP latest user guide

• CLAMP internal APIs can be found: clamp swagger pdf

AAF Consumes no Interfaces:

3. Component Description: (IN PROGRESS)

A more detailed figure and description of the component.

<< For later inclusion >>

4. known system limitations: (IN PROGRESS)

Runtime: None

Clamp data redundancy is dependent on Kubernetes and the persistent volume.

Clamp application redundancy HA relies on Kubernetes

5. Used Models: (N/A)

6. System Deployment Architecture: (IN PROGRESS)

AAF consists of x containers:

• CLAMP container
• MariaDB container
• Kibana container
• E_Search container
• LogStash container 

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
2. AAF internal interfaces:  https://onap.readthedocs.io/en/latest/_downloads/d3c9f924c6586fe411d40a05ad9b1bb7/swagger.pdf