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&gt; 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

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&gt; >> 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 >> > > >

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&gt; 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&gt; >>> 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 >>> >> >> >> >

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 <mailto:aron.bustya.js@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+Banki... <https://openbanking.atlassian.net/wiki/spaces/DZ/pages/7046134/Open+Banki... 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 <mailto:mposolda@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(a)redhat.com > <mailto:mposolda@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 > <mailto:aron.bustya.js@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 > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > > > >

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

On 13 March 2018 at 16:53, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@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(a)gmail.com > <mailto:aron.bustya.js@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+Banki... > <https://openbanking.atlassian.net/wiki/spaces/DZ/pages/7046134/Open+Banki... > 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 > <mailto:mposolda@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(a)redhat.com <mailto:mposolda@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 >> <mailto:aron.bustya.js@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 >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> <https://lists.jboss.org/mailman/listinfo/keycloak-dev> >> >> >> >> >> > > >