This project is read-only.
1

Closed

Realm should be excluded for OAuth 1.0 "Signature Base String" calculation

description

A partner of ours in the role of LTI Provider has run into issues connecting to our LTI consumer based on your library, I quote:
I went through the oauth documentation again, were i found in the final version of the OAuth 1.0 specification (http://tools.ietf.org/html/rfc5849 in section 3.4.1.3.1 Parameter Sources ) that the realm should be excluded when creating the signature base.
I looked at RFC 8549 myself and suspect he is right after reading:
3.4.1.3.1. Parameter Sources
...
The OAuth HTTP "Authorization" header field (Section 3.5.1) if present. The header's content is parsed into a list of name/value pairs excluding the "realm" parameter if present. The parameter values are decoded as defined by Section 3.5.1.

Suggested solution

1) Could you please fix the "Signature Base String" calculation (by excluding the "realm" parameter)?
2) When checking signatures, after it fails I would suggest to recheck when the "realm" parameter is present in the "Signature Base String" calculation for reasons of backwards compatibility and robustness. (Different ends of LTI might not always be upgrading this library at the same time)
Closed Nov 2, 2014 at 3:18 AM by afmiller
Fixed by Changeset 106879.

comments

afmiller wrote Nov 2, 2014 at 3:18 AM

You and your partner are absolutely correct..."realm" should be excluded from the signature base string. However, re-checking using both versions of the signature base strings seems like overkill.

The affected population is limited to consumers using a new LtiLibrary working with providers using an old LtiLibrary (and no other consumers since they would presumably have already broken) and using LTI outcomes and including the optional realm parameter.

I'm going to try fixing the issue without the re-check.

jhabets wrote Nov 4, 2014 at 11:31 AM

Hi Andy,

Thanks for your swift response and action.

That said it is rather unfortunate that you have chosen not to implement the backward compatibility: Based on your library we have built integrations with several content providers, some of which have based their end on your library as well. Furthermore, in our role as content provider collaborated with several LMS-es to add LTI support based on your library as well. To synchronize ALL of them to migrate at the exact same moment in time is nigh on impossible.

Can this convince you to reconsider? If need be, I can ask my team to provide a patch for backward compatibility for you.

Regards, Jeroen

afmiller wrote Nov 6, 2014 at 6:54 AM

Hello Jeroen,

Please help me understand the problem, I can't see it.

As a content provider, LtiLibrary does not (and has never) added Realm to the Authorization header. So there is nothing to fix on the Tool Provider side. Your LTI Tool Provider code should work with every Tool Consumer.

As an LTI consumer, the problem you reported occurred when a Tool Provider using some other library or code that does add Realm to the Authorization header, but (correctly) calculated the signature without it. In that case your Tool Consumer code--using an older version of LtiLibrary--(incorrectly) calculated a different signature. You can fix your Tool Consumer code by updating to LtiLibrary 1.4.5+.

In other words, it looks to me like this problem only affects Tool Consumers using LtiLibrary interoperating with Tool Providers Tool Providers not using LtiLibrary. The code you suggested would only be required if other LTI libraries include Realm in the Authorization header and incorrectly include Realm in the signature calculation. Are you seeing this happen?

jhabets wrote Nov 11, 2014 at 2:37 PM

I stand corrected! (I had falsely assumed the realm bug would also affect providers based on your library.)

jhabets wrote Nov 11, 2014 at 2:37 PM

Thank you for your explanation