[mitreid-connect] Authenticating the Consumer for the authorisation?

[Justin Richer]

This isn't really MITREid specific, so I suggest you bring this up to 
the OpenID Connect Working Group mailing list, and be sure to mention 
why request objects aren't a full solution for you.

  -- Justin

On 2/24/2015 12:23 PM, Lachezar Dobrev wrote:
>    Mmm... Yeah. Things are getting progressively complicated.
>    And even if we realise the request signing the request is re-playable,
> which would defeat its purpose.
>    How does one protect against request-replaying?
>
>    And I was very happy for a moment there: I was able to validate the
> signature of a request and continue with the process. But if I can
> receive request parameters as HTTP GET/POST parameters this becomes
> difficult to handle. I had the (probably wrong) impression, that if you
> have a request object (that is signed) you should completely ignore
> whatever is sent as unsigned parameters. And if these are ignored then
> validating them is futile.
>
>    What am I missing?
>
>    After explaining the situation to my superiors it seems we're going to
> look at a different approach to limiting authorisation requests: the
> request object looked good, but is too much hassle, and while it helps
> identity the client it does not go all the way to solve the issue at hand.
>
> На 24.02.2015 в 18:57, Justin Richer написа:
>> Yes, you can (and will) receive parameters inside the request object as well as outside. The ones outside aren’t protected by the signature, so they have to match the ones inside, which take precedence. This is detailed here:
>>
>> http://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
>>
>>   — Justin
>>
>>> On Feb 24, 2015, at 11:12 AM, Lachezar Dobrev <l.dobrev at paladin.bulgarpress.com> wrote:
>>>
>>>   I am working on validating the signature. I'm failing, but it's normal
>>> until I correctly put components together.
>>>
>>>   I do not understand the "precedence of parameters". Does that mean,
>>> that one could receive a request object and other parameters as well,
>>> all in the same Authorisation request? Wouldn't that get in the way of
>>> the signing of the request? Or am I missing something
>>>
>>>   About the list replying: sweet, reply-to-all it is.
>>>
>>> На 24.02.2015 в 17:18, Justin Richer написа:
>>>> OK, sounds like the request object is the right path for your use case.
>>>>
>>>> You can see how MITREid Connect does that processing in this class:
>>>>
>>>> https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/java/org/mitre/openid/connect/request/ConnectOAuth2RequestFactory.java
>>>>
>>>> It’s important to get the precedence of the parameters correct, so be
>>>> careful about just expanding the map and using that. And checking the
>>>> signature is obviously required for proper security and functionality.
>>>> You’re correct about the structure of the request, it’s a JSON Web
>>>> Signature. I’d suggest using a JOSE/JWT library on your platform to
>>>> handle the processing of that, if you can. We use (and contribute to)
>>>> the Nimbus JOSE JWT library on Java, and I can highly recommend it if
>>>> you’re on Java as well.
>>>>
>>>> As far as the list, reply-all to both poster and list and the server
>>>> will sort things out.
>>>>
>>>> — Justin
>>>>
>>>>> On Feb 24, 2015, at 10:05 AM, Lachezar Dobrev
>>>>> <l.dobrev at paladin.bulgarpress.com
>>>>> <mailto:l.dobrev at paladin.bulgarpress.com>> wrote:
>>>>>
>>>>> The part that costs money is the communication with the user for
>>>>> authorization. I can not see how to postpone that, so that it comes into
>>>>> play after the token has been issued.
>>>>>
>>>>> After I asked I took a deeper look and found about the request object.
>>>>> Looking further I found out, that I needed to use the
>>>>> signedAuthRequestUrlBuilder instead of the plainAuthRequestUrlBuilder in
>>>>> the simple-web-app.
>>>>>
>>>>> As far as I can see when a Consumer registers itself with the Provider
>>>>> it supplies JWK location for the Consumer's keys. Are these the keys
>>>>> that the Consumer signs requests with?
>>>>> As this is not a free-for-all service I am OK with explicit
>>>>> registration for the Consumers, including the public key with which they
>>>>> will sign the requests.
>>>>>
>>>>> If I understand correctly with the request object the three parts
>>>>> will be:
>>>>>   <json header object containing signature algorithm>
>>>>> .
>>>>>   <json request object containing same key:value pairs as a request>
>>>>> .
>>>>>   <Web-Safe-URL encoded signature byte array>
>>>>>
>>>>> Am I wrong?
>>>>>
>>>>> My current implementation handles (except for the actual signature
>>>>> checking) the request object by expanding the middle part and simulating
>>>>> a Request Parameter Map.
>>>>>
>>>>> Thanks again for the time spent to help.
>>>>>
>>>>> P.S. What is this mailing list's preference for responding: respond to
>>>>> list only, or respond to list and sender? Because the mails do not have
>>>>> a Reply-To header set. Is the list smart enough to not forward the mails
>>>>> to explicit recipients?
>>>>>
>>>>> На 24.02.2015 в 15:59, Justin Richer написа:
>>>>>> At the Authorization endpoint, there’s nothing in core OAuth that will
>>>>>> authenticate the client. The authentication comes on the back end
>>>>>> when the
>>>>>> token is issued in response to the auth code (in the auth code flow
>>>>>> at least).
>>>>>> So the easy solution is to have the part that costs money come into
>>>>>> play in
>>>>>> the back end, when the token is created and the client is
>>>>>> authenticated, if
>>>>>> you can manage that. If not, you do have some other options.
>>>>>>
>>>>>> With OpenID Connect, you do have a mechanism for authenticating the
>>>>>> authorization request: the request object. Assuming your server supports
>>>>>> request objects, and your client can generate and sign them, which the
>>>>>> server and client of MITREid Connect both do. You need to register your
>>>>>> public key with the server and use your private key to sign the request
>>>>>> object, or use your client secret to symmetrically sign the request
>>>>>> object.
>>>>>> Either way you likely need to register your client’s request object
>>>>>> signing
>>>>>> algorithm with the server. You can configure the MITREid Connect
>>>>>> client to
>>>>>> send signed request objects by using the SignedAuthorizationRequest
>>>>>> component, detailed here:
>>>>>>
>>>>>> https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/wiki/Client-configuration#signed-authorization-request
>>>>>>
>>>>>> — Justin
>>>>>>
>>>>>>> On Feb 24, 2015, at 6:09 AM, Lachezar Dobrev
>>>>>>> <l.dobrev at paladin.bulgarpress.com> wrote:
>>>>>>>
>>>>>>> Hey all.
>>>>>>>
>>>>>>> I am developing an OpenID-Connect provider.
>>>>>>> After some serious head-banging I've succeeded in making a provider
>>>>>>> that the MitreID-Connect simple-web-app can authenticate/authorise via.
>>>>>>>
>>>>>>> Now the problem I'm facing is authenticating the authorisation
>>>>>>> requests. The implementation has an authorisation procedure that costs
>>>>>>> money. However the authorisation request only contains a client_id that
>>>>>>> can be (relatively) easily duplicated and used to perform authorisation
>>>>>>> requests on behalf of a real client.
>>>>>>> If I understand correctly the authentication/authorisation process
>>>>>>> begins with the Client forwarding the User for the Provider, hence no
>>>>>>> Headers can be sent with the Authorisation request.
>>>>>>> What options do I have to authenticate the Client?