text: On 06-Dec-2012, at 9:59 PM, Koushik Das <koushik.das@citrix.com> wrote:
  > Rohit,
  >
  > Can you explain the "admin" and "user" security level? I don't see that in.
  Koushik,
  That was part of Alex's talk on "The future of CloudStack Architecture", will ask him to share
  somewhere, I'm unable to find it myself.
  The FS document on that wiki page refers to this work, "packaging the commands per entity
  category".
  I'm not sure if we should do separate cmds per security level, but the idea is that certain
  apis should not be shipped with the user API server, so that would be the ultimate isolation
  or restriction of APIs.
  >From a sysadmins perspective, if we get it right the storyboard would be like this: they
  would install CloudStack and it would only have cloud-engine and nothing else, they can go
  ahead and install the mgmt API server which can be controlled via the UI or cloudmonkey, using
  which they can configure their hosts, zones, etc. If they want to have API servers for users,
  they can start a VM which would run user API server. The idea is that unless you want a service,
  CS should not start it, for ex. for their own consumption an org may not require an user API
  server. On each VM the user API server could have different sets of APIs served via different
  urls end points (like url/hr, url/mgmt, url/engg etc.) for users.
  > Is this just a classification in terms of packaging or will there be a separate class
  hierarchy for admin vs. user commands?
  Yes, that is finished now, about 300 apis.
  You may checkout the code from api_refactoring. But, Mice raised an interesting question about
  domain admins, which I'm not sure. Will discuss and get back on this. The assumption I made
  was domain and system admins are within the datacenter. If not, one solution is to run multiple
  mgmt servers (in VMs as a service) with different sets of whitelisted apis served on different
  end points.
  > Also will there be more stringent input validations/additional checks in user level APIs
  compared to admin ones?
  All the validations should be dealt by the API layer, cloud-engine should orchestrate and
  not do any checking.
  Regards.
  >
  > Thanks,
  > Koushik
  >
  > -----Original Message-----
  > From: Rohit Yadav [mailto:rohit.yadav@citrix.com]
  > Sent: Friday, December 07, 2012 1:37 AM
  > To: cloudstack-dev@incubator.apache.org
  > 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.
  >
  >
  > Regards.