48 lines
2.7 KiB
Text
48 lines
2.7 KiB
Text
|
= CORS
|
||
|
|
|
||
|
|
CORS stands for Cross-Origin Resource Sharing.
|
||
|
|
If executing browser Javascript tries to make an AJAX HTTP request to a server's whose domain is different than the one the Javascript code came from, then the request uses the http://www.w3.org/TR/cors/[CORS protocol].
|
||
|
|
The server must handle CORS requests in a special way, otherwise the browser will not display or allow the request to be processed.
|
||
|
|
This protocol exists to protect against XSS and other Javascript-based attacks.
|
||
|
|
Keycloak has support for validated CORS requests.
|
||
|
|
|
||
|
|
Keycloak's CORS support is configured per client.
|
||
|
|
You specify the allowed origins in the client's configuration page in the admin console.
|
||
|
|
You can add as many you want.
|
||
|
|
The value must be what the browser would send as a value in the `Origin` header.
|
||
|
|
For example `http://example.com` is what you must specify to allow CORS requests from `example.com`.
|
||
|
|
When an access token is created for the client, these allowed origins are embedded within the token.
|
||
|
|
On authenticated CORS requests, your application's Keycloak adapter will handle the CORS protocol and validate the `Origin` header against the allowed origins embedded in the token.
|
||
|
|
If there is no match, then the request is denied.
|
||
|
|
|
||
|
|
To enable CORS processing in your application's server, you must set the `enable-cors` setting to `true` in your <<_adapter_config,adapter's configuration file>>.
|
||
|
|
When this setting is enabled, the Keycloak adapter will handle all CORS preflight requests.
|
||
|
|
It will validate authenticated requests (protected resource requests), but will let unauthenticated requests (unprotected resource requests) pass through.
|
||
|
|
|
||
|
|
== Handling CORS Yourself
|
||
|
|
|
||
|
|
This section is for Java developers securing servlet-based applications using our servlet adapter.
|
||
|
|
|
||
|
|
If you don't like our CORS support you can handle it yourself in a filter or something.
|
||
|
|
One problem you will encounter is that our adapter will may trigger for any CORS preflight OPTIONS requests to blindly secured URLs.
|
||
|
|
This will result in 302 redirection or 401 responses for the preflight OPTIONS request.
|
||
|
|
To workaround this problem, you must modify your web.xml security constraints to let OPTIONS requests through
|
||
|
|
[source]
|
||
|
|
----
|
||
|
|
|
||
|
|
<security-constraint>
|
||
|
|
<web-resource-collection>
|
||
|
|
<web-resource-name>wholesale</web-resource-name>
|
||
|
|
<url-pattern>/*</url-pattern>
|
||
|
|
<http-method>GET</http-method>
|
||
|
|
<http-method>POST</http-method>
|
||
|
|
<http-method>PUT</http-method>
|
||
|
|
<http-method>DELETE</http-method>
|
||
|
|
</web-resource-collection>
|
||
|
|
...
|
||
|
|
</security-constraint>
|
||
|
|
----
|
||
|
|
|
||
|
|
The above security constraint will secure all URLs, but only on GET, POST, PUT, and DELETE calls.
|
||
|
|
OPTIONS requests will be let through.
|