[keycloak-dev] make sending a request object mandatory for certain clients

[Aron Bustya]

I am not entirely sure, to be honest. I also think the signature should be
enogh for security.

We are implementing this specification:
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/7046134/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.0
The only reasoning for the decision is:
"OpenBanking, in conjuction with major IAM vendors, is ruling out the use
of JWT Request objects by reference due a number of delivery risks and
remaining security concerns."
Not very specific.

I'll check with our architect if we really need to comply with this, or
requiring any kind of request object will be enough.

Thanks,
Áron

On 9 March 2018 at 11:01, Marek Posolda <mposolda at redhat.com> wrote:

> Ah, really?
>
> I am curious why you have this requirement? Is it due the security? I
> wonder that if request is signed with the private key of the client, then
> it's not any difference regarding security if it's "request" or
> "request_uri" . It can't happen that someone will be able to construct
> request object and "put" it on specific URI due the fact that he won't be
> able to sign it (unless he steal the client RSA key, but that would be
> broken security anyway and he will be able to construct "request" object
> the exactly same way).
>
> Thanks,
> Marek
>
>
> On 09/03/18 10:32, Aron Bustya wrote:
>
> Hi Marek,
>
> Thans for the reply.
> In the meantime I found out that we must only accept a request object
> entered directly, and not a request_uri (my first implementation handles
> the two together).
>
> But I'm afraid this makes the configuration more complicated.
>
> I can imagine it with 3 switches:
> -Accept auth. request without request object
> -Accept auth. request with request object included in request param
> -Accept auth. request with request object referenced with request_uri
> (All of them true by default.)
>
> Or maybe with a dropdown "Accept auth. request":
> -any (default)
> -with request object included in request param or referenced with
> request_uri
> -with request object included in request param
> -with request object referenced with request_uri
>
> Is this too much to add on the UI?
> Do you have a better idea?
>
> Thanks,
> Áron
>
>
> On 8 March 2018 at 17:23, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 08/03/18 15:25, Marek Posolda wrote:
>>
>>> Hi,
>>>
>>> sorry to not respond earlier. Your usecase makes sense to me and the
>>> code you did as well. One minor thing, which is missing, is admin console
>>> update. I think you need to add new switch to the client details page.
>>> Please add it to same section like "Advanced config" where are other things
>>> like request object signature algorithm etc.
>>>
>> Forgot to mention, that it will be nice if you send PR once you do it :)
>>
>> Thanks,
>> Marek
>>
>>
>>> Thanks,
>>> Marek
>>>
>>> On 06/03/18 20:13, Aron Bustya wrote:
>>>
>>>> Hello!
>>>>
>>>> Can I get some reaction to this? (The community guidelines say I need to
>>>> ask around before sending pull requests.)
>>>>
>>>> Regards,
>>>> Áron Bustya
>>>>
>>>> On 2 December 2017 at 04:44, Aron Bustya <aron.bustya.js at gmail.com>
>>>> wrote:
>>>>
>>>> Hi!
>>>>>
>>>>> I have a use case where the server must accept authorization requests
>>>>> only
>>>>> when they contain a signed request object (should be configurable per
>>>>> client).
>>>>>
>>>>> I have found a way to make the signing of the request object mandatory
>>>>> by
>>>>> specifying a 'request.object.signature.alg' attribute on the client,
>>>>> but
>>>>> this only applies if a request object exists in the first place.
>>>>>
>>>>> I would like to propose a pull request: It defines a new client
>>>>> attribute
>>>>> 'request.object.required'. If this is set to 'true', the client must
>>>>> send a
>>>>> request object when initiating an authorization request.
>>>>>
>>>>> Current code can be checked here: https://github.com/abustya/
>>>>> keycloak/commit/476912906a3ad0d290220a1f54abee073dba687a
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Regards,
>>>>> Áron Bustya
>>>>>
>>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>
>