[keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

[Bill Burke]

On 3/24/2016 3:01 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, March 24, 2016 3:02:52 PM
>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>
>>
>> That is really not different than our admin console.    There's no
>> reason the Keycloak admin console couldn't be completely separated from
>> the auth server and served up statically from a simple web server like
>> Apache HTTPD.
> Yeah, from a client perspective they are the same thing. Just a client trying to access resources protected with a bearer token.
>
>>
>> I don't understand why you would need this.  Why can't the GWT
>> application incorporate keycloak.js?  If their console app can't support
>> keycloak.js or even a GWT adapter created by us, then they need to
>> change.   If you can change the console to support this custom protocol,
>> why can't you change it to use keycloak.js?
> I did the same question when I started this HAL/Keycloak SSO task. But I did it differently: Why not handle the console just like any other OAuth2 client ?
>
> Some time ago I had some discussions around that where I proposed two approaches to try to solve this problem:
>
>      1) Change HAL to support OAuth2. Which is aligned with your question. In this case, HAL would behave just like any other OAuth2 client using Authorization Code Grant to obtain access tokens and sending them as bearer tokens to the management API.
>
>      2) Minimize changes to HAL and focus on fixing the redirection issue I mentioned before. In this case, we need some very minimal changes to HAL which are basically around dealing with a HTTP header, nothing else. No need to change wildfly-core (where the console is actually installed) or change/add any other configuration specific to the console in order to get it protected or create a specific HAL distribution that can SSO with KC. Beside all that, AFAIK HAL can not have a dependency to Keycloak and may support other authentication mechanisms, such as DIGEST, etc.
>
> Everyone agreed that #1 would be the "right" thing to do, but #2 is more aligned with what WildFly/EAP/HAL teams are willing to do at this regard.
>
> So, back to your question and in addition to what I just mentioned, IMO #2 also provides a nice addition to Keycloak OIDC Adapters. Specially for use cases where the front-end (client) and the back-end (RESTful API) are in the same package (as you said in our F2F meeting, people are still doing that) or even when the client doesn't care if the server is using OAuth2, BASIC, DIGEST, CLIENT_CERT, etc. In other words, it just relies on the server and on the authentication provided by the browser using authentication/identity cookies.
>
> In the latter case, that is exactly how I got SSO working with HAL and Keycloak, where the adapter(from a Elytron/WildFly perspective, the right term would the Keycloak Authentication Mechanism) is configured to use a cookie store (but it can work with a session store as well).
>
> Honestly, for me I'm just fine with #1 and I wouldn't be here, writing this email, if the decision was a "got for it" :)
>
> For last, there are one more thing about this "new protocol" that I want to discuss. But I think we should get some agreement first about what we are discussing right now ...

#1, IMO the wildfly console team needs to make the console securable via 
SAML and/or OIDC. We can't be doing these one-off hack protocols just 
because these teams don't want to take the time to integrate properly.  
I'm sure there are already customers that want to integrate an existing 
non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit 
about DIGEST.  Everybody wants to integrate with an SSO solution.

That being said, I don't understand how this new protocol you are 
suggestion works. Can you walk through it again with which side is doing 
what?  (GWT vs. REST API).  At first glance, it looks like it is really 
vulnerable to CSRF attacks and is even vulnerable to stealing the token 
directly.  But again, maybe I'm not understanding what you want to do.

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