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

[Lachezar Dobrev]

  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?