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

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.