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 ?
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. Cheers, Kaz 2017-06-21 16:51 GMT+09:00 Steven Hardy <sha...@redhat.com>: > On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara <ksnhr.t...@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 > > __________________________________________________________________________ > 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