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

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

5) User provides his credentials to the AS and if the authentication is successful, he is redirected back to the RS 6) The adapter running on the RS side now creates an identity cookie or a session based on the response from the AS. Again, nothing new here.

7) The adapter redirect the user back to the client application URI based on some information on the original request (eg.: a redirect_uri parameter sent during step #1), where the URI of the client must be valid and provided via adapter configuration (something like a second valid URI check, but at the RS side). Basically, I'm using 302 instead of 403 and doing a second redirect to get the user back to the client application. Where the client URI must be provided via adapter config and will be always validated.