[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 7:18:04 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> 
> On 3/24/2016 5:40 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 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.
> 
> Brother...Argue with me if you don't agree.   Given that I can't even
> manage to master GIT, what makes you think I'm right here?

Well, I think I did answer your question already. We have the same feeling about which path would be the best to go.

However, I'm looking at both sides and I'm trying to find a balance. I don't think my proposal brings complexity or is useless, but right now it is being driven by a single use case, the console. On the contrary, I think it can help to address use cases with similar requirements. Actually, it was fairly easy to enable SSO and get the console integrated with KC using only the configuration and some very minor changes to the console code.

I think that the next step is get you into the loop and reopen the discussion about #1 and #2. I think is worthy to do that and make sure everybody is aligned.

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