Open Stack

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 <ramishra at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170616/4f17e60d/attachment.html>