Where a Site Admin controls how people sign in to Medialake: SAML2 through Ping or Okta, Google and Microsoft Azure SSO, and email & password.
What the Access page controls
The Access page decides which sign-in methods are offered on your Medialake login page. It has a single tab, Sign-In, with three sections:
Section | What it controls | Read more |
SAML2 | Sign-in through your own identity provider — Ping or Okta — using SAML 2.0. | |
SSO | Sign-in with a Google or Microsoft Azure account. | |
Email & Password | The standard sign-in form with an email address and password. | This article |
The page changes how people sign in. It does not create or remove user accounts, and it does not change what a user can do once they are signed in — see User Roles and Privileges for that.
Opening the Access page
You need to be a Site Admin. Regular users do not see the Administration menu.
Open the side menu and select Administration.
Select Access.
The page opens on the Sign-In tab with the three sections below.
The SAML2 section
The SAML2 table lists each identity provider Medialake can connect to — Ping and Okta — with three columns:
Column | What it shows |
Provider | The identity provider's name and logo. |
Status | Not set up — the metadata file or signing certificate has not been uploaded yet. Disconnected — the provider is configured but not enabled. Connected — the provider is enabled and users can sign in with it. |
Enabled | The switch that turns the provider on or off. |
Select the arrow at the end of a row to expand its configuration panel. The panel is where you upload the identity provider's metadata and signing certificate, set the attribute names, Save Changes, and run Test Connection. The full procedure is in Setting Up SAML2 Single Sign-On with Ping or Okta.
The Enabled switch stays locked until the provider has been configured and a connection test has passed. Hover over a locked switch to see why: Requires config setup before enabling or "Test Connection" before enabling.
The SSO section
The SSO table lists Google and Azure, each with a Status of Connected or Disconnected and an Enabled switch. Turning a switch on puts that provider's button on the login page; turning it off removes it. There is nothing else to configure: the connection between Medialake and Google or Microsoft is provisioned as part of your Medialake environment.
While a SAML2 provider is enabled, the SSO section is grayed out and shows a SAML2 active tag next to its heading. See Rules that apply across the page below.
The Email & Password section
A single row, Email & password, labeled Default sign-in method, with a status of Active or Inactive and a switch.
When it is on, the login page shows the Email and Password fields, the Remember Me checkbox, the Forgot password link, the Sign in button and — where self-registration is enabled — the Sign up link. When it is off, all of these disappear and users must sign in through SAML2 or SSO instead.
Rules that apply across the page
Medialake enforces these rules when you use the switches. Each one produces a message on the page if you try to break it.
At least one sign-in method must stay enabled. You cannot switch off the last remaining method. The page reports At least one sign-in method must remain enabled.
Only one SAML2 provider can be active at a time. Enabling a second SAML2 provider makes it the active one and disconnects the first.
Enabling SAML2 switches off Google and Azure SSO. Both SSO switches are turned off automatically and locked while SAML2 is enabled. Turning SAML2 off again does not turn them back on — switch them on yourself if you want them back.
A SAML2 provider cannot be enabled until it has been saved and successfully tested. Saving a configuration clears its previous test result, so every change to the metadata, certificate or attributes needs a fresh Test Connection before the switch unlocks.
A SAML2 configuration cannot be edited while it is enabled. Switch the provider off, make the change, test, then switch it back on.
Rules 1 and 3 together have a practical consequence: if SAML2 is your only enabled method, you cannot turn it off directly, and you cannot turn SSO on while it is active. Enable Email & password first, then disable SAML2.
What users see on the login page
Changes take effect the next time the login page loads. People who are already signed in are not signed out.
Enabled on the Access page | What appears on the login page |
Email & password | The email and password form. |
SAML2 (Ping or Okta) | A single Sign in with Ping or Sign in with Okta button. The Google and Microsoft Azure buttons are hidden. |
SSO — Google and/or Azure, with SAML2 off | A Google button, a Microsoft Azure button, or both. |
Other sign-in options that Medialake offers, such as passkeys, are not controlled from this page.
Recommended rollout
Whichever method you are introducing, keep Email & password enabled and make sure at least one Site Admin can sign in with it until the new method has been used successfully by a few people. If an identity provider is misconfigured or unavailable, that account is how you get back in to fix it.
Questions about sign-in settings? Contact [email protected].