[keycloak-dev] Cors origins in token

[Bill Burke]

On 11/21/2013 10:54 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 21 November, 2013 3:24:25 PM
>> Subject: Re: [keycloak-dev] Cors origins in token
>>
>> We could:
>>
>> * Have a web-origin token that's stuffed in a custom header.  We'd need
>> to think about any security implications surrounding that.
>
> I don't quite understand - would that not mean that the adapter would have to make some request to Keycloak in the first place?
>

Application could obtain a origin token at startup and make it 
available.  TOken is transmitted with REST requests and validated by the 
REST services.  This would allow to restrict web-origins per 
application.  Otherwise, a REST service would have to pull auth-server 
to get *ALL* possible web-origins.

>> * Have the adapter query the auth-server at boot time to get a list of
>> allowed origins.
>>
>> A web-origin token might be best then you can restrict a specific client
>> to only be able to invoke on a subset of origins.
>
> One thing I was wondering about in the past was if the adapter could retrieve a lot of the configuration information at boot time (it could also refresh it at certain intervals). Then all you'd need to add to the app to configure it would be client id and secret.
>

I've been down this route.  One fixable problem was that the demo had 
boot order dependencies.  Auth server has to be running before the WAR 
can be deployed. But...read further

> I'm not 100% sure whether or not it would be safe to retrieve pub key this way though? But it is retrieved over https, and if you can't trust the https connection and the keycloak server are you not a bit f... any ways?
>

Well, to have complete trust in HTTPS, the client needs a truststore 
that can be used to verify the host's cert.

We can sort of avoid this setup if the public key is provided via a 
config file and just sign auth-server responses with the public key. 
Not a perfectly secure solution, but it beats having to generate a 
keystore.  So, its either generate a keystore(truststore) or include the 
public key within the adapter config.

Bill


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com