Project Name:

  • Proposed name for the project: Application Authorization Framework
  • Proposed name for the repository: AAF

Project description:

  • The goal of the project is to provide consistent authentication, authorization and security to various ONAP components. AAF organizes software authorizations so that applications, tools and services can match the access needed to perform job functions.  AAF is designed to cover Fine-Grained Authorization, meaning that the Authorizations provided are able to use an Application's detailed authorizations, such as whether a user may be on a particular page, or has access to a particular Pub-Sub topic controlled within the App. This is a critical function for Cloud environments, as Services need to be able to be installed and running in a very short time, and should not be encumbered with local configurations of Users, Permissions and Passwords. The sister framework CADI ( Code Access Data Identity ) allows Java Applications to utilize Identity Authentication methods as plugins. Certificate Manager delivers X.509 certificates in support of 2 way x509 TLS.

Scope:

The scope of the AAF project is a pluggable and extensible framework that

  1. Organizes software authorizations so that applications, tools and services can match the access needed to perform job functions
  2. Provides Enterprise Level Authentication and Authorization
  3. Provides Role based authorization, including attribute-based authorization elements
  4. The frameworks exposure layer should be consumable by any product or technology
  5. The frameworks should be highly available with a resilient data store
  6. Provides administration functions by GUI and management APIs
  7. Provides consistent client plugins to access authentication and authorization frameworks functions
  8. Provides support for multi-tenancy
  9. Provides support for SSL Certificate management
  10. Provides support for OAuth2
  11. Support Microservices ( Docker/Kubernetes )
  12. Provide hardware security plugin for storing private keys and for performing cryptography operations that require private keys
  13. Management of Secrets and Protection of Secrets

CADI ( Code Access Data Identity) - Addresses the Runtime Elements of Access and Identity.

  • Secure code by Reuse

  • Defend Access with Authentication and Authorization

  • Protect Data by ensuring TLS encryption over the wire

  • Ensure Apps protect resources for each Identity

  • CADI can handle multiple Authentication Protocols in the same service
  • Client Side Caching for Speed and less network access

Certificate Manager :

  • Creates certificates.
  • Eliminates Expiration Risk with Auto-Renewal

Entities within AAF

Namespaces

A Namespace, in AAF, is the ensemble of Roles, Permissions and Identities. Namespaces are known by domain, example com.onap.dcae or com.onap.appc and they are hierarchically managed.

A Namespace is assigned to an application. A namespace contains one or more roles and one or more permissions. By default, every namespace has an admin role

People in Namespaces

Tasks that the Owner (Responsible) must perform:
  • Owners receive by email a notification to Approve. 
  • Owners also receive notifications of time based activities
    • Periodic Revalidation of Users in Roles in Namespace
    • Periodic Revalidation of Permission in Namespace to Roles

Admin

Admins may

  • Create/Delete/Modify Roles in Namespace
  • Add/Remove Users from Roles in Namespace
  • Create/Delete/Modify Permissions in Namespace
  • Grant/Ungrant (i.e. Revoke) Permissions in Namespace to any Role in the company (Cross Company Role Grants are possible, but require approvals from both sides).

Object Model

In AAF, permissions are granted to roles. Roles are assigned to User. A user can be assigned to any number of roles. Roles and permissions are stored centrally but segregated by Application.

For authorization, all that matters is the permissions you are granted.

AAF is an Attribute Based Access Control System.  Permission is the embodiment of the Attribute.  It is broken up into three elements.

  • Type - This is the core name of the Permission, and describes its kind. The type is "meta-data" which is a reference to the kind of Resource that is to be protected
  • Instance - The object of the interaction. E.g. Database Table.
  • Action - What is happening to that object. E.g. read, write, delete, etc.

Interacting with AAF

AAF GUI

The AAF GUI is designed primarily to provide AAF-specific information to users, though it does contain a few management features.

What AAF-specific information can you see in the GUI?

You can see the roles to which you are assigned, the permissions which you have been granted and the Namespaces in which you are an admin or responsible party

What management features are in the GUI?

  1. My Approvals
    1. If you are responsible for any namespaces or other resources, this is where you will need to approve or deny requests about those resources.
  2. Password Management
    1. This page provides the ability to reset passwords.
  3. Permission Granting
    1. If you are an admin or responsible person for a Namespace, you will find a "Grant This Perm" link for each permission in your Namespace details page. You can grant your permission to a role from this page. You can also expose this link to others if you want them to request access to your permission

AAF CUI (Command User Interface)

The CUI provides more management and reporting features to users through a command prompt interface.

Application Authorization Framework Big Picture

Architecture Alignment:

How does this project fit into the rest of the ONAP Architecture?

AAF is used for fined grained authorization of an application. It can authorize DMaaP for pub/sub to a topic. It can authorize access to services registered in Microservices Bus.




  • What other ONAP projects does this project depend on?
    • Does not depend on any ONAP project.
  • How does this align with external standards/specifications?
    • X.509 Certificates
  • Are there dependencies with other open source projects?

    • Cassandra

    • DME ( Direct Messaging Engine, developed by "AT&T Common platform" Team )


Resources:

  • Primary Contact Person - Ram Koya(ATT), John Murray(ATT)
  • Names, gerrit IDs, and company affiliations of the committers
  • Names and affiliations of any other contributors
  • Project Roles (include RACI chart, if applicable)


NameGerrit IDCompanyEmailTime Zone
Ram Koya
AT&T

 rk541m@att.com

Dallas, USA
CST/CDT
John Murray
AT&T

 jfm@research.att.com

Bedminster, USA EST/EDT
Dominic Lunanuova
AT&T 

MiddleTown, USA EST/EDT

 Sitharaman

T R


 IBM tsithara@in.ibm.com

 Middletown,USA

EST/EDT

Other Information:

  • link to seed code: https://github.com/att/AAF
  • Vendor Neutral
    • The current seed code has been already scanned (using Fossology and Blackduck) and cleaned up to remove all proprietary trademarks, logos.
    • Subsequent modification to the existing seed code should continue to follow the same scanning and clean-up principles
  • Meets Board policy (including IPR)

Key Project Facts

Project Name:

  • JIRA project name: Application Authorization Framework
  • JIRA project prefix: AAF-

Repo name: org.onap.aaf
Lifecycle State: incubation
Primary Contact: Ram Koya
Project Lead: Ram Koya
mailing list tag [Should match Jira Project Prefix] 
Committers:

Ram Koya  rk541m@att.com 

Jonathan Gathman jg1555@att.com


Contributors:

Varun Gudisena vg411h@att.com

Sai Gandham sg481n@att.com

Sowjanya Vemulapally sv8675@att.com 

Sitharaman T R  tsithara@in.ibm.com

Catherine Lefèvre cl664y@intl.att.com 



*Link to TSC approval: 
Link to approval of additional submitters: 

  • No labels

17 Comments

  1. HuabingZhao

    Currently, users have to sign on every subsystem seperately such as SDC, A&AI, SO etc. Will this project consider providing sso(single sign on) for ONAP?

  2. Ramprasad Koya

    Yes, The scope includes providing SSO capability to all ONAP Systems.

  3. Sandeep Shah

    is it correct to assume that this project entails distributed RBAC across ONAP components but RBAC policies managed centrally? Meaning - a user, deployment/ops rep can access  ONAP components (that he is authorized to access) and perform actions (that he is authorized to perform)? RBAC policies will not be maintained per ONAP component instance, but in a logically central location? Would this be correct? Would appreciate clarification. Thank you.

    1. Varun Gudisena

      AAF is more than a typical RBAC. There are Roles, to be sure, but the important Architectural Pattern includes separation of Roles and Permissions. The permissions, having a 3 part definition, make AAF also like an ABAC (A=Attribute).
      Roles, Permissions are stored centrally, but segregated by Application (the proverbial Namespace). The Application Creates Permissions that match their code (for the question "Does User have Permission"). Permissions are granted to Roles, to which the User belongs.
      Only Namespace Admins may manage Roles/Permissions within a Namespace. The Granting process is One-Way. The Namespace Admins must Grant given Permissions to Roles on request.
      AAF is NOT a Policy Engine, where dynamically based Policies are validated against differing kinds of Data Stores. AAF (Application Authorization Framework) is focused on RealTime Authentication and Authorization. 

  4. Varun Gudisena

    Please find the answers for queries on Initial Project Proposal Feedback From the TSC. 

    1. Could the project proposal clarify how to enforce the auth of asyn message publishing/subscription and the sync REST requests separately?
      AAF usage within Sync/Async messaging, typically, an Application will use the CADI Framework (Think of this as AAF Client Library) to Authenticate and Authorize each and every incoming HTTP call. Caching is employed to avoid too many AAF Service Hits.

    2. Will this project enforce access control between the components inside the ONAP system, for example, the communication between SO and A&AI?

      Using AAF will force every interaction between Application/Components to be Authenticated and Authorized.

    3. Will this project implement centralized auth for all the ONAP components, or user need to log into every component? If that's the expectation, AAF may need to discuss with MSB team about the possibility of the AAF MSB integration approach for centralized auth, which is listed in the MSB use cases.

      Users, like Apps, need to be Authenticated and Authorized for each transaction as well. From an Application perspective, there is no real difference between the need to Authenticate and Authorize any given activity.

    4. is there any internal or external dependencies for this project?

      No

  5. Michael Behan

    Some points for consideration:

    1. The danger of assigning permissions to roles is that as systems grow, the volume of permissions and permission types also expands, which inevitably leads to role explosion.
    2. The permissions and role models can restrict future possibilities as evidenced by previous implementations of RBAC systems. Attempts to introduce revised models such as Hierarchical and Constrained RBAC have not been widely successful.
    3. As stated in the proposal, ABAC or attribute based access controls is welcomed. But should it be turned around as a classical RBAC model can be realised from a ABAC model. Thus, compatibility with existing systems can be preserved without limiting fine-grained authorization within ONAP hosted applications.
    4. ABAC also allows the separation of concerns - the authorization knowledge can be described in policy-form, the access-control can be implemented in by centralized and/or distrbuted policy decision points and the resources protected by AAF can be catalogued separately.
    5. Lastly, the architecture diagram has a statement that the Application should have knowldge of the permision a user has for a resource; this probably should be restated that an Application should only have knowledge of the decisions regarding a user's access to a resource. The permission should only be resolved by AAF (via policy or role assignment)

    These and other points are captured well in the NIST's Computer Security Division's analysis on ABAC: http://csrc.nist.gov/projects/abac/index.html


  6. HuabingZhao

     I understand that authentication and authorization are centralized enforced by AAF, and every microservice needs to use CADI to talk with AAF to accomplish that like the below diagram, is it correct?

    This approach is feasible but has some limitations, such as

    • Every microservice need to handle the authentication and authorization, although it was done by CADI framework.

    • Requires every microservice to use CADI framework.

    • Need to develop new CADI frameworks for other languages like python.

    • The change of AAF and CADI will impact every ONAP components, which means the upgrade of AAF/CADI will cause every microservice to recompile and redploy.

    • Make is hard to replace the auth service to other implementation, which may be needed if community user wants to integrate ONAP with their own system.


    A more flexible solution is to use the API Gateway as the entrypoint for centralized Authentication and Authorization, which can avoid all the above issues.

    This approach can reuse whatever AAF project already have and move the auth responsibility from all the microservices to api Gateway.

  7. maopeng zhang

    Is the AAF a micro service?  How could the other project consume the AAF? How could it effect the other projects, not written in java? 

    I think it needs to be more clear, thanks

    1. Jonathan Gathman

      AAF is a MicroService in the true sense of the word, such as limited scope, etc.  It was designed so before the term was popular.  

      1. For OpenSource, AAF is also running under K8, which is what some people believe a MicroService is.

      AAF itself (the Service) is a RESTful service, accessible by any technology able to utilize HTTP/S.  For Java, we have the CADI Framework, which supports multiple Authentication Protocols (BasicAuth, 2-way Certs, etc).  This framework in Java also provides Caching, etc, and clear use for J2EE security.

      If other non-Java technologies are needed, the principals of CADI could be applied, such as Caching (or Token use), appropriate retry/scalability/resiliency models, etc.


  8. Andrew Baxter

    The project describes itself as a pluggable and extensible framework. How do you plug a different Authentication and Authorisation provider into this framework/ONAP?

    Many Thanks!

    1. maopeng zhang

      No, I do not plug a different one.  

      Is the CADI used for the AAF to integrate with other projects?

      what's the API specification of CADI? Can it be invoked by python, or only by java?

      Thanks

    2. Jonathan Gathman

      The CADI Framework is a pluggable Framework, (AAF is the Authorization Service, and “pluggable” does not apply to AAF as a Service/MicroService).

      1. You create Classes based on “TAF” interfaces for Authentication
      2. You create Classes based on “LUR” interfaces for Authorization
      3. Combinations of these are plugged in at Runtime based on Property Configurations

      This enables services to serve different Authentication/Authorization needs in Realtime without having to create separate Services for each combination.

      1. Andrew Baxter

        Hi Jonathan,

        Thanks for this - sounds promising - can you point me at more details?

  9. Hu To

    HI,

    Is AAF mandatory in the Beijing version? Can we discard AAF if we want a lightweight deployment environment?

    1. Jonathan Gathman

      AAF is used for Authentication and Authorization.  What you are really saying is that you would want a system without Authentication or Authorization, in other words, no security at all.  While you could do that to play with, there is no way we could recommend that for any serious installation.

      Casablanca includes more integration than Beijing.

      1. Srinivasa Addepalli

        Hi Jonathan,

        Is it possible to run other services without AAF? I thought services connect to AAF for RBAC decisions. Is there any way to inform services not to call AAF?

        Thanks
        Srini

  10. MANOJ731153 JENA

    Hi,

    Is AAF supporting multi-tenancy for Honolulu release ? if yes then is there any use case (How to test whether its supporting multi-tenancy or not) for the same .


    Regards,

    Manoj