Connect Medialake to your Ping Identity or Okta identity provider so that your people sign in with their company credentials.

What to expect

With SAML2 enabled, the login page shows a single Sign in with Ping or Sign in with Okta button. Medialake acts as a SAML 2.0 service provider: your identity provider (IdP) authenticates the user and sends Medialake a signed assertion; Medialake checks the signature against the certificate you upload, reads the user's email address and name from the assertion, and signs them in. Nobody types a Medialake password.

Setup happens in this order:

Register Medialake as an application in Ping or Okta, using Medialake's service-provider metadata.
Download your IdP's metadata file and signing certificate.
Upload both on Medialake's Access page, set the attribute names, and Save Changes.
Run Test Connection, which takes you through a real sign-in at your IdP and records the result.
Turn the provider on.

 Site Admin                     Ping / Okta                    Medialake
     │  create SAML app from          │                            │
     │  Medialake's SP metadata       │                            │
     │───────────────────────────────▶│                            │
     │  download IdP metadata         │                            │
     │  + signing certificate         │                            │
     │◀───────────────────────────────│                            │
     │  upload both, Save Changes     │                            │
     │────────────────────────────────┼───────────────────────────▶│
     │  Test Connection               │                            │
     │────────────────────────────────┼───────────────────────────▶│
     │                                │  sign-in request           │
     │                                │◀───────────────────────────│
     │                                │  signed assertion          │
     │                                │───────────────────────────▶│
     │  Last test passed → Enable     │                            │
     │────────────────────────────────┼───────────────────────────▶│

Medialake stores the uploaded metadata and certificate encrypted.

Before you begin

You will need:

A Site Admin account in Medialake — the Access page is not visible to regular users
Administrator access to Ping or Okta, to create a SAML application and download its metadata and certificate
Your Medialake address, for example https://yourcompany.medialakeapp.com
A user account in your IdP that you can sign in with during the connection test. It does not need a Medialake account, but the IdP must send an email address for it.

Keep Email & password enabled while you work. If SAML2 becomes the only sign-in method and the IdP is misconfigured, nobody can sign in to fix it — see Managing Sign-In Methods on the Access Page.

Step 1: Register Medialake in your identity provider

Create a SAML 2.0 application for Medialake in Ping or Okta. Your IdP will ask for the service-provider details below. Follow your IdP vendor's own documentation for where these fields live; the names vary between products.

Your IdP asks for	Value
Service-provider metadata	`https://yourcompany.medialakeapp.com/auth/saml2/metadata` — import this URL or upload the file it returns. It carries all the values below.
Entity ID, Audience or Issuer	`https://yourcompany.medialakeapp.com/auth/saml2`
ACS URL, Reply URL or Single sign-on URL	`https://yourcompany.medialakeapp.com/auth/callback` (HTTP-POST binding)

Replace yourcompany.medialakeapp.com with your own Medialake address. If your environment was provisioned with custom service-provider values, the metadata URL always reflects the correct ones, so prefer importing it over typing values by hand.

Medialake identifies users by an email attribute, not by the NameID, so any NameID format your IdP prefers will work. Configure the application to release these attributes in the assertion:

Attribute	Required	Notes
Email address	Yes	Without it the test fails and nobody can sign in.
Display name, or first name and last name	No	Used to name new accounts. Falls back to the part of the email address before `@`.
Groups	No	The first value names the personal team Medialake creates for a new user.

You can use any attribute names — you will tell Medialake what they are in Step 2. If you use the common names, Medialake finds them without further configuration:

Email:email, mail, emailAddress, or the standard claim URIs urn:oid:0.9.2342.19200300.100.1.3, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress and http://schemas.xmlsoap.org/claims/EmailAddress
Name:name, displayName, cn, commonName, or the standard claim URIs for name, display name and common name
First and last name:givenName, firstName, first_name and sn, surname, lastName, last_name, or the standard claim URIs
Groups:https://schemas.microsoft.com/ws/2008/06/identity/claims/groups

Then download two files from the application you created:

The IdP metadata, an XML document. It must describe an HTTP-Redirect single sign-on endpoint and include at least one signing certificate. Maximum size 512 KB.
The signing certificate, as a .crt, .cer or .pem file. It must be one of the signing certificates listed in the metadata — Medialake compares their fingerprints and rejects a certificate that does not match. Maximum size 1 MB.

Step 2: Upload the configuration in Medialake

Sign in to Medialake as a Site Admin and open Administration → Access.
In the SAML2 section, find the row for your provider — Ping or Okta — and select the arrow at the end of the row to expand its configuration panel.
Under Metadata Configuration, select Upload and choose the IdP metadata file. Once a file is stored the button reads Replace and the file name is shown.
Under X.509 signing certificate, select Upload and choose the certificate file.
Fill in Email attribute, Name attribute and Groups attribute with the names of the attributes your IdP releases. Leave a field empty if your IdP uses one of the common names listed in Step 1; leaving Groups attribute empty uses the Microsoft groups claim.
Select Save Changes.

If a file is rejected, the message under it explains why:

Message	What to check
The metadata must be a valid SAML2 identity provider metadata document.	You uploaded the wrong file, or an XML document that is not IdP metadata.
The metadata must describe an identity provider with an HTTP-Redirect single sign-on endpoint.	The metadata only lists an HTTP-POST endpoint. Export the metadata again with the redirect binding included.
The metadata must contain at least one signing certificate.	The export omitted the certificate. Re-export it from the IdP with signing certificates included.
The certificate must contain a valid X.509 certificate.	The file is not a certificate, or is not PEM-encoded. Export it as Base64 text beginning with `-----BEGIN CERTIFICATE-----`.
The certificate does not match any signing certificate in the metadata.	The certificate and metadata come from different applications, or the IdP rotated its certificate after the metadata was exported. Download both again from the same application.
Upload the identity provider metadata file. / Upload the identity provider signing certificate.	Both files are required before the configuration can be saved.

After a successful save, the provider's Status changes from Not set up to Disconnected, the panel shows Not tested yet, and the Enabled switch stays locked with the tooltip "Test Connection" before enabling.

> Saving clears any previous test result. Every change to the files or the attribute fields must be tested again before the provider can be enabled.

Step 3: Test the connection

The test performs a genuine SAML sign-in through your IdP without signing anyone in to Medialake and without creating an account.

In the provider's configuration panel, select Test Connection. The button is available once the configuration is saved and the provider is switched off.
Medialake sends you to your IdP. Sign in there with a user the application is assigned to.
Your IdP returns you to the Access page. A message reports the result, and the panel shows Last test passed or Last test failed with the time and a short explanation.

You stay signed in as yourself throughout. Finish the sign-in within ten minutes of starting the test, and do not edit the configuration while a test is in progress.

Result shown in the panel	Meaning and what to do
The SAML2 connection test passed.	The assertion was valid and carried an email address. Go to Step 4.
The identity provider rejected the sign-in request: …	The IdP refused before issuing an assertion. Check that the test user is assigned to the application and that the entity ID and ACS URL in the IdP match Step 1. The text after the colon is the IdP's own reason.
The identity provider responded but the assertion could not be validated. Check the signing certificate and the entity ID.	The assertion arrived but its signature or audience did not check out. Confirm the uploaded certificate is the IdP's current signing certificate and that the IdP is sending the entity ID from Step 1.
The identity provider signed in successfully but sent no usable email address, so nobody would be able to log in. Attributes received: …	Everything works except the email. The message lists the attribute names the IdP actually sent — either release an email attribute from the IdP, or enter one of the listed names in Email attribute and save again.
The test took too long to complete. Start it again and finish signing in within ten minutes.	The ten-minute window expired. Run the test again.
The configuration changed while the test was running. Save it, then test again.	The saved configuration was edited between starting and finishing the test. Test again.

Step 4: Enable the provider

Turn on the Enabled switch in the provider's row. The Status changes to Connected.
Google and Azure SSO are switched off automatically, and the SSO section shows a SAML2 active tag.
Open your login page in a private browser window and confirm the Sign in with Ping or Sign in with Okta button appears. Ask one user to sign in with it before you rely on it.

Only one SAML2 provider can be active at a time. If you later enable the other provider, it becomes the active one and the first shows Disconnected.

To stop offering SAML2, turn the switch off. If it is the only enabled method, switch on Email & password first; Medialake refuses to disable the last sign-in method.

How SAML2 sign-in works day to day

Users select Sign in with Ping or Sign in with Okta on the login page and authenticate at your IdP. If they already have an IdP session, they arrive in Medialake without seeing a sign-in screen.
First sign-in creates the account. Medialake creates a user with the email address from the assertion, a name taken from the name attribute (or first and last name, or the part of the email before @), and a personal team. The team is named after the first value of the groups attribute if one is sent, otherwise after the user. New accounts are Regular Users; a Site Admin can change the account type in Manage Users. SAML2 users do not need to be on the registration whitelist.
Existing accounts are matched by email. A person who already has a Medialake account with the same email address signs in to that account and keeps their teams, roles and content.
Deactivated users are refused with This account has been deactivated. Contact your administrator to restore it.
If a sign-in fails, the login page shows the reason and a six-character reference, for example Quote reference A1B2C3 to support. Ask the user for that reference when you contact support: it identifies the exact attempt in Medialake's logs.

Updating the configuration

Do this when your IdP rotates its signing certificate, when you change the attributes it releases, or when you move to a new IdP application.

Make sure another sign-in method is enabled, then turn the provider's Enabled switch off. While a provider is enabled, its configuration is read-only.
Expand the row, Replace the metadata and certificate, adjust the attribute fields, and Save Changes.
Test Connection, then turn the provider back on.

Plan certificate rotations in advance: once the IdP starts signing with a certificate Medialake does not have, every SAML2 sign-in fails with the assertion could not be validated message until you upload the new one.

Troubleshooting

Symptom	What to check
The Enabled switch is locked	Hover over it. Requires config setup before enabling means the metadata or certificate is missing; "Test Connection" before enabling means the saved configuration has not passed a test yet.
Test Connection is unavailable	The provider is currently enabled, or the configuration has not been saved.
Save and test the SAML2 configuration before enabling it.	The switch was toggled before a passing test was recorded. Run Test Connection first.
Disable SAML2 before editing its configuration.	You tried to save changes to the active provider. Switch it off first.
At least one sign-in method must remain enabled.	You tried to disable SAML2 while it was the only method. Enable Email & password, then try again.
The login page shows Google and Microsoft Azure buttons instead of the SAML2 button	The SAML2 switch is off. Enabling it hides the SSO buttons.
A user gets Quote reference … to support	Note the reference and the message. Rejected the sign-in request points to the IdP (assignment, entity ID, ACS URL); could not be validated points to the certificate; deactivated means the Medialake account was deactivated.

If the issue continues, contact [email protected] with your Medialake address, the provider (Ping or Okta), the exact message from the panel or login page, and any reference code. Do not send the signing certificate's private key — Medialake never needs it.

Questions about SAML2? Contact [email protected].

Setting Up SAML2 Single Sign-On with Ping or Okta