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

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