[keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

[Pedro Igor Silva]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at 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.

> 
> > 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.
> 
> Nothing new here?  We do not recommend, in fact, we discourage Keycloak
> users from using cookie authentication for authenticating REST XHR requests.
> > 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.
> 
> Unless the RS is set up to check the origin via CORS, using cookie
> authentication for REST XHR requests is vulnerable to CSRF attacks.

Yeah, but the idea is to enforce a same-origin policy.

Regardless of what we decide, the good thing about all that is that we have everything from both Elytron and Keycloak side (specially from the former) to secure both console and management API. Specially the management API, which can be 100% covered with bearer tokens. It is up to client to send them :)

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
>