[keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

[Pedro Igor Silva]

Btw, the Keycloak Adapter I did based on Elytron is not specific to GWT. It is just a regular OIDC adapter ...

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, March 24, 2016 4:01:31 PM
Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

----- 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 ...

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev