Hi Lukasz, > We decided to follow OpenStack approach where you authenticate > using keystone and then use only token to talk with services.
If some approach is used by OpenStack, it doesn't mean it's right. There were reasons to implement this way in OpenStack, and I don't see such reasons in Fuel (at least now). I mean, in OpenStack we have various services which interact with each other. Obviously, such interactions must be signed by some token. Therefore, we have a Keystone - a one source of truth. In Fuel we need authentication only for Nailgun and we don't need it for other parts of Fuel, right? If so, we don't need a separate authenticating service. Let's use Nailgun as a self-sufficient RESTful service. It will give us some benefits. 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. > 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ś -- 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