[keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

[Bill Burke]

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.

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