<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 11:03 PM, Qiu Yu <span dir="ltr"><<a href="mailto:unicell@gmail.com" target="_blank">unicell@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Fri, Dec 13, 2013 at 2:40 AM, Morgan Fainberg <span dir="ltr"><<a href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a>></span> wrote:<br>




<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="font-size:13px;margin:0px;font-family:Helvetica,Arial">




As Dolph stated, V3 is where the policy file protects.  This is one of the many reasons why I would encourage movement to using V3 Keystone over V2.</div><div style="font-size:13px;margin:0px;font-family:Helvetica,Arial">




<br></div><div style="font-size:13px;margin:0px;font-family:Helvetica,Arial">The V2 API is officially deprecated in the Icehouse cycle, I think that moving the decorator potentially could cause more issues than not as stated for compatibility.  I would be very concerned about breaking compatibility with deployments and maintaining the security behavior with the encouragement to move from V2 to V3.  I am also not convinced passing the context down to the manager level is the right approach.  Making a move on where the protection occurs likely warrants a deeper discussion (perhaps in Atlanta?).</div>




<div style="font-size:13px;margin:0px;font-family:Helvetica,Arial"><br></div></div></blockquote><div><br></div></div><div>Thanks for the background info. However, after a quick go-through keystone V3 API and existing BPs. Two questions still confuse me regarding policy enforcement.</div>




<div><br></div><div>#1 Seems V3 policy api [1] has nothing to do with the policy rules. It seems to be dealing with access / secret keys only. So it might be used for access key authentication and related control in my understanding.</div>




<div><br></div><div>Is there any use case / example regarding V3 policy api? Does it even related to policy rules in json file?</div></div></div></div></blockquote><div><br></div><div>The v3 policy API is intended to replace policy.json by centralizing the persistence and management of policy rule sets.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>#2 Found this slides[2] online by Adam Young. And in page 27, he mentioned "isAdmin" currently in nova belongs to keystone actually.</div>




<div><br></div><div>Would be really appreciated for some pointers. ML discussion or bp (I don't find any so far), etc.</div><div><br></div><div>[1] <a href="http://api.openstack.org/api-ref-identity.html#Policy_Calls" target="_blank">http://api.openstack.org/api-ref-identity.html#Policy_Calls</a><br>




</div><div>[2] <a href="http://www.slideshare.net/kamesh001/openstack-keystone" target="_blank">http://www.slideshare.net/kamesh001/openstack-keystone</a><br></div><div><br></div><div>Thanks,</div><div>--</div><div>Qiu Yu</div>



</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>