Mice, Thanks for the feedback. See Alex's comments, he clarified several points.
The packaging of the commands itself does not provide role-based access control. The API server contains the logic To do access control. Thanks, -Fang -----Original Message----- From: Mice Xia [mailto:[email protected]] Sent: Friday, December 07, 2012 4:36 PM To: [email protected] Subject: RE: Arch Rework RFC: API refactoring updates Fang, I vote for the second way, to keep it simple and clear, each API server has the same binary artifacts and contains all API implementations, access control is based on RBAC/ACL, and blacklist(white List) can be defined on a per API server basis. And perhaps we don’t need to explicitly package classes by roles ( or security level), this seems to hardcode APIs' ACL in the code level. My 2 cent. -Mice -----Original Message----- From: Fang Wang [mailto:[email protected]] Sent: Saturday, December 08, 2012 7:44 AM To: [email protected] Subject: RE: Arch Rework RFC: API refactoring updates Hi Mice, For now, we just separate the API into 2 roles: user and admin. The admin can be separated further into root admin, domain admin, etc. Further dynamic roles can be added. Once the framework is there, we can further separate the admin roles. Per your question, there can be 2 ways to handle the domain admin requests: - one is like you mentioned, sysadmin has separate api servers to handle user and domain api requests separately. - Another way is to deploy one api server, and the api server does the role base access check. So user cann't access the domain Admin apis., the access would be blocked and denied. The advantage of this method is the flexibility. E.g, add another new domain, or a new category admin, we can dynamically deploy and apply the roles. Thanks, -Fang -----Original Message----- From: Mice Xia [mailto:[email protected]] Sent: Thursday, December 06, 2012 5:15 PM To: [email protected] Subject: Re: Arch Rework RFC: API refactoring updates rohit, i asked this question because requests from domain admins are usually from outside of datacenter for a public cloud. so artifact built from user package can be directly deployed as a user api server and serve user requests. but to serve domain admin request, sysadmin has to prepare another api server with another set of apis, which is a sub set of admin package, is this correct? sent from phone, sorry for typos. mice 在 2012年12月7日星期五，Rohit Yadav <[email protected]> 写道： > > On 06-Dec-2012, at 4:29 PM, Mice Xia <[email protected]> wrote: > >> [quote] >> 1. Moved and classified all apis (except the anomalies, see other >> email) into namespace org.apache.cloudstack.api 2. There are two packages, admin and user in which the APIs are grouped based on security level. Note; APIs are not grouped based on roles. >> - Because of 1,2,3; there would be two classes of API server. The >> first one would be available for users, the user API server which would handle requests from network outside the datacenter which Alex refers to as "over the wire" requests. The second one would be available for sysadmins, the mgmt API server which would handle requests from admins/sysadmins within the datacenter; >> [/quote] >> >> I haven’t seen the codes, just one question. >> If the intention is to deploy API server separately based on the security level, where are APIs enabled for domain-admin located? In the user package or in the admin package? > > The admin package. For domain-admin etc. the sysadmin would run mgmt servers with different sets of apis s/he wants to provide for a domain admin. There won't be any pre configured set of apis, this would allow a system admin to decide exactly what level of access s/he wants to provide to a domainadmin role user. This allows him/her to create multiple end points of mgmt server as well, just like the user api server. > > Regards. > >> >> Regards >> Mice >> >> -----Original Message----- >> From: Rohit Yadav [mailto:[email protected]] >> Sent: Friday, December 07, 2012 4:07 AM >> To: [email protected] >> Subject: Arch Rework RFC: API refactoring updates >> >> Few updates; >> >> 1. Moved and classified all apis (except the anomalies, see other >> email) into namespace org.apache.cloudstack.api 2. There are two packages, admin and user in which the APIs are grouped based on security level. Note; APIs are not grouped based on roles. >> 3. Further in each org.apache.cloudstack.api.{admin,user}.command >> pkg, the APIs are grouped as per api affinity (for ex. all vm related ones in vm pkg). >> 4. Few usage related APIs could not be moved from cloud-server to cloud-api, as they are tightly coupled with classes available in cloud-server. >> 5. commands.properties is fixed. >> 6. Checked, the api_refactoring merges fine with a minor merge conflicts. The build on the branch is broken, would be fixed soon. >> >> I request that if you're adding any new class, please use the >> namespace org.apache.cloudstack. >> >> Road ahead: >> - Because of 1,2,3; there would be two classes of API server. The >> first one would be available for users, the user API server which would handle requests from network outside the datacenter which Alex refers to as "over the wire" requests. The second one would be available for sysadmins, the mgmt API server which would handle requests from admins/sysadmins within the datacenter; >> >> user API server would use only the org.apache.cloudstack.api.user artifact admin API server would use both org.apache.cloudstack.api.admin and org.apache.cloudstack.api.user Based on the arch. rework docs, ppts, talks, Alex's idea was to separate api based on security level would give ultimate isolation. >> >> - Separate out cloud-api, and make it run as a separate web app like awsapi. >> - Annotations and separation of API based on api affinity would help automate apidoc generation, api discovery over an api endpoint, so clients (UI or cloudmonkey etc.) would be able to discover >> - The commands.properties syntax is horrible, I want to get rid of >> the evil syntax by having an apiname annotation for all API Cmd classes and the API server would be able to load this info during runtime. In commands.properties, we should be just able to set policy for user role for each api, if apiname is not declared it's blacklisted. It becomes tricky with plugins. I don't know how to get it right the first time, but let's try. >> - ACL and security checking at API layer, the requests would be just passed to (multiple) cloud-engine which won't handle them, as that will only orchestrate. >> - Roles would be decided from commands.properties. Multiple API >> servers can be run with different combination of rules in commands.properties. This would allow separation of policy from mechanism, and multiple roles and end points. For example, an admin can create http routers for these api server, so: <url>/hr, <url>/finance, <url>/marketting can be proxies to different user api servers with different set of whitelisted apis. >> >> Comments, suggestions, flames? >> >> Regards. > > -- Sent from Gmail Mobile
