Hi all, @Mike,
> 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. I thought we shouldn't spam openstack-dev ML with such questions, since it's about our internal design. > 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. I guess the topic is over. I mean, we discussed it. If we're going to use Keystone's service discovery feature - I'm ok with it; it may help us to get rid of hardcoded IP/Port values. @Lukasz, > This is how it works now. If you press logout on browser, token is deleted. Actually, it's far from what we have now. If I understand correctly our JavaScript code [1], we just remove token from the browser storage and that's all. I mean, the token is removed from browser but still valid and can be use to sign API requests. So I propose to fix it as a part of Lukasz's blueprint [2]. [1]: https://github.com/stackforge/fuel-web/blob/a8226df578e63031d8c7189814d03d6f2ffee29e/nailgun/static/js/app.js#L181 [2]: https://review.openstack.org/#/c/118284/ Thanks, Igor On Fri, Sep 26, 2014 at 10:15 AM, Alexander Kislitsky <akislit...@mirantis.com> 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 <mscherba...@mirantis.com> > 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 <ikalnit...@mirantis.com> >> 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 <lo...@mirantis.com> wrote: >>> > Hi Igor, >>> > >>> > On Wed, Sep 24, 2014 at 8:58 AM, Igor Kalnitsky >>> > <ikalnit...@mirantis.com> >>> > 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 <lo...@mirantis.com> >>> >> 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 >>> >> > <ikalnit...@mirantis.com> >>> >> > 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 <lo...@mirantis.com> >>> >> >> 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 >>> >> >> > <ikalnit...@mirantis.com> >>> >> >> > 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@lists.launchpad.net >>> >> >> >> 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@lists.launchpad.net >>> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~fuel-dev >> More help : https://help.launchpad.net/ListHelp >> > -- Mailing list: https://launchpad.net/~fuel-dev Post to : fuel-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp