Consider using hawtio-oauth and removing ConnectOptions.token support

[astefanutti]

@tadayosi @akieling I wonder whether we should depend on hawtio-oauth directly in hawtio-jmx as it is used in hawtio v2 and hawtio-online. If that is the case, then we may consider removing ConnectOptions.token which is redundant.

That follows #47 up. Actually in the OpenShift console, the user stays in the same window and in hawtio-online the token is passed in the URL hash. So we may use the session store instead of the local store. We still need ConnectOptions.token if we want to open a new window.

I would tend to think end-users may want to have multiple windows opened. So that leaves us with the following options:

• Use hawtio-oauth and store the token in the local store
• Pass the token in the URL hash and rely on ConnectOptions.token stored in the session store
  The former would allow to logout from any window using the hawtio-logout extension and would allow using the token throughout its entire lifespan, while the later might be more secure.

[abkieling]

Currently, hawtio-oauth is a dependency of hawtio-console-assembly and it makes sense, doesn't it?
Apps that use oauth can depend on hawtio-oauth.
I personally think ConnectOptions shouldn't have the username, password, and token fields. They should be in a different object.
When we open a new window, the username and password are passed to the new window via properties in the parent window. What do you think of this strategy?

[astefanutti]

Currently, hawtio-oauth is a dependency of hawtio-console-assembly and it makes sense, doesn't it?
Apps that use oauth can depend on hawtio-oauth.

For sure, but the question is: as all the apps that depends on hawtio-integration depends on hawtio-oauth, would that make sense to have hawtio-jmx depends on hawtio-oauth to avoid duplications, inconsistencies and enables removing use of ConnectOptions.token?

When we open a new window, the username and password are passed to the new window via properties in the parent window. What do you think of this strategy?

What about page reload? Original question is about ConnectOptions.token but we can discuss username and password in a subsequent point.

[abkieling]

On Thu, Mar 8, 2018 at 3:00 PM, Antonin Stefanutti ***@***.*** > wrote: Currently, hawtio-oauth is a dependency of hawtio-console-assembly and it makes sense, doesn't it? Apps that use oauth can depend on hawtio-oauth. For sure, but the question is: as all the apps that depends on hawtio-integration depends on hawtio-oauth, would that make sense to have hawtio-integration depends on hawtio-oauth to avoid duplications and inconsistencies?

I'm not against it. If you guys feel it's a better place to define the dependency, than do it. We just need to make sure it doesn't cause any issues to apps that don't use oauth.

When we open a new window, the username and password are passed to the new window via properties in the parent window. What do you think of this strategy? What about page reload?

That's currently an issue because we aren't storing the credentials in any persistent storage and I guess we can't access the parent window after a page reload. Session storage could be a good place to temporarily store the credentials but storing a password as plain text isn't awesome isn't it?

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB0lT3jV0PU7dOb-od9_qZufeijLVE82ks5tcXHXgaJpZM4SjATB> .

-- Alexandre KielingSr. Software Engineer, JBoss FuseRed Hat

[astefanutti]

I'm not against it. If you guys feel it's a better place to define the
dependency, than do it. We just need to make sure it doesn't cause any
issues to apps that don't use oauth.

Hence my question ;) I'm requesting feedback.

That's currently an issue because we aren't storing the credentials in any
persistent storage and I guess we can't access the parent window after a
page reload. Session storage could be a good place to temporarily store the
credentials but storing a password as plain text isn't awesome isn't it?

Hence the original question discussing token not username / password.

[tadayosi]

Hi guys,

as all the apps that depends on hawtio-integration depends on hawtio-oauth, would that make sense to have hawtio-integration depends on hawtio-oauth to avoid duplications and inconsistencies?

Honestly, I'd feel against the idea of hawtio-jmx depending on hawtio-oauth. Logically speaking, how to authenticate the app (= hawtio-oauth) is orthogonal to what functionalities it provides (= hawtio-jmx & hawtio-integration). To me it is quite straightforward that the assembling projects combine hawtio-oauth and hawtio-jmx & hawtio-integration.

Recently I've made these changes cbe1d29 & hawtio/hawtio-oauth@1fb0eaa so that hawtio-oauth can overwrite the Ajax beforeSend to attach Keycloak token to each request to Jolokia. I think it's more beautiful to keep the getBeforeSend() code in hawtio-jmx as simple as possible and have hawtio-oauth (or other plugins) overwrite/extend it with their specific needs. @astefanutti Can it not be a solution to your problem?

Actually in the OpenShift console, the user stays in the same window and in hawtio-online the token is passed in the URL hash. So we may use the session store instead of the local store.

Considering the use cases of hawtio-oauth on OpenShift it seems acceptable to store the token to local storage, but then please make sure to clean it up upon logout through pre/postLogoutTasks just like:
https://github.com/hawtio/hawtio-integration/blob/master/plugins/activemq/ts/activemqPlugin.ts#L62-L67

[astefanutti]

@tadayosi thanks a lot, that helps!

Honestly, I'd feel against the idea of hawtio-jmx depending on hawtio-oauth. Logically speaking, how to authenticate the app (= hawtio-oauth) is orthogonal to what functionalities it provides (= hawtio-jmx & hawtio-integration). To me it is quite straightforward that the assembling projects combine hawtio-oauth and hawtio-jmx & hawtio-integration.

I agree. For the time being, hawtio-integration is used as an application in itself in the hawtio-online image. While that's convenient by avoiding creating a dedicated layer / project for it, I guess it will need to diverge any time soon. So I'll create that dedicated layer, similar to https://github.com/hawtio/openshift-jvm, and that will be symmetrical with Hawtio 2.x too.

Recently I've made these changes cbe1d29 & hawtio/hawtio-oauth@1fb0eaa so that hawtio-oauth can overwrite the Ajax beforeSend to attach Keycloak token to each request to Jolokia. I think it's more beautiful to keep the getBeforeSend() code in hawtio-jmx as simple as possible and have hawtio-oauth (or other plugins) overwrite/extend it with their specific needs. @astefanutti Can it not be a solution to your problem?

Yes, if I create that openshift-jvm thing, then it will have hawtio-oauth and that will work.

Actually in the OpenShift console, the user stays in the same window and in hawtio-online the token is passed in the URL hash. So we may use the session store instead of the local store.
Considering the use cases of hawtio-oauth on OpenShift it seems acceptable to store the token to local storage, but then please make sure to clean it up upon logout through pre/postLogoutTasks just like:
https://github.com/hawtio/hawtio-integration/blob/master/plugins/activemq/ts/activemqPlugin.ts#L62-L67

Agree, I think that's what the logout() method does in hawtio-oauth already.

Let me close this and I'll implement the above in hawtio-online. Thanks again!