On Thu, Jun 29, 2017 at 4:13 AM, Kaz Shinohara <ksnhr.t...@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 __________________________________________________________________________ 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
