Re: [keycloak-dev] CORS and Keycloak
On 10/8/2013 12:21 PM, Bill Burke wrote:
Based on our Hangout conversation, I'm trying to figure out what
we need
to do for CORS.
First, we absolutely need to allow CORS requests to Keycloak hosted
resources: specifically the token service and the admin REST api.
The question is, do we manage CORS for applications? How does this
information get transmitted? What support do we need to add? Here's my
take:
* Keycloak application adapters (i.e. the Tomcat Valve, or the Undertow
Handler) can be set up to handle CORS requests.
* Allowed origins can be specified within the adapter's config file.
Additionally we could:
* Store allowed origins per application within the Keycloak realm database
* Have a Keycloak REST API to obtain allowed origins for an application
* Optionally store allowed origins in the signed access token.
The Keycloak application adapter then has 3 options to authorize a CORS
invocation:
1) Its config file
2) a REST call to the Keycloak sever
3) From the access token.
TLDR; We can use an access token to perform CORS access control.
Did some research. Browsers will make a "preflight" OPTIONS request if
the request is not a simple request. That is, it will make a OPTIONS
request if there are any non-standard request headers, or a PUT or
DELETE call. Any Keycloak bearer token authentication request would
then trigger an OPTIONS preflight request as there would be an
Authorization header. This Authorization header is actually not sent
with the OPTIONS request. So, the Keycloak Application Adapter would
have to send a "Access-Control-Allow-Origin" of "*" back with the
OPTIONS request.
From IE 10 and Firefox 24 testing, it seems that if you send back "*"
with the OPTIONS request and don't send back Access-Control-Allow-Origin
when the actual request happens, then the request doesn't happen. So,
we *CAN* use an access token to perform CORS access control.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com