<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi Masahito, Tim.<br><br></div>Thanks for your messages.<br><br>>> btw, I added [Congress] prefix in the subject.<br><div>Firstly thanks for your point, I'm beginner openstacker. So this information is very useful.<br></div><br></div><div>Move to main topic.<br><br>>So as Masahito mentioned, if you provide more details about your use case<br>>(in particular what kinds of information you need for making authorization<br>>decisions), <br><br></div>I supposed that we use OpenStack as Public Cloud which have multiple tenants.<br></div>So The cloud administrator on OpenStack who have the admin role in OpenStack<br>and The deployer who is in charge of creating OpenStack environment and providing service are not same.<br>So we desire some mechanism to enable the admin on OpenStack in tenant (or domain) to specify which service(or function) can the user to use.<br></div><br></div>>the usual way to authorize API calls in OpenStack is<br>>through policy.json.  If I remember right, you can make a decision about<br>>whether an API call is permitted using (i) all the values in the API call<br>>and (ii) the Keystone role of the user making the request.  I'm not sure if<br>>you can also use the actual userID of the person making the request or not,<br>>but as soon as you get to 10 users, you'll end up grouping individual users<br>>into roles anyway.<br><br></div>Surely, The policy.json have potential to cover above our needs.<br></div>But as I mentioned before, the deployer and administrator of OpenStack isn't same.<br></div>And the deployer want to restrict the admin from login to the server which start up api processes.<br></div><div>So the admin on OpenStack can't login to the servers of working api process.<br><br></div></div><div>But it can't definitely realized by policy.json.<br></div><div>If we prepare the api server that works changing policy.json  and  provide the users.<br></div><div>But I think this solution isn't very good. <br></div><div>There are many reason of making this solution bad.<br>first reason is to make the rule of policy.json complex.<br></div><div>second reason is that policy file is <span class="">distributed in many server and many directory.<br></span></div><div><br><br></div><div>The reasons I'm interested in congress are followings.<br></div><div> - Congress can centrally manage policy rule.<br></div><div> - Congress can change policy or add policy via API.<br></div><div>So honestly I don't concern about dynamical policy (e.g. depending on the policy, which network is connected to) in our use-case.<br><br></div><div><br></div><div>if you'll allow a slight digression, <br>If we integrate authorization mechanism to actual environment,<br></div><div>we will prepare the translator from authorization specific policy to datalog and <br></div><div>we don't expose the congress in order to improve usability in the user perspective.<br></div><div><br></div><div>Can this mail give the image of what I want to do to you?<br><div><div><div><br><div><div><div><div><div>Yuki<br></div><div>------------------------<br>>Hi Yuki,<br>><br>>As Masahito mentioned, the usual way to authorize API calls in OpenStack is<br>>through policy.json.  If I remember right, you can make a decision about<br>>whether an API call is permitted using (i) all the values in the API call<br>>and (ii) the Keystone role of the user making the request.  I'm not sure if<br>>you can also use the actual userID of the person making the request or not,<br>>but as soon as you get to 10 users, you'll end up grouping individual users<br>>into roles anyway.<br>><br>>That said, Congress would be valuable for authorization decisions IF those<br>>decisions require information other than (i) values in the API call and<br>>(ii) the role of the user making the request.  For example, if you wanted<br>>to stop someone from deleting a Neutron network whenever there is a Nova VM<br>>attached to that network with status ACTIVE, then policy.json isn't<br>>adequate, and Congress makes sense.<br>><br>>So as Masahito mentioned, if you provide more details about your use case<br>>(in particular what kinds of information you need for making authorization<br>>decisions), we can help you pick the right tool.<br>><br>>Tim<br>><br>><br>><br>><br>>On Fri, Apr 15, 2016 at 1:06 AM Masahito MUROI <muroi.masahito at <a href="http://lab.ntt.co.jp">lab.ntt.co.jp</a>><br>>wrote:<br>><br>>> Hi Yuki,<br>>><br>>> This sounds interesting. AFAIK, there is no similar use-case you mentioned.<br>>><br>>> On 2016/04/15 10:13, Yuki Nisiwaki wrote:<br>>> > Hi openstacker working on congress.<br>>> ><br>>> > I want to implement the authorization mechanisms for each user, not role<br>>> > base.<br>>> > For example, User A can change security group, But User B can’t change<br>>> > security group like IAM feature of AWS.<br>>> ><br>>> > In order to achieve it,<br>>> > I’m considering whether can I utilize Congress feature.<br>>> > I am thinking somehow that I can achieve it by following step.<br>>> > 1. create policy for each user with datalog in congress<br>>> > 2. prepare the wsgi filter for each project that works confirming<br>>> > authorization of each user to Congress.<br>>> Could you clarify your usecase? I think it can be done by roles and<br>>> modifying policy.json. If you assume A and B are under some conditions,<br>>> what kind of condition do you want to use?<br>>><br>>> btw, I added [Congress] prefix in the subject.<br>>><br>>> ><br>>> > I think this use-case is very popular and there is someone who think<br>>> > same thing.<br>>> > But There is no information about it in any website (blog, presentation<br>>> > in summit).<br>>> > So why is there anyone who achieve it?<br>>> > or does this approach have anxious point?<br>>> > If you are interested in this approach or think same thing, I want to<br>>> > know it.<br>>> ><br>>> ><br>>> > Best regards<br>>> ><br>>> > Yuki Nishiwaki<br>>> > NTT Communitions<br>>> > Technology development<br>>> > Cloud Core Technology Unit<br>>> ><br>>> ><br>>> ><br>>> __________________________________________________________________________<br>>> > OpenStack Development Mailing List (not for usage questions)<br>>> > Unsubscribe:<br>>> OpenStack-dev-request at <a href="http://lists.openstack.org?subject:unsubscribe">lists.openstack.org?subject:unsubscribe</a><br>>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>>> ><br>>><br>>> best regards,<br>>> Masahito<br>>><br>>><br>>> --<br>>> 室井 雅仁(Masahito MUROI)<br>>> Software Innovation Center, NTT<br>>> Tel: +81-422-59-4539<br>>><br>>><br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request at <a href="http://lists.openstack.org?subject:unsubscribe">lists.openstack.org?subject:unsubscribe</a><br>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>>><br>>-------------- next part --------------<br>>An HTML attachment was scrubbed...<br>>URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160415/6e977044/attachment.html">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160415/6e977044/attachment.html</a>><br><br></div></div></div></div></div></div></div></div></div></div>