Hi Malini,<div><br></div><div>That is an interesting use case. It is sort of like Trusts, in that the customer rep has a diminished form of the users privileges (can't see credit card details), but has some additional privileges the user wouldn't have. Since the customer rep use case involves a third person interacting with the system, it seems like the right way to provide this feature would be to define a role for the privileges you want (can see line items, can't see financial info, can give refund) and give that role to the customer representative for the user's tenant.</div>
<div><br></div><div>However, in the explicit impersonation case, I'm hesitant to just give Nova a role on every tenant that allows it to download and upload images. If a bug in Nova somehow allowed a user in tenant1 to trigger these actions for tenant2, that would represent a means of attack. Ideally, Glance would authenticate a request and authorize an action based on both the identity of the proximate user (Nova) and the ultimate user (a customer who triggers a nova build/snapshot). That would provide more protection.</div>
<div><br></div><div>-Mark</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 8, 2012 at 12:51 AM, Bhandaru, Malini K <span dir="ltr"><<a href="mailto:malini.k.bhandaru@intel.com" target="_blank">malini.k.bhandaru@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Mark, this notion of impersonation with different levels of privileges (higher, lower, different functions) is also encountered in customer service.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">For example, you can view your credit card details and line items, but your credit card customer rep (phone or online chat/email)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Can see only your line items, to help with a dispute and grant a refund (in this case privileges and an additional privilege).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">If we have more such use cases, I can see a tenant seeking assistance with the cloud provider for issues with their VMs and charges, and not<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Needing to build an additional authentication/support infrastructure for the same.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Malini<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Mark Washenberger [mailto:<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>]
<br>
<b>Sent:</b> Friday, December 07, 2012 8:53 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] Trusts and Explicit Impersonation<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hi auth guys!<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As we continue to make progress towards large service providers exposing their Glance deployments as public services, one critical feature we need to support is the ability to limit certain actions (mostly image uploads, also possibly image
downloads) to use by Nova or other trusted services, and restrict users from taking those actions directly. Of course, this feature would only be turned on by configuration, and not likely by default.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I had figured we could do this using some features piggy-backed on keystone pki, and documented the use case in this blueprint:
<a href="https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonation" target="_blank">
https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonation</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I've been following the discussion of Keystone Trusts with interest, and some questions have presented themselves. Is there some way we could manipulate the Trust mechanism to provide the auth feature Glance needs? Another (scarier for
me) question: does the Trusts proposal conflict with my feature request?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks!<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Mark<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>