0

I have a bff running in Liberty (https://localhost:9443), secured it with oidcclient, and configured it with cors to allow its SPA frontend to consume it, from a different origin (https://localhost:3000). I also enabled liberty's sso by setting a custom ltpa cookie.

However, despite my current configuration, whenever the SPA sends an xhr request to the bff and oidc responds with a redirect to login (either 302 or client-side redirects) it does not include cors headers, so the redirection itself gets rejected by the browser running my SPA, due to cors (MissingAllowOriginHeader). This prevents my SPA to catch the redirection, and send user to login page accordingly. Browser simply aborts the xhr.

Hence the question: Am I conceptually wrong in securing all bff endpoints with the oidcclient feature when the frontend will be in different origin? If not, am I missing some further configuration? It is highly probable I am not designing this right, but to me, it feels that liberty's oidcclient feature was not meant for SPA's on different origin? I was tempted to move oidc to my SPA instead, but quickly desist from it after googling a bit.

Some extracts of my configuration:

In server.xml:

  ...
  <httpEndpoint httpPort="9080" httpsPort="9443" id="defaultHttpEndpoint"/>
  
  <cors domain="/" allowedMethods="GET" allowedHeaders="*" allowCredentials="true" allowedOrigins="https://localhost:3000"/>
  
  <openidConnectClient id=... scope="openid" signatureAlgorithm="RS256" .../>
  
  <webAppSecurity ssoCookieName="ratorLtpaToken" sameSiteCookie="Lax" />
  ...

For anyone facing preflight issues when using cross-site xhr and oidc, like me, I have excluded the OPTIONS http method so that preflights bypass oidc:

<security-constraint>
  <display-name>Secured</display-name>
    <web-resource-collection>
      <web-resource-name>Everything</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method-omission>OPTIONS</http-method-omission>
      </web-resource-collection>
      <auth-constraint>
        <role-name>Authorized</role-name>
      </auth-constraint>
...

Here are the headers of such redirects provided by oidcclient feature:

< HTTP/1.1 302 Found
< X-Powered-By: Servlet/4.0
< Location: https://login.ibm.com/v1.0/endpoint/default/authorize?response_type=code&client_id=***&state=***&redirect_uri=https%3A%2F%2Flocalhost%3A9443%2Foidcclient%2Fredirect%2FIBMid&scope=openid
< Content-Language: en-US
< Set-Cookie: WASOidcCode=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly; SameSite=Lax
< Set-Cookie: JSESSIONID=**; Path=/; HttpOnly
< Set-Cookie: WASOidcStaten2054248538=***; Expires=Thu, 07 Jul 2022 18:02:59 GMT; Path=/; Secure; HttpOnly; SameSite=Lax
< Set-Cookie: WASReqURLOidcn2054248538=https://localhost:9443/login; Expires=Thu, 07 Jul 2022 18:02:59 GMT; Path=/; HttpOnly; SameSite=Lax
< Transfer-Encoding: chunked
< Date: Thu, 07 Jul 2022 17:55:59 GMT
< Expires: Thu, 01 Dec 1994 16:00:00 GMT
< Cache-Control: no-cache="set-cookie, set-cookie2"

As you can see, no cors headers are part of the oidc redirect response, so a frontend running on different origin than bff will drop this redirect and can never be caught.

Appreciate in advance any clarification/suggestion

Kuper
  • 23
  • 4
  • There must be some reason you don't just host everything from the 9443 server? – Bruce T. Jul 07 '22 at 23:56
  • they use different technology stack, are maintained by different squads, and they should scale independently. Coupling them together just to avoid cors doesnt sound right, imho. – Kuper Jul 08 '22 at 11:59
  • Makes sense. I wonder if this could help? https://openliberty.io/blog/2021/10/05/configurable-response-headers-21.0.0.11-beta.html – Bruce T. Jul 08 '22 at 13:30
  • It helped indeed to workaround my problem! I can force the headers with this new feature you mentioned. I am deeply interested in knowing if I am against a liberty bug then, or if I'm wrongly designing my architecture – Kuper Jul 08 '22 at 19:58
  • I'm not sure. CORS respect for 302's is a bit murky as well according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS, but I'm not sure how else you'd do what you're trying to do, maybe proxy server 3000 through 9443. . You could open an issue at https://github.com/OpenLiberty/open-liberty, it might get more feedback. – Bruce T. Jul 10 '22 at 19:39

0 Answers0