Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

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(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Thursday, March 24, 2016 4:01:31 PM Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest ----- Original Message ----- Yeah, from a client perspective they are the same thing. Just a client trying to access resources protected with a bearer token. 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 ... _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev