LTI: Invalid signature for signature method HMAC-SHA1

[Ruth Lang]

Hi,

we have upgraded our pre-production system to MH 1.6.0  and now we want to test the LTI interface to our LMS.

When we try to get a connection to our engage node we received the following error message:

HTTP ERROR 401

Problem accessing /lti.
Reason: Invalid signature for signature method HMAC-SHA1

The http - request is exactly the same as in our production system, except the server names (see attached file). And there it works fine.

I assume "oauth_signature:E+H8LXgbYoHBB3XUpWYLzmWl1Ls=" is the signature and is created on the LMS side.

Why is this signature rejected on the MH side ?

Surprisingly we had no problems during the QA stage on the All-In-One test machine.

Regards

Ruth

[Ruth Lang]

HI,

I think we have found the solution ourselves ( after reading old messages :-) )

• Our production server uses directly https (https://<mh_server>:8443)
• Our pre-production server is behind an Apache proxy, passing https:<server>:80 to http://<mh_server>:8080 )
  

We will figure this out.

Regards

Ruth

[Tobias Wunden]

Hi Ruth,

my guess is you are referring to 

- https://<mh-server>:443

- https://<apache>:443 -> http://<mh_server>:8080

Not to be nitpicking here, just to make sure. You may want to make sure your pre-production Proxy server (Apache?) is setting the X-Forwarded-SSL:

# Instruct Matterhorn to assume HTTPS as the protocol

Header set X-Forwarded-SSL "on"

Not sure if that helps, but it might be a first hint.

Tobias

--

Tobias Wunden
CTO, Co-Founder
http://www.entwinemedia.com
Entwine - For the Open Minded

To unsubscribe from this group and stop receiving emails from it, send an email to matterhorn-use...@opencast.org.

[Ruth Lang]

Hi Tobias,

- https://<apache>:443 -> http://<mh_server>:8080

The above line is exact what we are using now.

Everything works fine in our cluster except this stupid LTI interface.

And I really can not understand why I should/must implement all this certificate stuff for the „real“ engage node behind a proxy.

# Instruct Matterhorn to assume HTTPS as the protocol

Header set X-Forwarded-SSL „on"

When I use this line in my proxy configuration I have also to configure the engage node with SSL ?

Ruth

[Per Pascal Grube]

Hi Ruth,

I think I also had this issue while playing around with LTI. The issue is if
remembert correctly that Matterhorn, when it recalculates the oauth-signature
uses its own server url http://<mh_server>:8080. When you create the oauth-
signature, you use probably use https://<apache> to calculate it. You can work
around it if you create the signature for the matterhorn-server itsself and
the then still send create a lti-form in the lms to https://<apache>:443. But
that of course would require you to hack the code on the lms.

Regards.

Pascal

On Friday 30 January 2015 14:53:44 Ruth Lang wrote:
> Hi Tobias,
>
> > - https://<apache>:443 -> http://<mh_server>:8080
>
> The above line is exact what we are using now.
> Everything works fine in our cluster except this stupid LTI interface.
>
> And I really can not understand why I should/must implement all this
> certificate stuff for the „real“ engage node behind a proxy.
> > # Instruct Matterhorn to assume HTTPS as the protocol
> > Header set X-Forwarded-SSL „on"
>
> When I use this line in my proxy configuration I have also to configure the
> engage node with SSL ?
>
> Ruth
>
> > Not sure if that helps, but it might be a first hint.
> >
> > Tobias
> >
> > --
> >
> > Tobias Wunden
> > CTO, Co-Founder

> > http://www.entwinemedia.com <http://www.entwinemedia.com/>

> > Entwine - For the Open Minded
> >
> >> On 30.01.2015, at 12:40, Ruth Lang <ruth...@googlemail.com

> >> <mailto:matterhorn-use...@opencast.org>.>

> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to matterhorn-use...@opencast.org

> > <mailto:matterhorn-use...@opencast.org>.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to matterhorn-use...@opencast.org.

--
Per Pascal Grube
IZUS/TIK
Universitaet Stuttgart Tel: ++49-711-685-60011
Allmandring 30a
70550 Stuttgart www.tik.uni-stuttgart.de


***********************************************************

[Ruth Lang]

Hi Pascal,

after browsing a little bit about oauth 1.0 I think you are absolutely right. 

If we switch the protocol from http to https for the real engage node (https://<mh-server>:8443) , would this really help ?

I can remember that Alexander from Ulm has posted a solution in this direction.

The LMS creates a signature which contains the proxy name ( https://<apache-proxy>:443).

Matterhorn will create a signature which contains the MH server name (https://<mh-server>:8443).

How can the signature ever match ?

Or am I missing something in the configuration files ?

Regards

Ruth

> >> <mailto:matterhorn-users+unsub...@opencast.org>.>

> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to matterhorn-use...@opencast.org

> > <mailto:matterhorn-users+unsub...@opencast.org>.

[Lars Kiesow]

Hi everyone,
I do admit that I don't have a lot of knowledge about OAuth, but when I
read this, it seems like it would make sense to make the URL used for
the OAuth signature a dedicated configuration option. Would that help?
–Lars

On Sat, 31 Jan 2015 10:23:26 -0800 (PST)
Ruth Lang <ruth...@googlemail.com> wrote:

> Hi Pascal,
>

> after browsing a little bit about *oauth* *1.0* I think you are

> absolutely right.
>
> If we switch the protocol from http to https for the real engage node

> ( *https://<mh-server>:8443*) , would this really help ?

> I can remember that Alexander from Ulm has posted a solution in this
> direction.
>
> The LMS creates a signature which contains the proxy name (

> *https://<apache-proxy>:443*).

> Matterhorn will create a signature which contains the MH server name (

> *https://<mh-server>:8443*).

> > <javascript:>

[Per Pascal Grube]

Hi Ruth,

On Saturday 31 January 2015 10:23:26 Ruth Lang wrote:
> Hi Pascal,
>

> after browsing a little bit about *oauth* *1.0* I think you are absolutely
> right.
>

> If we switch the protocol from http to https for the real engage node (

> *https://<mh-server>:8443*) , would this really help ?

> I can remember that Alexander from Ulm has posted a solution in this
> direction.

I guess it would work. I think that the HttpRequest tells you if you use http
or https, and this breaks the signature.

> The LMS creates a signature which contains the proxy name (

> *https://<apache-proxy>:443*).
> Matterhorn will create a signature which contains the MH server name (
> *https://<mh-server>:8443*).

> How can the signature ever match ?
>
> Or am I missing something in the configuration files ?

I think what you could try to get it working, if you specify the mh-server
org.opencastproject.server.url https://mh-server
without the port, and configure the apache to push the data to the mh-
server:8443 with https.

Another possibility would be to directly push everything to mhserver:8443
using xinetd without proxying it in apache.

Regards, Pascal

> > > >> On 30.01.2015, at 12:40, Ruth Lang <ruth...@googlemail.com
> >

> > <javascript:>

> > > >> email to matterhorn-use...@opencast.org <javascript:>
> > > >> <mailto:matterhorn-use...@opencast.org <javascript:>>.>

> > > >
> > > > To unsubscribe from this group and stop receiving emails from it, send
> >
> > an
> >

> > > > email to matterhorn-use...@opencast.org <javascript:>
> > > > <mailto:matterhorn-use...@opencast.org <javascript:>>.

> > >
> > > To unsubscribe from this group and stop receiving emails from it, send
> >
> > an
> >

> > > email to matterhorn-use...@opencast.org <javascript:>.
> >
> > ***********************************************************

[Ruth Lang]

Hi,

thank you all for your comments and hints.

The good news: It is working now, but I am not so sure why. May be there can be other solutions.

Here is our configuration for MH 1.6.0 (may be helpful for the next adapter):

Apache Server:

<VirtualHost *:443>
    ServerName <server-name>
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyRequests Off
    ProxyPreserveHost On
    ProxyPass / https://<mh-engage-name>:8443/
    ProxyPassReverse / https://<mh-engage-name>:8443/
    SSLEngine on
    SSLProxyEngine On
    SSLCertificateFile       <path>/cert.pem
    SSLCertificateKeyFile    <path>/key.pem
    SSLCertificateChainFile  <path>/chain.pem
</VirtualHost>

/etc/matterhorn/config.properties:

org.osgi.service.http.secure.enabled=true
org.osgi.service.http.port.secure=8443
org.apache.felix.https.keystore=/etc/matterhorn/keystore2
org.apache.felix.https.keystore.password=<passwd>
org.apache.felix.https.enable=true
org.opencastproject.server.url=https://<server-name>:443

/etc/matterhorn/load/org.opencastproject.organization-mh_default_org.cfg 

server=<server-name>
port=-1
prop.org.opencastproject.admin.ui.url=http://<mh-admin-name>:8080
prop.org.opencastproject.engage.ui.url=https://<server-name>:443 

> > > >> <mailto:matterhorn-users+unsub...@opencast.org <javascript:>>.>

> > > >
> > > > To unsubscribe from this group and stop receiving emails from it, send
> >
> > an
> >
> > > > email to matterhorn-use...@opencast.org <javascript:>

> > > > <mailto:matterhorn-users+unsub...@opencast.org <javascript:>>.

[Ruth Lang]

Hi Lars,

to me it sounds like a good idea to make the URL used for the OAuth signature configurable.

For instance in the file /etc/matterhorn/security/mh_default_org.xml

Now I am forced to use https, an additional certificate and the java keystore stuff also for the "real" server behind the proxy. 

Pretty much effort for using the LTI interface. 

Regards

Ruth