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(a)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+
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(a)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(a)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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>
>