Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

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

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

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.

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

On Fri, Jun 16, 2017 at 10:09 AM, Kaz Shinohara 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.

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

On Fri, Jun 16, 2017 at 7:03 PM, Zane Bitter wrote: [snip] > > 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.

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

Hi team, >> Free advice: whatever reason you have for not enabling trusts, storing >> user passwords in the Heat database is 100x worse. Thank you, your point sounds reasonable. Of course we don't like to store our customer's credentials in Heat DB, event though those are encrypted. This is one

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

HI all, On Fri, Jun 16, 2017 at 4:33 PM, Zane Bitter wrote: > On 16/06/17 05:09, Kaz Shinohara wrote: > >> 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. >> > > Free advice:

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

On 16/06/17 05:09, Kaz Shinohara wrote: 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. Free advice: whatever reason you have for not enabling trusts, storing user passwords in the Heat database

Re: [openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

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.

[openstack-dev] [heat] Deprecate/Remove deferred_auth_method=password config option

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