[keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

[Bill Burke]

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?

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