Okta SAML Setup — Mediacast CastControl

For: your IT / identity team From: Mediacast Version: 3.1 — 2026-09-27

1. What this is, and why it matters

Mediacast CastControl lets a member of your staff control the TV in their own office from their phone or laptop. This document sets up the piece that identifies them: signing in with their existing Okta account, so the controller opens on their office and nobody else's.

This is the access path for your internal users — it is not an optional extra. Office TV control depends on knowing who the person is. There is a separate QR-code flow for transient guests in suites, but by design it doesn't identify anyone, which is exactly why offices need this instead.

Everything below happens on the Okta side and takes about 30 minutes of your time. We then do the Mediacast-side work and a short joint test with you.

2. What we need from you

One thing to start: the SAML metadata URL for a new Okta application you create using the values in §3.

That URL looks like https://<your-org>.okta.com/app/<appid>/sso/saml/metadata and is on the app's Sign On tab.

We extract three values from it (the sign-on endpoint, your issuer/entity ID, and your signing certificate) and commit them to our infrastructure-as-code. We don't poll the URL at runtime.

Certificate expiry matters. Because we pin your signing certificate, office sign-in will start failing when that certificate rotates. Please tell us the rotation date if you know it, and give us a heads-up before any planned rotation. It's a two-minute change on our side, but only if we know it's coming.

3. Values to configure in Okta

These are fixed. Please use them exactly — particularly the word okta in the sign-on URL, which is an identifier on our side and can't be changed after the fact without reconfiguring both ends.

<your-realm> is the short name we assigned your organisation. It is in your onboarding bundle, together with the exact URLs already filled in.

4. Step by step in the Okta admin console

1. Applications → Applications → Create App Integration.
2. Choose SAML 2.0. Click Next.
3. App name: Mediacast CastControl (<your organisation>). Click Next.
4. On the Configure SAML step, enter the values from the table in §3.
5. Add the attribute statements in §5 — including the group statement.
6. Under Show Advanced Settings, turn on signed requests and upload our certificate (§6).
7. Click Next, then Finish.
8. Set up the app tile (§7), then assign the app (§8).
9. Go to the app's Sign On tab and copy the metadata URL (§2). Send it to us with the other items in §9.

If something below doesn't match what your Okta console shows (wording differs between Okta versions), tell us what you're seeing rather than guessing at the equivalent — a wrong value here fails silently and is slow to chase down.

5. Attribute statements

No custom or new directory attributes are required. We have deliberately designed this so that you do not need to add any new attribute to your directory. We hold the person-to-office mapping on our side, keyed on email address.

Add these three standard statements:

Group membership — for administrative access

No group is needed to use a controller. A staff member who is assigned the app and mapped to an office (§8) can control that office's TV with no group at all. Groups govern the admin portal only.

If some of your people should administer CastControl (build controllers, manage users, issue QR codes), add one group attribute statement:

and create these Okta groups. Spelling and capitalisation are matched exactly on our side — note the capital C in MediaCast:

Each level includes everything below it. A full roles-and-permissions reference is published separately in the Admin guide.

Amendment, 2026-09-27 — CastControl roles. Three further groups carry the CastControl product roles (see the roles reference in the Admin guide). They use the same attribute statement and the same MediaCast- prefix, so nothing else in your app changes:

A person in more than one of these groups chooses which surface to enter after signing in.

Please check the statement before you tell us it's done. On the Configure SAML step, click Preview the SAML Assertion and confirm an attribute named groups lists a MediaCast-… group. If the groups don't reach us, sign-in still works but people arrive without their permissions, and nothing shows an error — the preview is the only place that proves it.

6. Signed requests and our certificate

We sign the sign-in requests we send to Okta, and we ask Okta to check them. Under Show Advanced Settings on the Configure SAML step:

1. Tick Signed Requests.
2. Next to Signature Certificate, click Browse files and upload the Mediacast SP signing certificate from your onboarding bundle.

This is safe to do at any point: until we switch your integration on, nothing depends on it. Please leave everything else in Advanced Settings at its default.

7. The app tile — make it land on the controller

Your staff sign in through a short link:

`https://go.mediacast.app/<your-realm>`

It sends them through your Okta sign-in and straight to their controller. Put that link wherever your people look for tools, and set the Okta app tile up so it goes there too — an Okta SAML tile on its own lands on our sign-in service, not on the controller.

Standard tile setup, on the SAML app:

Fallback, if your Okta app doesn't offer those fields: hide the SAML app's icon (Do not display application icon to users) and add a Bookmark App pointing at the same link, assigned to the same groups. Your staff then see one tile that works.

For your IT team — the download portal. Administrators (the MediaCast-Admin group) can also sign in to the Mediacast download portal with the same account, to fetch appliance images and your deployment kit. Use your organisation's form of the link, which tells the portal which sign-in to use:

`https://www.mediacastnet.com/downloads.html?realm=<your-realm>`

Without ?realm=… the portal offers Mediacast's own staff sign-in, which your account cannot use.

8. Who to assign the app to

Assign the app to the staff who should be able to control the TV in their own office, plus anyone who needs the admin portal (put those people in the groups from §5).

Being assigned the app is necessary but not sufficient — a person only reaches a controller once we've also mapped their email address to a specific office on our side (§10). So assigning the app broadly is safe: an assigned person with no mapping simply sees a message telling them to contact support.

9. What to send back

Reply on the existing Mediacast onboarding thread with:

1. The metadata URL from §2.
2. The list of offices to enable, and for each one the email address of the person (or people) who should control that office's TV. A spreadsheet is ideal. Example:

Use whatever office naming you already use internally — we'll match it to the locations on our side and come back to you if anything is ambiguous.

1. A screenshot of the Preview the SAML Assertion groups line (§5), if you set up groups.
2. Confirmation that Signed Requests is on and our certificate is uploaded (§6).
3. Optionally, your signing-certificate rotation date (§2).

10. What happens after that — and the joint test

On our side we add your IdP to our infrastructure-as-code, create the sign-in client, and load the email-to-office mapping you sent. That's roughly a half-day of Mediacast work, scheduled at our end.

Then we do a joint test of about 30 minutes, for which we need one or two people from your side:

• A test user — a real Okta account, assigned to the app, mapped to a real office, ideally one we can see or have someone standing in.
• That person opens the sign-in link (§7), signs in with Okta, lands on the controller, and changes a channel and the volume on the TV in that office.
• We confirm on our side that the sign-in, the office resolution, and the command all landed.

If the test passes, office sign-in is ready for your staff. If it doesn't, nothing else in the deployment is affected and we debug without time pressure.

11. Security notes

Worth having on the record for your InfoSec review:

• We never see your passwords or MFA. Authentication happens entirely at Okta, with whatever MFA and conditional-access policy you enforce there; we receive a signed assertion afterwards.
• We validate your signature on every sign-in. Assertions must be signed by the certificate in your metadata; unsigned or mis-signed assertions are rejected. Our requests to Okta are signed too (§6).
• We don't store your SAML assertions or tokens. They're used for the exchange and discarded.
• What we store per user: email, first name, last name, the office you've told us to map them to, and — for admin-portal users — the MediaCast- group names from your assertion.
• Deprovisioning follows Okta. We re-read your attributes on every sign-in, so unassigning or disabling someone in Okta stops their access at their next sign-in attempt, and removing someone from a group removes that permission at their next sign-in. Controller sessions are time-limited rather than indefinite.
• Scope of access. Signing in this way grants control of the TV in the mapped office only, plus whatever admin-portal level the person's group grants. It grants no access to your other systems and no Mediacast administrative authority.
• You can turn it off unilaterally by unassigning or deactivating the Okta app. That disables office sign-in and affects nothing else.

12. Questions

Use the existing Mediacast onboarding thread, or the support contact on this site — please keep it to one channel, so the history stays in one place.