Reason to use trivialAuth provider

[pj892031]

The ZLUX application contains a couple of authentication providers. One of them is trivialAuth. This provider accepts userId from the JWT token without any validation.

I understand it could be useful for testing purposes, but should it be really used in production? Even as a fallback?

ZLUX should be accessible via Gateway (btw. GW is checking the validity of the token) and the reason to use fallback is that GW is not available.

I guess trivialAuth should be disabled during release.

module.exports.getUserId = (apimlTkn) => {
  let base64UrlToBase64 = (input) => {
    let result = input.replace(/-/g, '+').replace(/_/g, '/');
    const padCount = result.length % 4;
    if (padCount > 0) {
      if (padCount === 1) {
        throw new Error('bad length of base64url string');
      }
      result += new Array(5 - padCount).join('=');
    }
    return result;
  }

  let userid;
  try {
    const payloadBase64Url = apimlTkn.split('.')[1];
    const payloadBase64 = base64UrlToBase64(payloadBase64Url);
    const payloadString = Buffer.from(payloadBase64, 'base64').toString();
    const payloadObject = JSON.parse(payloadString);
    userid = payloadObject.sub;
  } catch (e) {
    throw new Error(`failed to parse APIML token: ${e}`);
  }
  return userid;
}

  authenticate(request, sessionState) {
    if (request.body && request.body.username) {
      sessionState.username = request.body.username;
      sessionState.authenticated = true;
      return Promise.resolve({ success: true });
    } else if (request.cookies && request.cookies[TOKEN_NAME]) {
      try{
        sessionState.username = apiml.getUserId(request.cookies[TOKEN_NAME]);
      } catch (e) {
        return Promise.resolve({ success: false });
      }
      sessionState.authenticated = true;
      return Promise.resolve({ success: true })
    } else {
      return Promise.resolve({ success: false });
    }
  },

[1000TurquoisePogs]

It could be used for debug, but its original purpose was for implementations of the server that do not need auth, or dataservices that do not need auth. Consider you have a setup where some apis should only be accessed with authorization, but other apis can be accessed by anyone, in the same runtime.

This https://github.com/zowe/zlux-server-framework/blob/2e8738f6d96c20dbf71a8fa2df83f3d17e8a836a/lib/auth-manager.js#L200 allows per-api configuration, where an api could use a certain handler, or no handler. trivial-auth is equivalent to no handler so there's 2 ways to do the same thing at the per-api level, so i guess the main difference is trivial-auth could be used server-wide as you said for debug or for repurposing app-server for use in contexts other than zowe that wouldn't require auth.

The word 'fallback' is very misleading and should be changed if possible to do without breaking, because the server does not 'fallback' to trivial-auth. The server just uses whichever auth an api needs, and if an api doesnt specify, they get the default, which should be 'sso-auth' in ordinary configs.

If you're wanting to remove trivial-auth from the official zowe releases, that's a zowe-install-packaging decision i believe. here: https://github.com/zowe/zowe-install-packaging/blob/e88fc91b66fc04c91e65de017de808ef59f4ed45/files/zlux/config/plugins/org.zowe.zlux.auth.trivial.json

That may be a breaking change. I'm unsure if extensions are expecting this plugin for per-api control. I can ask some extenders.

[1000TurquoisePogs]

I believe this may satisfy the request zowe.jfrog.io/zowe/libs-snapshot-local/org/zowe/2.9.0-PR-3418/zowe-2.9.0-pr-3418-3084-20230511150533.pax