<div dir="ltr">HI all,<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 16/06/17 05:09, Kaz Shinohara wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I still takes `deferred _auth_method=password` behalf of trusts because we don't enable trusts in the Keystone side due to some internal reason.<br>
</blockquote>
<br></span>
Free advice: whatever reason you have for not enabling trusts, storing user passwords in the Heat database is 100x worse.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The issues what you pointed are correct(e.g. user_domain_id), we don't use the domain well and also added some patches to skip those issues.<br>
</blockquote>
<br></span>
Why aren't those upstream?<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
But I guess that the majority of heat users already moved to trusts and it is obviously better solution in terms of security and granular role control.<br>
As the edge case(perhaps), if a user want to take password auth, it would be too tricky for them to introduce it, therefore I agree your 2nd option.<br>
<br>
If we will remove the `deferred_auth_method=password<wbr>` from heat.conf, should we keep `deferred_auth_method` self or will replace it to a new config option just to specify the trusts enable/disable ? Do you have any idea on this?<br>
Also I'm thinking that `reauthentication_method` also might be changed/merged ?<br>
<br>
Regards,<br>
Kaz Shinohara<br>
<br>
<br></span>
2017-06-16 14:11 GMT+09:00 Rabi Mishra <<a href="mailto:ramishra@redhat.com" target="_blank">ramishra@redhat.com</a> <mailto:<a href="mailto:ramishra@redhat.com" target="_blank">ramishra@redhat.com</a>>>:<br>
</blockquote>
<br>
[snip]<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not sure whether this works with keystone v2 and anyone is using<br>
it or not. Keeping in mind that heat-cli is deprecated and keystone<br>
v3 is now the default, we've 2 options<br>
<br>
1. Continue to support 'deferred_auth_method=passswor<wbr>d' option and<br>
fix all the above issues.<br>
<br>
2. Remove/deprecate the option in pike itlsef.<br>
<br>
I would prefer option 2, but probably I miss some history and use<br>
cases for it.<br>
</blockquote>
<br></span>
Am I right in thinking that any user (i.e. not just the [heat] service user) can create a trust? I still see occasional requests about 'standalone mode' for clouds that don't have Heat available to users (which I suspect is broken, otherwise people wouldn't be asking), and I'm guessing that standalone mode has heretofore required deferred_auth_method=password.<br></blockquote><div><br></div><div>When trusts are enabled, generally any user can create a trust to any other user, but only with itself as trustor - there's a strict rule for that in default keystone policy.json [0]. The only other reason that might block this is when the user is already a trustee, and trust chaining is disabled or already exhausted for this trustee. A tiny problem might be that it seems you need to know both the user_id/project_id of trustor (can be resolved by trustor itself) and the user_id of trustee - which is generally impossible for non-admin users, so a trustee must give the trustor its id.</div><div><br></div><div>[0] <a href="http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138">http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json#n138</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So if we're going to remove the option then we should probably either officially disown standalone mode or rewrite the instructions such that it can be used with the trusts method.<br>
<br>
cheers,<br>
Zane.<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div>Cheers,</div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Dr. Pavlo Shchelokovskyy<div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div></div>
</div></div>