Open Stack

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 <shardy at redhat.com>:
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev