Hi All,

I have been following the IAM functionality work from quite sometime.
And I am interested in this work and would like to contribute in the API
changes and discussions.
If there are any design documents or any Jira tickets related to these
changes can you please point me to them that will be helpful.

>From looking over the API changes documentation for the IAM feature I was
curious if everything you set out to accomplish that is mentioned
here https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes is
completed ?

Thanks
Meghna.



On Thu, Jun 5, 2014 at 11:03 PM, Prachi Damle <prachi.da...@citrix.com>
wrote:

>
>
> -----Original Message-----
> From: Meghna Kale [mailto:meghna.k...@sungardas.com]
> Sent: Wednesday, June 04, 2014 11:24 PM
> To: dev
> Cc: Daan Hoogland; Hugo Trippaers
> Subject: Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
>
> Thanks Min and Prachi.
>
> >Based on above, for your usecase, you can attach a new policy to one
> account to deny specific operations. So even if that account belongs to
> the group that allows All, the second >policy has an explicit Deny, so this
> will deny the specific operations.
>
> Does that mean that a new deny permission role should be created and then
> applied to the user? If yes then is it like we are apply two roles to a
> single user.
>
> >> Yes it means attaching two policies to the account. The policy
> evaluation logic should look at all the policies attached and evaluate
> using the precedence.
>
> Thanks
> Meghna.
>
> Thanks
> Meghna.
>
>
>
> On Thu, Jun 5, 2014 at 1:19 AM, Prachi Damle <prachi.da...@citrix.com>
> wrote:
>
> > >For example, there are two accounts and they belong to a group with
> > >Allow all permissions. If I have to remove some permissions for only
> > >account 1 but keep them for account 2 is it possible?
> >
> > This will be decided depending on whether Deny has higher precedence
> > over Allow or the other way. If Deny has the higher precedence, the
> > evaluation logic will be:
> > - If there is a policy attached to the account or to a group that the
> > account belongs to, which states an explicit Deny, then the permission
> > will be denied.
> >
> > Based on above, for your usecase, you can attach a new policy to one
> > account to deny specific operations. So even if that account belongs
> > to the group that allows All, the second policy has an explicit Deny,
> > so this will deny the specific operations.
> >
> > Thanks,
> > Prachi
> >
> > -----Original Message-----
> > From: Min Chen [mailto:min.c...@citrix.com]
> > Sent: Tuesday, June 03, 2014 9:30 AM
> > To: dev@cloudstack.apache.org
> > Cc: Daan Hoogland; Hugo Trippaers
> > Subject: Re: [ACS5.0] IAM feature postponed from 4.4 to 5.0?
> >
> > As mentioned in our FS doc in wiki, "In phase I, all the permissions
> > attached to any policy are by default explicit 'Allow' permissions. As
> > of now 'Deny' permissions cannot be added."
> >
> > For your use cases, you can have two options:
> > 1. Assign the two accounts into 2 different groups,  and attach
> > different policy for the group.
> > 2. Directly attach an Allow policy to account 2 instead of assigning
> > both accounts into the Allow All group.
> >
> > Thanks
> > -min
> >
> >
> > On 6/3/14 5:03 AM, "Meghna Kale" <meghna.k...@sungardas.com> wrote:
> >
> > >Hi Min,
> > >
> > >With reference to the wiki doc, I had a query.
> > >In case of a customized role with deny permissions how will the
> > >listAll, isrecursive ..etc. input parameters values will be ?
> > >
> > >For example, there are two accounts and they belong to a group with
> > >Allow all permissions. If I have to remove some permissions for only
> > >account 1 but keep them for account 2 is it possible?
> > >
> > >Thanks
> > >Meghna.
> > >
> > >
> > >On Thu, May 22, 2014 at 10:22 PM, Min Chen <min.c...@citrix.com> wrote:
> > >
> > >> Added API issues we found through IAM feature in the wiki page
> > >>created by
> > >> Demetrius:
> > >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes
> > >>
> > >> Thanks
> > >> -min
> > >>
> > >> On 5/14/14 9:34 AM, "Min Chen" <min.c...@citrix.com> wrote:
> > >>
> > >> >Thanks Daan. Yes, I saw that there is another thread about putting
> > >> >an
> > >>API
> > >> >request for 5.0 api. Once we are done with this disabling, we will
> > >> >put
> > >>the
> > >> >issues we have found with current API in that wiki page to take
> > >> >into consideration when we design the new API.
> > >> >
> > >> >-min
> > >> >
> > >> >On 5/14/14 12:12 AM, "Daan Hoogland" <daan.hoogl...@gmail.com>
> wrote:
> > >> >
> > >> >>Min,
> > >> >>
> > >> >>I think everybody knows I am all for less features per release. I
> > >> >>don't think you are making a bad call, per se. I do think we
> > >> >>should consider if we can come up with a total picture of what
> > >> >>5.x would require af the api, though. Can you add to the
> > >> >>discussion what it is that is keeping you from implementing. And
> > >> >>what requirements you have for the 5.0 api so we can start
> > >> >>devising the architectural guidelines for the new api. more and
> > >> >>more calls for a 5.0 are coming up lately so let's move forward.
> > >> >>(changing title)
> > >> >>
> > >> >>On Wed, May 14, 2014 at 1:53 AM, Min Chen <min.c...@citrix.com>
> > wrote:
> > >> >>> Hi All,
> > >> >>>
> > >> >>> In the past several weeks, QA has done some testing on IAM
> > >> >>> feature
> > >>and
> > >> >>>found
> > >> >>> several backward-compatibility issues. Even though Prachi and I
> > >> >>>have tried  our best to fix bugs to maintain backward
> > >> >>>compatibility, we realized that in  order to support true IAM
> > >> >>>model documented in our FS
> > >> >>>
> > >> >>>
> > >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+I
> > >> de
> > >> nti
> > >> >>>t
> > >> >>>y+and+Access+Management+%28IAM%29+Plugin,
> > >> >>> we will have to make several API changes that will require us
> > >> >>>to increment  CloudStack major version.
> > >> >>> Therefore we think that IAM feature is not ready for ACS 4.4
> > >>release,
> > >> >>>and we
> > >> >>> would like to propose to disable it in 4.4 branch and re-enable
> > >> >>>it later  when community decides to go for 5.x.
> > >> >>>
> > >> >>> Thanks
> > >> >>> -min
> > >> >>
> > >> >>
> > >> >>
> > >> >>--
> > >> >>Daan
> > >> >
> > >>
> > >>
> > >>
> >
> >
> >
>

Reply via email to