fuel-dev team mailing list archive

[Kamil Sambor <ksambor@xxxxxxxxxxxx>]

Hi all,

@Alexander
If you log off, the UI can also revoke the token using DELETE
/v2/tokens/<token>

Best regards,
Kamil Sambor

On Fri, Sep 26, 2014 at 9:15 AM, Alexander Kislitsky <
akislitsky@xxxxxxxxxxxx> wrote:

> I can answer on the 2-nd question:
>
> Tracking of the logout  can be useful for logs analyse - for example if
> token is used after logout - it can detect that token has been stolen.
> Tracking of login/logout is not required by stat collector but this
> information can be used for some analytic reports.
>
> On Fri, Sep 26, 2014 at 1:53 AM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx
> > wrote:
>
>> My 5 cents on this:
>>
>>    1. Why don't we drive such conversations in openstack-dev? We don't
>>    have Keystone devs in this mailing list, and it seems good general question
>>    which someone could help to resolve. My strong suggestion is to move to
>>    openstack-dev for other similar discussions. For example, subject could
>>    look like "[Fuel] [Keystone] Login and Logout actions are absent in Fuel's
>>    Nailgun" - and it could attract more people into discussion.
>>    2. Please someone explain to me why do we want to track logout action
>>    by stats collector
>>    3. Logout can be as simple as token removal from client cache (UI or
>>    CLI, no matter) - in case if don't need to track logout action. I think
>>    it's useful feature though - let's say, I'm using someone's browser, and
>>    don't want my token live there even another minute.
>>    4. Support of services discovery, multiple services authx in Keystone
>>    is mandatory for Fuel's future, as pointed out Lukasz. It fully aligns with
>>    my vision. Let me know if it is doable by the approach you are proposing.
>>    5. Benefits of switching over from what has been implemented are not
>>    clear to me. Please clarify.
>>
>> Thanks,
>>
>> On Thursday, September 25, 2014, Igor Kalnitsky <ikalnitsky@xxxxxxxxxxxx>
>> wrote:
>>
>>> Hi Lukasz,
>>>
>>> > If this doesn't convince you I don't know what can :)
>>>
>>> Actually, I understand your points and agree with some of them, but
>>> still think that we're doing that wrong way. But as I see, nobody
>>> cares and the team is ok with current approach. Let's keep things as
>>> they are, then.
>>>
>>>
>>> > we also will use keystone as service/endpoint discovery tool.
>>>
>>> Indeed, it's a cool possible usercase.
>>>
>>>
>>> > Do you now, that you are proposing to introduce backward
>>> > incompatible change?
>>>
>>> No, I don't know why it's backward incompatible change. If we add
>>> Nailgun auth logic which will use keystone inside - there's no
>>> incompatible changes, since we will still use keystone auth token.
>>>
>>>
>>> > Why do you need this in the first place? If you want to know when user
>>> is
>>> > using UI you can do it by adding special header in JavaScript client.
>>> > You can easly detect when user started and stopped using UI.
>>> > You can do the same with fuelclient.
>>>
>>> I'd prefer to refuse to count such metrics rather than use hacks in
>>> headers. :)
>>>
>>>
>>> Thanks,
>>> Igor
>>>
>>> On Wed, Sep 24, 2014 at 10:44 PM, Lukasz Oles <loles@xxxxxxxxxxxx>
>>> wrote:
>>> > Hi Igor,
>>> >
>>> > On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky <
>>> ikalnitsky@xxxxxxxxxxxx>
>>> > wrote:
>>> >>
>>> >> In Fuel we need authentication only for Nailgun and we don't need it
>>> >> for other parts of Fuel, right?
>>> >
>>> >
>>> > Actually no. Currently nailgun and ostf are using keystone for
>>> > authentication/authorization.
>>> > In next release we will introduce Plugin Manager which will be separate
>>> > service. It will also require
>>> > keystone.
>>> > So for now I know about 3 services.
>>> > Some advanced plugins with their own API will also require keystone.
>>> > Currently we are also working[1] on testing Fuel on large scale and we
>>> may
>>> > use Rally[2] for this. Rally requires keystone.
>>> > It uses it to discover nailgun service.
>>> > In future we may add to fuelclient  OSTF and Plugin support and we
>>> also will
>>> > use keystone as service/endpoint discovery tool. Anyone can use it
>>> this way,
>>> > as in OpenStack.
>>> > Also if someone comes to us from OpenStack world  he already knows
>>> what to
>>> > do. After all we are building OpenStack installation tool here.
>>> >
>>> > If this doesn't convince you I don't know what can :)
>>> >
>>> >>
>>> >>  For example, if we will decide
>>> >> to use Keystone v3 the only thing we will have to do is to change only
>>> >> Nailgun, not all clients.
>>> >
>>> > Actually keystone here is better than nailgun here  because it can
>>> support
>>> > many API versions. Do you now, that you are proposing to introduce
>>> backward
>>> > incompatible change?
>>> >
>>> > Why do you need this in the first place? If you want to know when user
>>> is
>>> > using UI you can do it by adding special header in JavaScript client.
>>> You
>>> > can easly detect when user started and stopped using UI. You can do
>>> the same
>>> > with fuelclient.
>>> > I don't see any reason to make such change.
>>> >
>>> > [1] https://review.openstack.org/#/c/119400/
>>> > [2] https://github.com/stackforge/rally
>>> >
>>> > Regards,
>>> >
>>> >> > We are currently fixing some small issues with our implementation[1]
>>> >>
>>> >> Thank you for the link! I'll take a look.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Igor
>>> >>
>>> >> On Wed, Sep 24, 2014 at 12:48 AM, Lukasz Oles <loles@xxxxxxxxxxxx>
>>> wrote:
>>> >> > Hi Igor,
>>> >> >
>>> >> > When we were designing this future (access control for Fuel) there
>>> was a
>>> >> > discussion about this. We decided to follow OpenStack approach
>>> where you
>>> >> > authenticate using keystone and then use only token to talk  with
>>> >> > services.
>>> >> > If you are using fuelclient or UI it's hidden from you as in
>>> OpenStack.
>>> >> >
>>> >> > We are currently fixing some small issues with our
>>> implementation[1].
>>> >> > Please
>>> >> > read the spec. You may suggest some changes which will help you with
>>> >> > statistics. Maybe cookies will help?  Vitaly can comment on it.
>>> Changing
>>> >> > nailgun API for me is the worst solution.
>>> >> >
>>> >> > [1] https://review.openstack.org/#/c/118284/
>>> >> >
>>> >> > Regards,
>>> >> >
>>> >> >
>>> >> > On Tue, Sep 23, 2014 at 9:28 PM, Igor Kalnitsky
>>> >> > <ikalnitsky@xxxxxxxxxxxx>
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi Lukasz,
>>> >> >>
>>> >> >> Thank you for the input. Actually I agree with you, but still I
>>> think
>>> >> >> there's something wrong with our current approach.
>>> >> >>
>>> >> >> I don't like that we work with keystone directly from UI and Fuel
>>> CLI.
>>> >> >> I believe there should be a Nailgun API for authenticating users.
>>> In
>>> >> >> deep of Nail Gun we can use Keystone for authenticating users and
>>> >> >> validating tokens, but not vice-versa.
>>> >> >>
>>> >> >> I mean there's something wrong if we don't provide authentication
>>> >> >> abstraction and use keystone directly in both server and client
>>> sides
>>> >> >> (Nailgun, CLI, UI, Upgrade Script, etc).
>>> >> >>
>>> >> >> What do you think about it?
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Igor
>>> >> >>
>>> >> >> On Tue, Sep 23, 2014 at 8:07 PM, Lukasz Oles <loles@xxxxxxxxxxxx>
>>> >> >> wrote:
>>> >> >> > Guys,
>>> >> >> >
>>> >> >> > there is no "logout issue". This is REST API. It is stateless.
>>> >> >> > There is no such thing like login or logout in REST API. You can
>>> only
>>> >> >> > get
>>> >> >> > authentication token. This token is only valid for a while. After
>>> >> >> > some
>>> >> >> > time
>>> >> >> > it will be outdated and you need to get new one. It doesn't mean
>>> that
>>> >> >> > user
>>> >> >> > login and logout every time, it only means that token is not
>>> valid
>>> >> >> > anymore
>>> >> >> > and you need new one.
>>> >> >> >
>>> >> >> > In 6.0 token will be valid for 24h, so when you will see new
>>> token it
>>> >> >> > means
>>> >> >> > user started using API again. That's all. You can easily
>>> calculate
>>> >> >> > when
>>> >> >> > user
>>> >> >> > started using API and when he ended. You don't need to add
>>> >> >> > login/logut
>>> >> >> > handlers. It's broken. REST API doesn't work this way.
>>> >> >> >
>>> >> >> > If we need add new handlers to API because of collecting data it
>>> >> >> > means
>>> >> >> > you
>>> >> >> > are doing something wrong.  Your code should't change anything
>>> in API
>>> >> >> > workflow.
>>> >> >> >
>>> >> >> > Regards,
>>> >> >> >
>>> >> >> > On Mon, Sep 22, 2014 at 12:59 PM, Igor Kalnitsky
>>> >> >> > <ikalnitsky@xxxxxxxxxxxx>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Hi folks,
>>> >> >> >>
>>> >> >> >> Today I took a look over "logout issue" [1] and figured out
>>> that we
>>> >> >> >> cannot implement it with current approach.
>>> >> >> >>
>>> >> >> >> In current approach both login and logout actions are handled
>>> by Web
>>> >> >> >> UI with direct requests to Keystone server [2].
>>> >> >> >>
>>> >> >> >> As far as I know, we want to track login/logout actions as a
>>> part of
>>> >> >> >> anonymous statistic [3], so we need to decide how to avoid this
>>> >> >> >> issue
>>> >> >> >> and make it fly.
>>> >> >> >>
>>> >> >> >> I think we need to implement login/logout handlers as a part of
>>> >> >> >> Nailgun API. A login handler should receive user credentials and
>>> >> >> >> make
>>> >> >> >> request to Keystone server in order to retrieve an auth token. A
>>> >> >> >> logout handler should mark the token as invalid and forbid any
>>> >> >> >> actions
>>> >> >> >> with this token.
>>> >> >> >>
>>> >> >> >> Fuel Web UI should work with login/logout handlers which are
>>> part of
>>> >> >> >> Nailgun, instead of working with Keystone directly.
>>> >> >> >>
>>> >> >> >> What do you think about it? Any ideas and suggestions are
>>> welcome!
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> [1]: https://bugs.launchpad.net/fuel/+bug/1370964
>>> >> >> >> [2]:
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> https://github.com/stackforge/fuel-web/blob/master/nailgun/static/js/app.js#L70
>>> >> >> >> [3]:
>>> https://blueprints.launchpad.net/fuel/+spec/send-anon-usage
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> - Igor
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Mailing list: https://launchpad.net/~fuel-dev
>>> >> >> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >> >> >> Unsubscribe : https://launchpad.net/~fuel-dev
>>> >> >> >> More help   : https://help.launchpad.net/ListHelp
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Łukasz Oleś
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Łukasz Oleś
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Łukasz Oleś
>>>
>>> --
>>> Mailing list: https://launchpad.net/~fuel-dev
>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>