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

[Aron Bustya]

Yet, it's ok. (If by switch you meant a dropdown list.)

On 13 March 2018 at 16:53, Marek Posolda <mposolda at redhat.com> wrote:

> I would rather do with single switch instead of introduce 2 as you
> mentioned earlier. How about the switch "Request object required" with
> values:
> - Not required (default)
> - request_uri or request
> - request only
> - request_uri only
>
> And add some more details into the corresponding tooltip. Will it work for
> you?
>
> Marek
>
>
> On 12/03/18 08:53, Aron Bustya wrote:
>
> Hi, it turns out we do need to comply with this.
>
> Another way of putting it on the UI would be to add a switch "Request
> object required" (false by default).
> And if is set to true, display a dropdown "Request object delivery method"
> with options of "any" (default), "by value", "by reference".
>
> Is it ok if I do this?
>
> Thanks,
> Áron
>
> On 9 March 2018 at 13:16, Aron Bustya <aron.bustya.js at gmail.com> wrote:
>
>> 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+Profi
>> le+-+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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>