Hi Rabi,
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. 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. 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. 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. 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? Also I'm thinking that `reauthentication_method` also might be changed/merged ? Regards, Kaz Shinohara 2017-06-16 14:11 GMT+09:00 Rabi Mishra <ramis...@redhat.com>: > Hi All, > > 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=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. > > 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. > > I've noticed that 'deferred_auth_method=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]. > > 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 > > 1. Continue to support 'deferred_auth_method=passsword' option and fix > all the above issues. > > 2. Remove/deprecate the option in pike itlsef. > > I would prefer option 2, but probably I miss some history and use cases > for it. > > Thoughts? > > > [1] https://bugs.launchpad.net/python-heatclient/+bug/1665321 > > [2] https://review.openstack.org/435213 > > [3] https://github.com/openstack/heat/blob/master/heat/common/ > context.py#L292 > > -- > Regards, > Rabi Mishra > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
