Zhao, Below are the responses to your questions: 1. This project covers both the Authentication and Authorization of ONAP components/services, but from the project name, it seems that it only takes care of authorization. It would be great if we could figure out a better name matching its actual scope. However, this one is more like a comment rather than an issue.
AAF refers to the Authorization Service which covers permissions, etc. We package AAF with a Framework called "CADI", which gives clients a plugin architecture for Authentication and Authorization. CADI Authentication covers Basic Auth (User Password) but also 2-way Certificates (which will be part of any ONAP). In our AT&T Version, we also have 2 proprietary Identity Stores and protocols which we support for Single Sign-on capabilities, etc. Thus, any given CADI/AAF supported service can accept any of the plugin protocols on any given transaction... you are not limited to one at a time. Thus, as you suggest, the more accurate description would be "AAF Services accessed by CADI Framework". Limiting the name to "AAF" has helped people avoid one Acronym. 2. After going through the proposal, It seems not clear to me whether his project provides centralized authentication and centralized authorization for the ONAP components or not. If it does, how this project accomplish hat? As mentioned, CADI provides a plugin architecture for Authentication, because Authentication is fits hand-in-glove with Identity Management. CADI assumes that most companies would have their own Identity Management tools and stores, hence the Plugin mechanism. AAF (the service) does provide a Basic-Auth mechanism and a Client Certificate mechanism, which, at AT&T, we only use for application Identities. This is because AAF provides the ability to have multiple passwords viable at one time for the purposes of allowing Applications to run 24x7x365.25. Example: When a Password comes close to expiring, a new one is allowed to be created. Both are accepted. This gives the Application time to migrate the password change to its configurations and restart without need to take down the whole system. This is similar to replacing expiring Certificates. If required, either of these Authentication methods can be used exclusively, or, as we do in AT&T, delegate some identities to external Identity Stores, and some internally. AAF (the Authorization) is centrally stored relationships between the Identities above the Permissions they have through roles. Applications request this information from the AAF Service. Thus, both Authentication and Authorization are covered in a centralized manner, with a certain amount of flexibility for the implementers in terms of Identity Management. 3. From the information I got from last Friday's special meeting, this project will provide a framework/lib for every other project to use. So this project has impacts on the coding of all the other projects, could AAF team be more specific how will this project affect other projects on this aspect? Is it possible that ONAP could achieve centralized auth without impacts on each individual component/microservic? Using the CADI Framework and AAF provides a common way to implement security. This common way of implementing security for Applications does not impose specific coding behaviors on their clients. HTTP/S is still HTTP/S, Basic Auth (User/Password) is still Basic Auth, and Certificates are still Certificates. These are all Industry standard. If a client, i.e. a browser with no CADI Framework, accesses a component with HTTP/S and a User/Password, there is no difference between any other interaction for which HTTP/S and Basic Auth are the method of contact. The Application does, however, utilize AAF Service to determine exactly what the client (having Authenticated) may do within its own specific span of control. This is what we call "Fine-Grained Authorization", which AAF Provides. The Applications themselves determine what internal elements need protecting by Permission and are able to define them centrally. The client experience is only whether they are enabled to specific things or not, depending on whether they have been Authorized. There are advantages for all the components utilizing the same Authorization mechanism, but does not impact external Clients specifically. 4. Will this project provide API Token authentication? This may be needed because it's not every time a user is involved in the authentication process such as the authentication between third party apps and ONAP. OAuth2 compliant Token Authorization (and authentication, per spec) will be added to the Open Source AAF. Thanks Varun Gudisena Sr. Software Engineer (Contractor) AT&T Services, Inc. 211 S Akard St, Dallas ,TX 75202 Ph: 617-834-4157
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
