Upstream rejection during oauth2 with Immutant and/or Wildfly

[Webdev Tory Anderson]

My app is working fine from both localhost and remotehost with just "lein run"; however, it fails when I do "lein immutant war" and stick it in Wildfly. Here is the middleware wrapping flow:

#+BEGIN_SRC clojure

(defn wrap-base [handler]
  (-> ((:middleware defaults) handler)
      wrap-webjars
      wrap-flash
      wrap-byu-api-call ;; API piggy-backs off CAS; returns with "code=" and "state=" in the url
      (wrap-cas (-> env :site-url)) ;; regular CAS; gives me a "ticket=" param
      (wrap-session {:cookie-attrs {:http-only true}})
      (wrap-defaults
        (-> site-defaults
            (assoc-in [:security :anti-forgery] false)
            (dissoc :session)))
      wrap-context
      wrap-internal-error))

#+END_SRC

CAS is fine and I've used it in a number of other apps on Wildfly without issue. Here is my wrap-byu-api-call:

#+BEGIN_SRC clojure

(defn wrap-byu-api-call [handler]
  (let [api-address (oauth/authkey-GET-url
                     (-> env :client-id)
                     (-> env :site-url))] ;; Just generates the target URL, including its redirect_url after auth happens
    (println "API ADDRESS" api-address) ;; looks good
    (fn [req]
      (println "--- In wrap-byu-api-call ---")
      (println req)
      (if (get-in req [:session :byu-api-auth-code])
        (do
          (println "--------- Request has the right session info")
          (handler req))
        (if-let [code (get-in req [:params :code])]
          (do
            (println "--------- Request has the code in the url")
            (handler (assoc-in req [:session :byu-api-auth-code] code)))
          (do
            (println "--------- Request has neither url or session code")
            (redirect api-address)))))))

#+END_SRC

When my war is dropped in wildfly, requests never seem to make it past the "has neither url or session code" level. The nginx error is as follows:

#+BEGIN_SRC

2016/08/03 17:43:30 [error] 46923#0: *11 connect() failed (111: Connection refused) while connecting to upstream, client: 10.25.2.15, server: humplus-funding.byu.edu, request: "GET /?state=myteststate&code=c45fdbea689f5669665299f52df21 HTTP/1.1", upstream: "http://[::1]:8080/humplusfunding/?state=myteststate&code=c45fdbea689f5669665299f52df21", host: "humplus-funding.byu.edu", referrer: "https://shib.byu.edu/idp/profile/SAML2/POST/SSO;jsessionid=449AF9F05854EE118062BE44D06A43B0.2?execution=e1s1&_eventId_proceed=1"

#+END_SRC

The request has the information I need -- particularly the temporary auth code -- but doesn't include the ticket from the previous step (I don't know if that matters). However, it gets rejected.

And here is the wildfly console log matching the same requests:
#+BEGIN_SRC

[0m [0m17:43:05,408 INFO  [stdout] (default task-11) --- In wrap-byu-api-call ---
[0m [0m17:43:05,412 INFO  [stdout] (default task-11) {:ssl-client-cert nil, :cookies {}, :cas-info #object[java.util.Collections$EmptyMap 0x7b1411d5 {}], :remote-addr 127.0.0.1, :username torysa, :params {:ticket ST-553561-akFrwrLF0F61bh71eX2G-smaug1}, :servlet-context #object[io.undertow.servlet.spec.ServletContextImpl 0x5321b1d1 io.undertow.servlet.spec.ServletContextImpl@5321b1d1], :servlet-response #object[io.undertow.servlet.spec.HttpServletResponseImpl 0x15e9b613 io.undertow.servlet.spec.HttpServletResponseImpl@15e9b613], :handler-type :servlet, :servlet #object[immutant.web.internal.servlet.proxy$javax.servlet.http.HttpServlet$ff19274a 0x42b3cfa1 immutant.web.internal.servlet.proxy$javax.servlet.http.HttpServlet$ff19274a@42b3cfa1], :headers {accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8, connection close, x-forwarded-proto https, user-agent Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0, x-forwarded-for 10.25.2.15, host humplus-funding.byu.edu, accept-language en-US,en;q=0.5, accept-encoding gzip, deflate, br}, :server-port 80, :servlet-request #object[io.undertow.servlet.spec.HttpServletRequestImpl 0xb5665c6 HttpServletRequestImpl [ GET /humplusfunding/ ]], :content-length -1, :form-params {}, :query-params {ticket ST-553561-akFrwrLF0F61bh71eX2G-smaug1, _const_cas_assertion_ #object[org.jasig.cas.client.validation.AssertionImpl 0x633a30ed org.jasig.cas.client.validation.AssertionImpl@633a30ed]}, :content-type nil, :path-info /, :character-encoding nil, :context /humplusfunding, :uri /humplusfunding/, :server-name humplus-funding.byu.edu, :query-string ticket=ST-553561-akFrwrLF0F61bh71eX2G-smaug1, :body #object[io.undertow.servlet.spec.ServletInputStreamImpl 0x7f53fade io.undertow.servlet.spec.ServletInputStreamImpl@7f53fade], :multipart-params {}, :scheme :http, :request-method :get, :session nil}
[0m [0m17:43:05,412 INFO  [stdout] (default task-11) --------- Request has neither url or session code

... <REPEATED MANY TIMES>

#+END_SRC
The console log includes the _const_cas_assertion_ that shows it successfully finished the CAS authentication, but we never seem to receive the "upstream" request shown by the nginx log that includes the needed ":code" parameter.

Additional information:

• - Wildfly 10, mostly out-of-the-box with standalone deployment
• - Fronted with nginx
• - Running securely on https (SSL port 443)
• - Works fine on the same server, fronted by nginx, when run as "lein run" not an immutant war/wildfly.

Any suggestions on what the wildfly/immutant problem is would be very welcome. Other than a brief hyphen-vs-underscore naming convention what was easily fixed, I have no leads. Unfortunately, due to the authentication nature of the problem, it's hard to give more details; but I'll do what I can if you need more info.

[Toby Crawley]

Tory:

I'm not very familiar with CAS. Is the flow here supposed to be:

1. request -> nginx -> wildfly
2. redirect to auth server if unauthenticated
3. auth server redirects back to nginx -> wildfly with the code

If so, is the nginx error above on step 3?

The nginx error shows the request as `GET
/?state=myteststate&code=c45fdbea689f5669665299f52df21`, but the
WildFly log shows the app as being mounted at the `/humplusfunding`
context. If I'm reading the error correctly, it seems like it should
instead be `GET /humplusfunding/?state=...`. Does/can
`authkey-GET-url` use current context when generating the return url?

- Toby

> --
> You received this message because you are subscribed to the Google Groups
> "Immutant" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to immutant+u...@googlegroups.com.
> To post to this group, send email to immu...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/immutant/94c5730b-4564-4758-ad48-e4df0b77f60e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Webdev Tory Anderson]

I'm still fighting this. Some added tests make it increasingly puzzling:

1. Wildfly on my local host (same version of wildfly) works with the immutant war
2. java -jar works locally
3. lein run works also REMOTELY
4. Remote Wildfly with the immutant war FAILS remotely, the the previously provided errors
5. Remote Wildfly with NO HTTPS still fails with the same errors (so nginx rewrite to HTTPS probably isn't the problem)

As near as I can tell, the wildfly standalone config is identical on local and remote (except for some shuffling of the xml param order)

[Toby Crawley]

On Wed, Aug 17, 2016 at 5:18 PM, Webdev Tory Anderson
<web...@toryanderson.com> wrote:
> I'm still fighting this. Some added tests make it increasingly puzzling:
>
> 1. Wildfly on my local host (same version of wildfly) works with the
> immutant war

How are you deploying this war locally? Is it at the root context (/),
of at /humplusfunding?

> 2. java -jar works locally
> 3. lein run works also REMOTELY

Both 2 & 3 would use the root context.

> 4. Remote Wildfly with the immutant war FAILS remotely, the the previously
> provided errors
> 5. Remote Wildfly with NO HTTPS still fails with the same errors (so nginx
> rewrite to HTTPS probably isn't the problem)

From the log output, the war is deployed at the /humplusfunding
context, but the return url that is given to the auth server is at the
root context, so won't hit the app. As I said below, I think the cause
here is that `authkey-GET-url` isn't taking the current context into
account, so isn't giving you the correct url when the app is deployed
to a context other than the root one.

> https://groups.google.com/d/msgid/immutant/e063fda8-e48b-4374-beac-4e962a37be0a%40googlegroups.com.

[Webdev Tory Anderson]

Okay, I've made some progrewss, though I'm not all the way up and running yet. The fundamental problem seems to be that the wildfly setup is handling (transforming) the request differently than expected, and I'm not sure how to work with it. I'll post more on a related issue.

[Webdev Tory Anderson]

I think I have it fixed. It turns out it was chiefly to do with the order of my middleware, although some of it also had to do with the differences in how servlet context is handled vs non-servlet. I need to understand that better.

On Wednesday, August 3, 2016 at 9:05:10 PM UTC-6, Webdev Tory Anderson wrote: