[keycloak-dev] make sending a request object mandatory for certain clients
Marek Posolda
mposolda at redhat.com
Tue Mar 13 11:53:54 EDT 2018
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