Open Stack

On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara <ksnhr.tech at gmail.com> wrote:
> 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?

I don't think it makes sense to have an enable/disable trusts config
option unless there is an alternative (e.g we've discussed oauth in
the past and in future there may be alternatives to trusts).

I guess if there was sufficient interest we could have some option
that blacklists all resources that require deferred authentication,
but I'm not sure folks are actually asking for that right now?

My preference is to deprecate deferred_auth_method, since right now
there's not really any alternative that works for us.

> Also I'm thinking that `reauthentication_method` also might be
> changed/merged ?

No, I think we still need this, because it is disabled by default -
this option allows you to enable defeating token expiry via trusts,
which is something an operator must opt-in to IMO (we should not
enable this by default, as it's really only intended for certain edge
cases such as TripleO where there are often very long running stack
operations that may exceed the keystone token expiry).

Steve