Hi Sylvain,
If you're getting op=login then I assume that this response is being generated because a login is required. The Reverse Proxy is seeing that it needs to return application/json and is not finding a login.json file - so is returning the default.json file (from /management/C) instead.
If you create a login.json file this will be returned instead for the login required event - you can customize it to your needs.
If, instead of creating login.json, you create login.401.json, then the content of the file will be returned with a 401 response code.
If there is an error condition, and accept header is application/json, then Reverse Proxy will attempt to load the <error code>.json file. If this isn't found it will use the default.json file (from error/C). You can create new <error code>.json (or <error code>.<response code>.json for specific error messages.
It is NOT possible to dynamically set the response code for a Reverse Proxy page.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Wed August 05, 2020 09:27 AM
From: Sylvain Gilbert
Subject: How to manage return codes when using WebSEAL as an OAuth Enforcement Point
Hi Laurent, and all !
The way I have been thinking about this over last 24 hours goes as follow. It re-uses some of your suggestions Laurent.
Use Case Description:
- Emulating as much as possible an API server with a Web Reverse Proxy to protect a single junctioned back-end API application.
- Authentication mechanism configured: "oauth-auth = https" (and is forms-auth enabled by default, for now)
- We have no requierment to authenticate "web" users using forms-auth.
- Web Authenticated users are prevented from navigating the API back-end junction using forms as special POP is set and attached to require OAuth token on the API endpoint.
- OAuth Flow: Client Credential, short token duration lifetime (5 min).
- OAuth client: pure stateless client (no care for webseal session cookie returned).
- OAuth token consumed on this WRP is obtained from another configured OAuth Authorization Server (WRP).
Requirement:
On expired/invalid OAuth (bearer) token received, return a HTTP 401 status code instead of the now HTTP 200 (TAMOP: Login) behavior that is depicted below:
HTTP/1.1 200 OK
content-length: 30
content-type: application/json
date: Wed, 05 Aug 2020 13:11:49 GMT
isam-op: login
{
"operation" : "login"
}
Option A:
Develop a HTTP Transformation (XSLT) that will inspect in the HTTP Response for the presence of the TAM OP header (http-rsp-header = isam-op:TAM_OP, see https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.5/com.ibm.isam.doc/wrp_stza_ref/reference/ref_http_rsp_header.html) and if present, trigger a re-write of the HTTP 200 status code into a HTTP 401 status code (might as well update the "OK" reason code while at it to "Unauthorized"). This should do the trick most of the time. Technical errors scenario I imagine would fall more under the range of HTTP 500 status code and in such cases, the XSLT would leave the status code as-is.
We are gaining in momentum with XSLT HTTP Transformation, so we are not "afraid" going that road.
Option B:
I was wondering if another cleaner (OOTB) option existed that didn't require modifying (with XSLT) the behavior of WebSEAL wanting to let know the user that no "session" existed.
------------------------------
Sylvain Gilbert
Original Message:
Sent: Mon February 17, 2020 10:02 AM
From: Laurent LA Asselborn
Subject: How to manage return codes when using WebSEAL as an OAuth Enforcement Point
We want to use WebSEAL to protect applications with OAuth sent as a bearer token. As I understand it WebSEAL should send a 401 if the token is incorrect, expired or missing.
For the "oauth-eas" mechanism you can configure the following:
unauthorized-rsp-file = oauth_template_rsp_401_unauthorized.html
But for "oauth-auth" there doesn't seem to be such a config. And if I understood correctly "oauth-eas" was the old way to do oauth and "oauth-auth" is the new one.
I've now tried playing around with the various custom return codes that I can configure in the login/error pages but until now I haven't found a satisfying solution.
If the only mechanism activated is oauth-auth, then the response for an unauthenticated request will be a 403 (38cf0427.html). I can now change this file to 38cf0427.401.html, but I'm not sure if this would be a good idea because then basically every 403 will be a 401.
If I also add "forms-auth" as an authentication mechanism then I can change login.html to login.401.html. This has the advantage that only login operations are impacted but I have to active an authentication mechanism that I didn't want to allow on this instance. So I will have to use a POP with the correct authentication level to prevent users login in with passwords.
What's also missing with this approach of changing the return code is that no "WWW-Authenticate" header will be sent. Now I could write a http transformation which checks for the presence of the "Authorization" header and sends the correct challenge back if this header is missing. But I don't know how I should treat an expired or incorrect token this way.
What is the correct way in which IBM recommends to use WebSEAL as an enforcement point?
------------------------------
Laurent Asselborn
------------------------------