[keycloak-dev] make sending a request object mandatory for certain clients
Marek Posolda
mposolda at redhat.com
Tue Mar 13 14:44:17 EDT 2018
On 13/03/18 19:28, Aron Bustya wrote:
> Yet, it's ok. (If by switch you meant a dropdown list.)
Ah yes :) Sorry to be unclear.
Marek
>
> On 13 March 2018 at 16:53, Marek Posolda <mposolda at redhat.com
> <mailto: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
>> <mailto: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+Profile+-+Implementer+s+Draft+v1.1.0
>> <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
>> <mailto: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 paramor
>>> referenced withrequest_uri
>>> -with request object included in request param
>>> -withrequest object referenced withrequest_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 <mailto: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
>>> <mailto: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
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
More information about the keycloak-dev
mailing list