...

CLAMP relies on Policy to communicate to App-C/VF-C/SDN-C/SO in runtime, hence these are not part of CLAMP 

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 interfaces: TO BE UPDATED

...

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: (IN PROGRESS)

AAF uses the following models:

• Service model (received from SDC)
• VNF model (received from SDC)
• Policy Model.

6. System Deployment Architecture: (IN PROGRESS)

AAF consists of x containers:

...

This release, AAF adds the following Capabilitiescapabilities:

• AAF Locator differentiates public Fully Qualified Domain Name fully qualified domain name (FQDN) from Kubernetes FQDN

  • Internal Kubernetes FQDN generated when client declares its Container Namespacecontainer namespace
  • Public FQDN are accessible for both:
    
    • GUIs/Management outside Clustercluster
    • Non-ONAP entities outside the Clustercluster
    • Other Clustersclusters
• Improved documentation and enhanced configuration
  
  • Example "Helm" init containers to setup Volumesvolumes
• Refactored maintenance processes online for Open Source (meaning non company specific), including
  
  • Analysis of expiring Creds credentials and Roles
  • Generation of Approval approval records
  • Notification of Approvalsapprovals, Creds and Roles in an external company configurable waycredentials and roles to support configurable integration with external services.

8. References

1.  AAF Overview & User Guide: https://onap.readthedocs.io/en/latest/submodules/clamp.git/docs/index.html 
2. AAF internal interfaces:  https://onap.readthedocs.io/en/latest/_downloads/d3c9f924c6586fe411d40a05ad9b1bb7/swagger.pdf 

...