<div dir="ltr"><div>Hi Rabi,<br><br><br></div><div>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>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>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` 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></div><div>Also I'm thinking that `reauthentication_method` also might be changed/merged ?<br><br></div><div>Regards,<br></div><div>Kaz Shinohara<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-16 14:11 GMT+09:00 Rabi Mishra <span dir="ltr"><<a href="mailto:ramishra@redhat.com" target="_blank">ramishra@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hi All,<br><br></div><div>As we know,  'deferred_auth_method=trusts' being the default, we use trust_auth_plugin whenever a resource requires deferred_auth (any resource derived from SignalResponder and StackResource). We also support 'deferred_auth_method=<wbr>password' where  'X-Auth-User'/username and 'X-Auth-Key'/password is passed in the request header and we then store them in 'user_creds' (rather than 'trust_id')  to create a 'password' auth_plugin when loading the stack with stored context for signalling. I assume for this very reason we've the '--include-pass' option in heat cli.<br><br></div><div>However, when using keystone session(which is the default), we don't have the above implemented with SessionClient (i.e to pass the headers). There is a bug[1] and patch[2]  to add this to SessionClient in the review queue. Aslo, we don't have anything like '--include-pass' for osc.<br></div><div><br></div><div>I've noticed that 'deferred_auth_method=<wbr>password' is broken and does not work with keystone v3 at all. As we don't store the 'user_domain_id/name' in 'user_creds', we can not even intialize the 'password' auth_plugin when creating the StoredContext, as it would not be able to authenticate the user without the user_domain[3].<br><br></div><div>I'm not sure whether this works with keystone v2 and anyone is using it or not. Keeping in mind that heat-cli is deprecated and keystone v3 is now the default, we've 2 options<br><br>1. Continue to support 'deferred_auth_method=<wbr>passsword' option and fix all the above issues.<br><br></div><div>2. Remove/deprecate the option in pike itlsef.<br><br></div><div>I would prefer option 2, but probably I miss some history and use cases for it.<br></div><div><br>Thoughts?<br></div><div><br><br>[1] <a href="https://bugs.launchpad.net/python-heatclient/+bug/1665321" target="_blank">https://bugs.launchpad.net/<wbr>python-heatclient/+bug/1665321</a><br><br>[2] <a rel="nofollow" href="https://review.openstack.org/435213" target="_blank">https://review.openstack.org/<wbr>435213</a><br><br>[3] <a href="https://github.com/openstack/heat/blob/master/heat/common/context.py#L292" target="_blank">https://github.com/openstack/<wbr>heat/blob/master/heat/common/<wbr>context.py#L292</a><span class="HOEnZb"><font color="#888888"><br clear="all"><br>-- <br><div class="m_5154500316831681597gmail-m_-1431543927473533894gmail_signature"><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div>
</font></span></div></div></div></div>
<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>