CORS filter doesn't seem to process pre-flight requests in CE 3.0.x

[aliaksander-samuseu]

Environment:
CentOS6.7, Gluu CE 3.0.1

Steps to reproduce:

1. Edit file WEB-INF/web.xml inside of oxauth.war in any way which would result in behaviour that differs from defaults. For example, let's add "Authorization" header to the list of allowed headers, which will make it to look like this:

    <!-- Cors -->
    <filter>
        <filter-name>CorsFilter</filter-name>
        <filter-class>org.gluu.oxserver.filters.CorsFilter</filter-class>
        <init-param>
            <param-name>cors.allowed.origins</param-name>
            <param-value>*</param-value>
        </init-param>
        <init-param>
            <param-name>cors.allowed.headers</param-name>
            <param-value>Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization</param-value>
        </init-param>
        <init-param>
            <param-name>cors.support.credentials</param-name>
            <param-value>true</param-value>
        </init-param>
    </filter>

2. Restart oxAuth service # service oxauth restart
3. Send next request to userinfo OIDC endpoint (it's an actual CORS pre-flight request used by some on-page OIDC javascript clients employing implicit flow):

OPTIONS /oxauth/seam/resource/restv1/oxauth/userinfo HTTP/1.1
Host: idp.gsu.edu
Connection: close
Access-Control-Request-Method: GET
Origin: http://oidc-js.site:5000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36
Access-Control-Request-Headers: authorization
Accept: */*
Referer: http://oidc-js.site:5000/user-manager-sample.html
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8

Result:
Response to the proposed request looks like this:

HTTP/1.1 200 OK
Date: Mon, 15 May 2017 23:17:04 GMT
Server: Jetty(9.3.15.v20161220)
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Allow: HEAD, POST, GET, OPTIONS
Content-Type: text/plain
Content-Length: 24
Access-Control-Allow-Origin: *
Connection: close

This seems to be a plain usual response to OPTIONS request instead of response to CORS pre-flight request (the latter should contain several "Access-Control-Allow-*" headers; "Access-Control-Allow-Origin" which can be seen there actually has nothing to do with the filter as it's set outside of Jetty, by Apache web server). Filter seems to maintain some basic functionality and even reacts to certain changes to its configurations (I was able to modify "SupportCredentials" settings), and even return some CORS headers in response sent to certain urls, but it at least doesn't produce a correct pre-flight response from userinfo endpoint what makes it inaccessible for on-page clients.

Expected result:
A correct response to such kind of request should look like this (additional CORS headers are possible):

HTTP/1.1 200 OK
Date: Mon, 15 May 2017 23:17:04 GMT
Server: Jetty(9.3.15.v20161220)
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization
Access-Control-Max-Age: 86400
Content-Type: text/plain
Content-Length: 24
Access-Control-Allow-Origin: *
Connection: close

Also please note that in case when "Access-Control-Allow-Credentials" headers is used in response and is set to "true", it's prohibited to use wildcard "*" for "Access-Control-Allow-Origin" and explicitly set origin must be used instead. As in requests to userinfo endpoint we must send access token in "Authorization" header, we must backup response to such request with "Access-Control-Allow-Credentials: true", or on-page javascript client won't be able to receive it.

For further details those pages may be useful:

• link1
• link2
• link3

[aliaksander-samuseu]

Please also note one thing I mentioned in comment to other report:

It seems we still use this "Access-Control-Allow-Origin: *" header in responses both in 3.0.x and 3.1.x packages. It happens because of this part of Apache's configuration:

        <Location /oxauth/seam/resource/restv1/oxauth/userinfo>
                ProxyPass http://localhost:8081/oxauth/seam/resource/restv1/oxauth/userinfo retry=5 disablereuse=On
                ProxyPassReverse http://localhost:8081/oxauth/seam/resource/restv1/oxauth/userinfo
                Header set Access-Control-Allow-Origin "*"
                Order allow,deny
                Allow from all
        </Location>

I.e. this header is simply attached to all responses from /oxauth/seam/resource/restv1/oxauth/userinfo.

If in the end explicit "Access-Control-Allow-Origin" set by CORS filter will be overridden by this wildcard value set by Apache, on-page clients won't be able to access such response due to requirements I mentioned above.

[aliaksander-samuseu]

Seems like we have same line set for "/oxauth" path too:

        <Location /oxauth>
                ProxyPass http://localhost:8081/oxauth retry=5 disablereuse=On
                ProxyPassReverse http://localhost:8081/oxauth
                Header set Access-Control-Allow-Origin "*"
                Order allow,deny
                Allow from all
        </Location>

[qbert2k]

GluuFederation/community-edition-setup@4a3029c

[aliaksander-samuseu]

I couldn't verify it's fixed. I used the 17.05.2017 oxauth-server.war(s) snapshots and pre-flight to userinfo still doesn't solicit a correct CORS-aware response.

There is also another issue due to the fix done to this issue. Now on-page js client can't access "/oxauth/seam/resource/restv1/oxauth/jwks" which it needs, due to the fact Access-Control-Allow-Origin "*" is now not returned for it, and it also isn't included in CORS filter's coverage by default

I had to add this element to web.xml to make it work:

    <filter-mapping>
        <filter-name>CorsFilter</filter-name>
        <url-pattern>/seam/resource/restv1/oxauth/jwks</url-pattern>
    </filter-mapping>

It should be there by default from now.

[willow9886]

@qbert2k @aliaksander-samuseu @sahiliamsso @zamilskhan seems like this is a high priority issue that needs to make it into 3.0.2. Can we spend some cycles making sure this is working as expected?

[qbert2k]

I am testing again this issue and also #542.

[LunarAshes]

Was this issue fixed for 3.0.2? I'm using the latest (3.0.2_rs3) .war file from https://ox.gluu.org/maven/org/xdi/oxauth-server/ but it seems like it's still older than the most recent commit. Any chance that the prebuilt .war file can be updated to include this fix? It's a pretty big showstopper for JS client access.

[willow9886]

@qbert2k @aliaksander-samuseu has this fix been tested and confirmed in 3.0.2?

[LunarAshes]

I ended up building a fresh .WAR from the 3.0.2 branch including the above commits and still got the same issue. Any ideas @qbert2k @aliaksander-samuseu?

[willow9886]

@zamilskhan @sahiliamsso can you guys both test for this as well?

[yurem]

Can you share your oxauth-config? It's in attribute oxAuthConfDynamic of entry: ou=oxauth,ou=configuration,inum=@!appliance_inum,ou=appliances,o=gluu

In setup branch there are few commits with fixes to oxAuth configuration like this:
GluuFederation/community-edition-setup@0fec4e9

[LunarAshes]

@yurem Thanks for the heads up - my existing setup didn't include that fix in the oxauth-config.json on my server. If I modify the config in /install/community-edition-setup/output, does that apply the change to a server that's already been installed? Or are those files used purely during setup only?

If it's the former, I'm still getting the following error in Chrome, using the documented OpenID Connect JS Implicit Flow client when attempting to access userinfo after a successful login.

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://local.testsite.co.nz' is therefore not allowed access. The response had HTTP status code 403.

With an unmodified 3.0.1 build, I'd get an error saying that the Authorization header wasn't accepted, so it looks like that part has been resolved, but as noted by aliaksander-samuseu, the Access-Control-Allow-Origin header looks like it's being overridden.

I am very new to the platform so it'd be great if someone more experienced could confirm if their results are consistent with mine.

[nynymike]

If this is not a bug, you'll need to move this thread to https://support.gluu.org

[yurem]

yes, it's better to move this to support.gluu.org

@LunarAshes you can try to update existing instance using next steps.

1. Log into oxTrust (/identity).
2. Open: Configuration -> JSON Configuration
3. Scroll to corsConfigurationFilters section
4. Apply changes to corsAllowedHeaders property
5. Save settings
6. Restart oxAuth service

[LunarAshes]

Thanks guys, with the config added through oxTrust, it's working on my end. Sorry if this wasn't the right channel to approach this - I was a little unsure due to the limbo of 3.0.2 being almost released but not quite.