Alex, Got it, very clear now and hope this clarification will be updated on the wiki.
Regards Mice -----Original Message----- From: Alex Huang [mailto:[email protected]] Sent: Saturday, December 08, 2012 8:47 AM To: [email protected] Subject: RE: Arch Rework RFC: API refactoring updates Mice, Please take a look at my email reply to Dave. There's no implied ACL in this separation. --Alex > -----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
