Shibboleth & Tobira (+ Opencast)

[Pedrotti, Maxime]

Hello,

We are trying to get Opencast and Tobira working with Shibboleth.

Unfortunately, we are facing a few issues, and there does not seem to be a lot of documentation around, especially on the topic of nginx and Shibboleth configuration. My hope is that there might be someone here who has a working environment and who is willing to share some information on their configuration and application distribution.

To limit the scope of this thread, the question is focussed on the Tobira part, but some points might touch the Opencast parts, which we have not set up yet (Tobira is higher priority, as it is facing a larger user group than Opencast's admin and engage UIs).

Our setup:
* A public web server (nginx) acts as proxy for the applications in the backend, and on each application server there is another nginx setup as a local proxy.
opencast.example.org -> public proxy -> tobira.opencast.internal.example.org -> local proxy -> Tobira
admin.opencast.example.org -> public proxy -> admin.opencast.internal.example.org -> local proxy -> Opencast Admin Node
video.opencast.example.org -> public proxy -> engage.opencast.internal.example.org -> local proxy -> Opencast Engage Node
* Only the public proxy host is publicly available, the application servers are all on internal networks and not reachable from the outside.
* A Shibboleth service provider is registered with the AAI and generally working (tested with a static sample resource before trying the integration with Tobira).

The goal:
* One service provider for the whole environment. (The daemon can be installed on several servers, I just don't want to have to register several SPs for what is essentially one service.)
* Tobira can be called without login. When a user clicks the login button, the Shibboleth handler should start its process (IdP discovery, redirect to login host, redirect back to application after success).
* Opencast can be called without login. If and when a resource needs user information, the Shibboleth handler should start its process, allowing Opencast to check if user is allowed to access the resource.

I managed to get Shibboleth login to work with Tobira (thanks to some help from Lukas Kalbertodt) by setting it up on the public proxy for the main domain (opencast.example.org). However, there are several problems with this setup:
* Tobira can only be called after having a Shibboleth session, i.e. people have to login before being able to reach the front page. This is not the desired outcome, as the front page (and public video pages) should be reachable without having to login. As an aside, Opencast cannot talk to Tobira, as it is redirected to the Shibboleth login process when trying to get `/.well-known/jwks.json` from the Tobira host. As there is no list or pattern of resources that need authentication (or no authentication), this makes it hard to setup a workable nginx configuration.
* Since Shibboleth is located on the public proxy and configured for the Tobira domain, I have to figure out how to include further configuration to allow Opencast to use the same installation under a different domain address. This might be possible with application overrides?
* Tobira's documentation describes a scenario where Shibboleth would be installed only on the Tobira host, letting Tobira decide when to call the authorizer, but I cannot find any information on how this would actually work, and the documentation is very vague on this point.
* Installing Shibboleth directly on the Tobira host and just handing all requests via the public proxy down to the internal proxy does not work: The handler endpoints are reachable, but when the handler sends me to our EDS page, it puts the internal proxy's hostname in the redirect parameter, which is a) not on the allow list, and b) not the right return target for after the IdP login.

Long story short:
I am looking for a more detailed information on how to setup the environment to work with Shibboleth for authentication. If someone has a link to helpful documentation or is willing to share their configuration, it would help me a lot.

Thanks in advance, and best regards,

Maxime

[Katrin Ihler]

Hi Maxime,

maybe this webinar by Lukas could also be of use to you?
https://video.ethz.ch/events/opencast/miscellaneous/webinars/36e6a726-743d-4181-8bbd-dce83237582d.html

Cheers,

Katrin

> To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.

--
Opencast-DevOps Teamlead

ELAN e.V.
Karlstr. 23
D-26123 Oldeburg

elan-ev.de

[Pedrotti, Maxime]

Hi Katrin,

Thanks for the link! I had followed the webinar the time it was live, my initial steps were based on my notes from that session. Unfortunately, after reviewing the recording a couple of times, I still have trouble setting this up as described.

I was able to fix one problem: Calling Tobira without login is now possible, and login is performed after clicking the “Login” button. I found that the RequestMapper in the shibboleth2.xml was set to generally require a session for all paths. After changing this setting, Tobira could be navigated without logging in (of course protected pages are still protected and will tell me to login first).

The basic setup is fairly straightforward (if you have set up Shibboleth before), but the “better” solution of placing Shibboleth behind the internal proxy does not seem to work properly. I mentioned to Lukas already that I see a problem with placing the handler locations (“/Shibboleth.sso”) behind an non-public proxy, since the browser needs to be able to call this location. But even if I move the handler location to the main block of the internal proxy, it does not work as intended, Tobira does not recognize the authentication attempt.

I would still be grateful for hints to working configurations.

Thanks and best regards,

Maxime

[Pedrotti, Maxime]

Hello,

As an update to this:
After a lot of trial and error I got Shibboleth working with Tobira and Opencast as required. (Some update suggestions for the docs in both projects will be coming when a fully working environment is reached, because some crucial pieces are missing and some are wrong/outdated.)

What is *not* working:
* The “better” solution mentioned in Tobira’s docs.
* Cross-authentication between Opencast and Tobira, i.e. Tobira is not really usable.

I can login fine in Tobira (living under https://opencast.example.org/) and the Opencast Admin node separately, but uploads via Tobira return an error and will not transfer.
At first, I thought this might be dependent on the setting of `pre_auth_external_links` in Tobira, but this setting is indeed only for links to Studio and the editor (more on that below). Then, I thought I might be missing a relevant role with permission to access the `/ingest/**` endpoints, but this was not the case either: In Tobira, I get all the roles I define via my callback application, and in Opencast I have set an equivalent role mappings in the JWT and Shibboleth sections to ensure I have the same set of roles on every platform and access solution. I tried with me getting `ROLE_ADMIN`, `ROLE_STUDIO`, or several different combinations of roles, which should always allow me access to Opencast Studio.

What happens when I try to upload a video:
* The uploader calls GET https://admin.opencast.example.org/info/me.json with an Authorization header.
* The response, however, shows the anonymous user.
* The uploader calls GET https://admin.opencast.example.org/ingest/createMediaPackage with an Authorization header.
* The response is a 302 redirect to the Shibboleth handler (which would redirect to the discovery service, if followed).
* Tobira displays an error: “Failed to upload video. Internal cross-authentication error: Opencast did not authorise the upload.”

Concerning pre-authentication of external links, I could observe the setting does change the behavior of routing the user to e.g. Studio, but not the outcome.
With pre-auth set to `false`, Tobira simply shows a normal hyperlink to Studio on the admin node and opens a new tab when clicking. If no Opencast-Session is present, it redirects to the Shibboleth handler, which redirects to the discovery service, which leads to the IdP login and then back to Studio. Not pretty (because users have to choose their institution again), but working in general.
With pre-auth set to `true`, Tobira apparently uses a click event to send the user (without opening a new tab) to POST https://admin.opencast.example.org/redirect/get with the target URL and a JWT in the form body. This does not result in an authenticated user, but rather sends me the same route as before without pre-auth.

My best guess is that I am missing something in the configuration for JWT or some parts are conflicting, because apparently the Authorization header (or JWT in the form for Opencast’s redirect handler) does nothing, but I cannot find the missing (or wrong) piece. I followed the guides from Tobira and Opencast, reviewed the steps and configurations several times. Logs on Opencast and Tobira hosts show no errors (nothing at all in Tobira, as the interaction happens only on the client side, and nothing in Opencast, as far as this host is concerned, these are just generic unauthenticated requests).

Maybe someone here has an idea where else to look?

Thanks and kind regards,

Maxime

[Pedrotti, Maxime]

Hello,

Another update:
After searching and raising the loglevel for `org.opencastproject.security.jwt` I think I found the problem. Opencast was rejecting the JWTs sent by Tobira because of an “invalid signature”, which lead me to this issue on GitHub: https://github.com/opencast/opencast/issues/6092

The issue persisted for ES256 as well as ES384, none of the automatically generated keys from Tobira were accepted. After manually generating a key and configuring it in Tobira, authentication via the Tobira uploader worked, and (authorized) users can now upload videos via Tobira.

The only issue remaining is a usability issue when launching Studio or the editor from Tobira:
Shibboleth is configured for Tobira as well as the Opencast nodes (admin + engage). If I turn on pre-authentication in Tobira, the JWT will be attached to the URL for Studio, and Opencast will recognize and accept the token and correctly map the roles (verified via logs), but since the nginx/Shibboleth configuration requires a Shibboleth session for every .html path (as per Opencast’s documentation), users will be redirected to the Shibboleth handler for the admin node regardless, requiring a second selection of the home institution to be redirected to the appropriate IdP login. This is not a serious problem, as users usually are already logged in with the IdP and thus will be redirected straight back to Studio, but it might be a little confusing, considerung users have already selected their institution and logged in once before for Tobira.

I will have to evaluate the risks and problems of limiting the Shibboleth session requirement to the admin UI paths (maybe some other paths as well?) to take advantage of Tobira’s pre-authentication mechanism, otherwise we might have to live with the situation as it is now.

Kind regards,

Maxime