Authentication for thermos webui

[Bhuvan Arumugam <bh...@apache.org>]

Hello,
We are implementing cookie based authentication for thermos webui
(port: 1338). It is a single sign-on implementation. The
unauthenticated users will be redirected to a login service. After
user is successfully authenticated in the login service, a cookie will
be added in this domain. The cookie is validated against the login
service, before the page is rendered.

I wish to get input on the design we are planning to implement, for
thermos webui. Ideally, we want to grant access to thermos webui only
for authenticated users.

Thermos use twitter.common.http library to render the UI, which use
bottle web framework and server. The html pages are generated using
bottle templates.

We could implement authentication in 2 ways.

1. The authentication can be implemented as a bottle plugin, within
thermos code base. The plugin can be installed for each route defined
for different web pages. This way, we could avoid making changes
directly to twitter.common.http library. We should install this plugin
for newer routes/pages added in future.
2. The authentication can be implemented as a bottle plugin, within
twitter.common.http library. The plugin can be installed, per
application. When it's installed at application level, it is applied
to all routes automatically. It will be applicable for newer
routes/pages added in future.

I'm inclined to go with #1, primarily for single reason: We don't want
to fork twitter.common.http library. If we fork, we should come up
with a way to integrate it with pants build system, and override this
library every time we package thermos. We already forked
incubator-aurora for making different changes, and planning to track
authentication changes alongside.

Is there a better approach to implement authentication?

Thank you,
-- 
Regards,
Bhuvan Arumugam
www.livecipher.com

Re: Authentication for thermos webui

[Bhuvan Arumugam <bh...@apache.org>]

Thank you, Brian.

We'll develop a plugin and track it within thermos observer. When
thermos is re-written using newer frameworks, we'll port the plugin.

On Wed, Aug 13, 2014 at 10:58 AM, Brian Wickman <wi...@apache.org> wrote:
> There is an existing kerberos plugin that works with twitter.common.http:
> https://github.com/twitter/commons/blob/master/src/python/twitter/common/http/plugins/kerberos.py
>
> I only bring this up as a reference to prior art.  There's nothing that
> requires this or other plugins to be within the commons codebase and could
> just as easily have been a third party plugin.
>
> Regarding architecture, the observer is probably the thing that has been
> given the last attention in the last few years and I'm personally open to
> significant architectural change, e.g. porting to Flask and away from
> twitter wrappers, if it means better support for these extensions.  I'm by
> no means a domain expert here and would love community suggestions,
> especially insight into how it's being used.
>
> ~brian
>
>
> On Wed, Aug 13, 2014 at 10:32 AM, Bhuvan Arumugam <bh...@apache.org> wrote:
>
>> Hello,
>> We are implementing cookie based authentication for thermos webui
>> (port: 1338). It is a single sign-on implementation. The
>> unauthenticated users will be redirected to a login service. After
>> user is successfully authenticated in the login service, a cookie will
>> be added in this domain. The cookie is validated against the login
>> service, before the page is rendered.
>>
>> I wish to get input on the design we are planning to implement, for
>> thermos webui. Ideally, we want to grant access to thermos webui only
>> for authenticated users.
>>
>> Thermos use twitter.common.http library to render the UI, which use
>> bottle web framework and server. The html pages are generated using
>> bottle templates.
>>
>> We could implement authentication in 2 ways.
>>
>> 1. The authentication can be implemented as a bottle plugin, within
>> thermos code base. The plugin can be installed for each route defined
>> for different web pages. This way, we could avoid making changes
>> directly to twitter.common.http library. We should install this plugin
>> for newer routes/pages added in future.
>> 2. The authentication can be implemented as a bottle plugin, within
>> twitter.common.http library. The plugin can be installed, per
>> application. When it's installed at application level, it is applied
>> to all routes automatically. It will be applicable for newer
>> routes/pages added in future.
>>
>> I'm inclined to go with #1, primarily for single reason: We don't want
>> to fork twitter.common.http library. If we fork, we should come up
>> with a way to integrate it with pants build system, and override this
>> library every time we package thermos. We already forked
>> incubator-aurora for making different changes, and planning to track
>> authentication changes alongside.
>>
>> Is there a better approach to implement authentication?
>>
>> Thank you,
>> --
>> Regards,
>> Bhuvan Arumugam
>> www.livecipher.com
>>



-- 
Regards,
Bhuvan Arumugam
www.livecipher.com

Re: Authentication for thermos webui

[Brian Wickman <wi...@apache.org>]

There is an existing kerberos plugin that works with twitter.common.http:
https://github.com/twitter/commons/blob/master/src/python/twitter/common/http/plugins/kerberos.py

I only bring this up as a reference to prior art.  There's nothing that
requires this or other plugins to be within the commons codebase and could
just as easily have been a third party plugin.

Regarding architecture, the observer is probably the thing that has been
given the last attention in the last few years and I'm personally open to
significant architectural change, e.g. porting to Flask and away from
twitter wrappers, if it means better support for these extensions.  I'm by
no means a domain expert here and would love community suggestions,
especially insight into how it's being used.

~brian


On Wed, Aug 13, 2014 at 10:32 AM, Bhuvan Arumugam <bh...@apache.org> wrote:

> Hello,
> We are implementing cookie based authentication for thermos webui
> (port: 1338). It is a single sign-on implementation. The
> unauthenticated users will be redirected to a login service. After
> user is successfully authenticated in the login service, a cookie will
> be added in this domain. The cookie is validated against the login
> service, before the page is rendered.
>
> I wish to get input on the design we are planning to implement, for
> thermos webui. Ideally, we want to grant access to thermos webui only
> for authenticated users.
>
> Thermos use twitter.common.http library to render the UI, which use
> bottle web framework and server. The html pages are generated using
> bottle templates.
>
> We could implement authentication in 2 ways.
>
> 1. The authentication can be implemented as a bottle plugin, within
> thermos code base. The plugin can be installed for each route defined
> for different web pages. This way, we could avoid making changes
> directly to twitter.common.http library. We should install this plugin
> for newer routes/pages added in future.
> 2. The authentication can be implemented as a bottle plugin, within
> twitter.common.http library. The plugin can be installed, per
> application. When it's installed at application level, it is applied
> to all routes automatically. It will be applicable for newer
> routes/pages added in future.
>
> I'm inclined to go with #1, primarily for single reason: We don't want
> to fork twitter.common.http library. If we fork, we should come up
> with a way to integrate it with pants build system, and override this
> library every time we package thermos. We already forked
> incubator-aurora for making different changes, and planning to track
> authentication changes alongside.
>
> Is there a better approach to implement authentication?
>
> Thank you,
> --
> Regards,
> Bhuvan Arumugam
> www.livecipher.com
>