apimlAuthenticationToken is overwritten when user works on multiple zowe instances

[std4lqi]

We have multiple Zowe servers configured with different ports on one z/OS. When we logon two Zowe desktops on two different ports in one browser window, and switch from one to another forth and back, we'll be prompted for credential again and again.

I understand apimlAuthenticationToken in cookie is not specific to port. So

• When I logon Zowe desktop on port 8544, I get apimlAuthenticationToken=tokenA stored in cookie.
• When I logon Zowe desktop on another port, say 18544, I get new apimlAuthenticationToken=tokenB, which override the original tokenA.
• When I switch back to port 8544, tokenB is invalid, and Zowe prompts for credential again.

It would be great to have apimlAuthenticationToken stored in port-specific way in cookie, like apimlAuthenticationToken.8544 and apimlAuthenticationToken.18544.

[1000TurquoisePogs]

Indeed, we used to do this with the zlux cookie (connect.sid.port) before making more use of apimlAuthenticationToken. Maybe we can make this change too.

[plavjanik]

I like this idea. It will be useful for everyone who has multiple instances on a system.

We were thinking about having a configurable suffix to the token name. Using a port number automatically is better because it does not require additional configuration.

This will be applied only to API gateway. The downstream services will receive the cookie without the port number. Do you agree?

[plavjanik]

I think that APIML can the token name a configurable property. This could be set at the configuration time. The UI clients should not require changes. The browser will send cookies for all the ports to APIML but APIML will choose the right one. The cookie is HttpOnly so UI code is not accessing it directly. The CLI might require some changes unless it accepts then apimlAuthenticationToken with any suffix.

[jandadav]

This might solve the issue for the client's browser, but what are your thoughts on the SSO? The tokens might be passed around, to services which have different hostnames and ports... I am not sure if it would not break something. How common is the use-case that customer will install and run production with more than one zowe on the same system?

[1000TurquoisePogs]

Good points. I think we need to be careful about 2 things

1. When there are multiple APIML for high availability, the unique prefix/suffix of the cookie should be something shared by all... port may not be the best. You could use the instance ID of Zowe!
2. In SSO, other servers must also recognize the cookie. Again, if the prefix/suffix is easy to know, such as the instance ID, then this could be simple.

So my proposal would be... (for backwards compatibility) apimlAuthenticationToken is the default But if you change the value of instance ID (default=1), then you get apimlAuthenticationToken.INSTANCE_ID or something similar.

[1000TurquoisePogs]

I am moving this to api-layer to determine what to do. Perhaps this is insightful for the upcoming ID federation.

[balhar-jakub]

The video is here: https://ibm.box.com/s/sfyzj7z2z0yl88oxja0cs63k570wcrh8