api-layer icon indicating copy to clipboard operation
api-layer copied to clipboard

Allow basic auth for passticket scheme

Open achmelo opened this issue 4 years ago • 5 comments

Is your feature request related to a problem? Please describe. In the case of passticket authentication scheme, onboarded service is accepting authentication in the form of username and password. The current limitation is the requirement of JWT in a request that is being translated into passticket. This is not necessary a could be omitted by providing credentials on the client-side.

Describe the solution you'd like Do not generate a passticket and just pass-through user credentials in case they are present in the client HTTP request.

achmelo avatar Jan 31 '22 11:01 achmelo

Passwords and passtickets are interchangeable, so a a service accepting a password can accept a passticket and vice-versa. A passticket is just a temporary short lived password. The scenario is where a gateway is not currently configured to generate passtickets. Perhaps it's not running in production, or is being used for testing where the gateway doesn't yet have auth to create a passticket. In this case a user might want to use bypass to just have password flowed. Then if that same service is deployed into a gateway that has passtickets enabled they now want to use that, which means they need to change their scheme to be passticket instead of password. The suggestion is that if the service has defined passticket but the gateway is not able to create a passticket (because it's not been configured to do so yet) then the gateway will default to flowing a password so it effectively reverts to bypass. This means that the service can be more flexibility deployed between gateways.

Joe-Winchester avatar Feb 02 '22 11:02 Joe-Winchester

There are two key questions:

  1. Are we looking at supporting the password coming from northbound services only for the passticket schema?
  2. What should have precedence in case we receive the password and can generate a passticket.

From my point of view:

  1. We shouldn't support this as it increases potential risk surface where some users will be depending on this functionality
  2. I believe that in such a case we should forward the password. Even though it may mean that the password may be wrong.

balhar-jakub avatar Feb 11 '22 09:02 balhar-jakub

The overall scenario this would work for is where a service cannot accept a JWT and can only accept basicAuth. It wants to work in situations where the customer has configured their gateway for SSO (maybe alongside MFA) or for customers where they don't have any SSO and just want passwords flowed all the way from client to server through the gateway untouched.

  1. If you have a password and can generate a passticket I agree you should forward the password. Passtickets should be used in an SSO token based request or x509.

Joe-Winchester avatar Feb 11 '22 10:02 Joe-Winchester

@Joe-Winchester The issue with this approach is that it doesn't work for SSO. You aren't getting SSO as there is no way for Gateway to accept other valid authentication methods e.g. JWT or X509 and translate to the username/password.

With the x.509 support there is no guaranteed way to get and use the password even if we wanted to cache it.

I am willing to reach out to the team and figure out whether there is any other way to help them, but this approach won't solve the issue.

balhar-jakub avatar Feb 14 '22 14:02 balhar-jakub

So the actual goal isn't that much relevant to the SSO per se. It's about simplification of the initial setup of the Zowe on system without Passticket enabled for the services that requires Passticket schema.

The idea is that in such case if basic auth is provided, we will pass it through if we can't generate passticket.

The services themselves are conformant as they support passtickets.

balhar-jakub avatar Feb 21 '22 08:02 balhar-jakub