Open Stack

On Thu, Jun 29, 2017 at 4:13 AM, Kaz Shinohara <ksnhr.tech at gmail.com> wrote:
> Hi,
>
>> No, I think we still need this, because it is disabled by default -
>> this option allows you to enable defeating token expiry via trusts,
> My understanding for the current implementation is..
> `deferred_auth_method=trust` triggers getting trust_id and storing it in the db.
> `reauthentication_method=trust` triggers getting trust scoped token by
> taking the trust id(Allow reauthentication)
> Those looks somehow duplicated because trust_id is required only when
> you want to get the trust scoped token, it's ok for heat to get
> trust_id when he need to get trust scoped token, isn't it ?

No they are two different uses for the trust_id;

1. reauthentication_method unset (default) - we can get a trust scoped
token for deferred operations such as autoscaling, but we cannot
defeat the token expiry set by keystone by reauthenticating.

2. reauthentication_method=trusts - we can get a trust scoped token
for any operation (including those initiated by a user with a real not
trust scoped token), such that the token expiry set by keystone can be
defeated.

(2) is not a safe default, but it's useful for certain use-cases such
as TripleO where stack operations can take many hours.

> In case of removing the password authentication, why don't we remove
> `deferred_auth_method` from heat.conf and unify
> 'reauthentication_method' to triggers getting trust_id and getting
> trust scoped token.

Yes as I said before, we could remove deferred_auth_method but we
cannot remove reauthentication_method.

HTH,

Steve