fuel-dev team mailing list archive

[Lukasz Oles <loles@xxxxxxxxxxxx>]

As Kamil sugested we can use keystone API do delete token if it's
required. But if you really want to increase Fuel Master node security
I propose to implement HTTPS. We even have blueprint[1] for this.
Sebastian is author of it and he can provide more info.

If you really need to know when tokens are created and deleted(if we
add this) you can use keystone event mechanism[2]. We already have
rabbitmq and oslo.mesasging in the Fuel. It's even better because it's
done in async way.

[1] https://review.openstack.org/#/c/119330/
[2] http://docs.openstack.org/developer/keystone/event_notifications.html

Regards,

On Fri, Sep 26, 2014 at 7: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:
>>
>> 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.
>> Please someone explain to me why do we want to track logout action by
>> stats collector
>> 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.
>> 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.
>> 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
>



-- 
Łukasz Oleś