Yeah, the decoupling brought by API gateway seems very helpful for individual micro service design/development. And the token issue/revocation are important functions worthy to expose in the similar way.
Xinhui From: <[email protected]> on behalf of Jason Hunt <[email protected]> Date: Friday, 30 June 2017 at 10:53 PM To: "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [onap-tsc] Application Authorization Framework Are there responses to Huabing's proposal below? For external systems calling into ONAP, it seems the approach Haubing suggests -- whereby the External API Gateway does authentication and authorization using AAF -- is a prudent one & a very typical capability for API gateway. Regards, Jason Hunt Executive Software Architect, IBM Phone: +1-314-749-7422 Email: [email protected] Twitter: @DJHunt ----- Original message ----- From: <[email protected]> Sent by: [email protected] To: [email protected], <[email protected]> Cc: [email protected], [email protected] Subject: Re: [onap-tsc] Application Authorization Framework Date: Thu, Jun 29, 2017 6:07 AM Hi Varun, Thanks for your answers. Now 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? Image.00100001d7ec43e923c3730a1.other<cid:00100001d7ec43e923c3730a1> 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. Image.00100001d7ec43e923c3730a4.other<cid:00100001d7ec43e923c3730a4> Image.00100001d7ec43e923c3730a6.other<cid:00100001d7ec43e923c3730a6> That's my two cents. I might be wrong because I am not familiar with AAF, so please correct me if some of the above descriptions was wrong. What do you think of it? Thanks, Huabing Original Mail Sender: <[email protected]>; To: zhaohuabing10201488; CC: <[email protected]>; <[email protected]>; <[email protected]>; Date: 2017/06/29 02:09 Subject: [onap-tsc] Application Authorization Framework 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=14DWHoQdlEcTDc7RcGLzzkS0IMYLAIocLc5dNQRKqgk&m=Wpb0Vj2oP1NbwNWMNHqgrD1CFbNZ48J5t1xZYJkntt4&s=_7Etvyh6F4dQjgSRncLovCW_4iXPH3BVIgNFQGRTxoI&e=>
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
