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
