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

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, March 24, 2016 6:36:11 PM > Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest > > > > On 3/24/2016 5:19 PM, Pedro Igor Silva wrote: >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Thursday, March 24, 2016 5:50:58 PM >>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest >>> >>> >>> >>> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote: >>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>> Sent: Thursday, March 24, 2016 4:25:44 PM >>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest >>>>> >>>>> >>>>> >>>>> #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 is fine as long as everybody is happy. I'm open to get back on step >>>> back and get a agreement about #1 or #2. >>>> >>>> Integration with third-party OIDC and SAML is something #1 can do using >>>> nothing but what the standards define. >>>> >>>> Regarding DIGEST, it is just one of the different http authentication >>>> mechanism supported by WildFly/EAP. Elytron is adding even more to this >>>> list. For instance, SCRAM. There are different use cases out there ... >>> This is a console problem and not an Elytron issue. How did the console >>> authenticate before? >> Today, the console uses DIGEST by default and relies on the browser to >> handle that. > Yeah, that's unacceptable. Can't expect real authentication to work > that way. > >> When the console sends a request to the mgmt API with no authentication >> info, the mgmt api responds with a 401 WWW-Authenticate. So the browser >> will show that dialog and handle both authentication and subsequent >> requests to the server. >>>>> 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. >>>> Well, it is not really a one-off hack. Actually, I've used something >>>> similar to what UMA provides in order to tell clients which AS they >>>> should >>>> go. >>>> >>>> There is no adapter on the client side, but only on the RS side. Beside >>>> that, the client was designed to rely on a authentication/identity cookie >>>> in order to secure requests and get things from the RS. >>>> >>>> The flow is: >>>> >>>> 1) Client asks a protected resource to the RS >>>> 2) The adapter running on the RS side identifies that the request >>>> contains >>>> a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there >>>> is no authentication info associated with the request >>>> 3) Instead of responding with a 302 redirect, the adapter sends back a >>>> response with a 403 status code and an Authorization header containing >>>> the >>>> "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing >>>> special here >>>> 4) Client extract the Authorization header from the response and redirect >>>> the user to an URI as specified in "as_uri" >>> In step #4 you have to modify the client console anyways. Why not just >>> do the right thing here? instead of this custom protocol? >> Sure, but those changes are very minimal if compared to what may be >> necessary to do the "right" thing. Just like I mentioned before. >> >> I'll reopen a thread where I was discussing this topic with the HAL team. >> Let's start that discussion next week. > You don't need to do much, just integrate keycloak.js. We already have > an adapter for javascript. Let's see. I'm not a GWT expert so I don't have a clue about how to do that. But I'm sure HAL team will support us if we go through this path. Beside that, we may even come up with a statndard-based solution for the console. SO they can work with any OAuth2/OIDC provider.