Single Sign‑On (SSO) Integration

What is Single Sign-On (SSO)?

Single Sign-On allows users to sign in once using their organisation’s login and then access multiple systems such as MediRecords - without needing separate usernames or passwords.

Instead of managing individual logins for each application, your organisation controls access through a central identity provider. This approach is commonly used by larger practices and organisations that use multiple systems daily.

Activating Single Sign-On (SSO)

Single Sign-On is available as an add-on feature for organisations that use an Identity and Access Management (IAM) platform (also known as an Identity-as-a-Service provider).

MediRecords supports integration with a range of identity providers, including (but not limited to):

• Microsoft Azure Active Directory
• Okta
• Auth0

To activate SSO for your MediRecords tenant, please contact your Customer Success Manager, who will arrange for the feature to be enabled.

Configuring Single Sign-On (SSO)

Once Single Sign-On has been enabled for your tenant, configuration must be completed by a Practice Owner.

To configure SSO:

1. Log in to MediRecords as a Practice Owner and navigate to More > Settings > Configuration Settings.
    
2. Open Care System Configuration.
    

3. To complete the setup, select the SAML Integration tab, enable SAML Integration, enter your identity provider's details, and click Save.

   ℹ️ Note: Your identity provider will supply the required configuration details, such as:

   • Identity Provider Entity ID
   • Identity Provider SSO URL
   • SAML Certificate

   For Azure, you can find this information under Step 6 Azure Entra ID (Azure Active Directory) Configuration.

   For Okta, you can find this information under Step 8 of Okta Configuration.

   For Auth0, you can find this information under Step 4 of Auth0 Configuration

   
    

Once configured, users will authenticate through your organisation’s identity provider when logging in to MediRecords.

Setting Up Your Identity Provider

Before completing the SAML Integration step above, your identity provider needs to be configured with MediRecords' details. The steps differ slightly depending on which identity provider your organisation uses.

Azure Entra ID (Azure Active Directory)

1. In the Azure Portal, go to Azure Active Directory > Enterprise Applications. 
   
   
   
    
2. Select Create your own application, give it a name (e.g. MediRecords), choose Integrate any other application you don't find in the gallery (Non-gallery), and select Create. 
   
   
    
3. On the application's Single sign-on page, select SAML. 
   
   
     
4. Select Upload metadata file and upload MediRecords' SAML metadata file, downloaded from https://api-mrapp.medirecords.com/oauth/saml/metadata (save it as an .xml file first), then click Save.
   
   
    
5. Under Attributes & Claims, select Add new claim, and enter urn:oasis:names:tc:SAML:attribute:subject-id as the Name, with user.mail as the Source Attribute.
   
   
      

6. Scroll to the Certificate section and download the Certificate (Base64). Note the Login URL and Azure AD Identifier, you'll need these for the configuration in the MediRecords side. 
   

   
    

   ℹ️ Note: Once finished we will have these values populated from Azure Identity:Identity Provider Entity ID = value from Azure AD Identifier

   Identity Provider SSO URL = value from Login URL

   SAML Certificate = value from Certificate (Base64)

   
    

7. Under Users and groups, assign the users who should have access. 
   
   
     

Okta

1. In the Okta Admin Console, go to Applications and select Create App Integration. 
   
   
   
     
2. Choose SAML 2.0 and select Next. 
   
     
3. Enter an App Name (e.g. MediRecords) and select Next. 
   
     
4. Okta doesn't support uploading a metadata file, so the SAML details must be entered manually:
   • Single sign on URL: https://api-mrapp.medirecords.com/oauth/saml/callback
   • Audience URI (SP Entity ID): https://app.medirecords.com
   • Application username: Email
     
       
5. Select I'm an Okta customer adding an internal app, then Finish. 
   
     
6. Go to Applications > Single Sign On > Attributes Statement (under legacy configuration) and add an attribute: Name urn:oasis:names:tc:SAML:attribute:subject-id, Name format Unspecified, Value user.email. 
   
     
7. Under Assignments, assign the users who should have access. 
   
   
   
   
     
8. Go to Sign On and select View SAML setup instructions to get the values needed for MediRecords. 
   
   

Auth0

Prerequisites
Before starting, you'll need:

1. An Auth0 account and tenant (Identity Provider)
2. Admin access to the Auth0 Dashboard
3. SAML configuration set up on the tenant (Service Provider side)

Step 1: Create a SAML Application in Auth0

1. Log in to the Auth0 Dashboard
2. Navigate to Applications → Applications
3. Click Create Application
   
     
4. Choose a Name (e.g. "Medirecords") and set Type to "Regular Web Application"
5. Click Create

Step 2: Enable the SAML Add-on

1. Open the newly created application
2. Go to the Add-ons tab
   
     
3. Enable "SAML2 Web App"
4. Click Settings
   

Step 3: Configure Basic SAML Settings

Application Callback URL - set to the SP's Assertion Consumer Service URL:

https://api-mrapp.medirecords.com/oauth/saml/callback

Audience (Entity ID) - set to the SP Entity ID:

https://app.medirecords.com

NameID Configuration: recommended settings:

nameIdentifierFormat: "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
nameIdentifierProbes: ["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]

Attribute Mapping: set the email as subject-id:

mappings: { "email": "urn:oasis:names:tc:SAML:attribute:subject-id" }

Full setting example (for reference):

{
"audience": "https://app.medirecords.com",
"recipient": "https://api-mrapp.medirecords.com/oauth/saml/callback",
"destination": "https://api-mrapp.medirecords.com/oauth/saml/callback",
"signResponse": true,
"signAssertion": true,
"signatureAlgorithm": "rsa-sha256",
"digestAlgorithm": "sha256",
"nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
"nameIdentifierProbes": ["http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"],
"mappings": { "email": "urn:oasis:names:tc:SAML:attribute:subject-id" }
}

Step 4: IdP Metadata

1. In the SAML Add-on settings page, go to the Usage tab
2. Download the IdP certificate
3. Download and verify the Identity Provider Metadata URL
   

This metadata includes: IdP Entity ID, SSO Endpoint, Signing Certificate

Configuration properties equivalency:

Step 5: User Management
Add a user using the same email address as their MediRecords (Mrapp) user.

Step 6: Test Result
Log in with the registered email. The Access Origin will be from the Auth0 domain.

Troubleshooting

User cannot log in through Single Sign-On

Cause: The user's email address in the identity provider (Azure, Okta, or Auth0) does not match their email address in their MediRecords user account.

Resolution: Confirm the user's identity provider email address exactly matches their MediRecords user account email, then have them try logging in again. Assigned users must use the same email address in the identity provider as they use in MediRecords.

Escalate: If the email addresses already match and the user still cannot log in, contact your Customer Success Manager or MediRecords Support.

Multi-Factor Authentication (MFA) prompts have stopped appearing after enabling SSO

Cause: Enabling Single Sign-On bypasses MediRecords' own MFA. Once a user authenticates through the identity provider, they are logged in to MediRecords directly, so MediRecords no longer prompts for MFA itself.

Resolution: This is expected behaviour once SSO is active. If your organisation still needs multi-factor verification, configure MFA within your identity provider instead of relying on MediRecords' own MFA.

Escalate: If login behaviour differs from what is described here, contact your Customer Success Manager.

Login or access issues appear shortly after enabling SSO

Cause: Single Sign-On was enabled before the MediRecords go-live was complete, or before the required API keys were created.

Resolution: Before enabling SSO, confirm with your Customer Success Manager that go-live is complete and that any required API keys have been created. Your Customer Success Manager can guide you through these readiness checks.

Escalate: If issues continue after these checks, contact MediRecords Support. Support may require screen sharing to help diagnose SSO issues once it is enabled.

Frequently Asked Questions

• Does MediRecords only support Azure?
  No. MediRecords supports Single Sign-On with multiple identity providers. Azure Active Directory is one option, but other providers such as Okta and Auth0 are also supported.  
   
• What is the difference between SSO and Multi-Factor Authentication (MFA)?
  SSO and MFA serve different purposes:
  • SSO allows users to sign in once and access multiple systems using the same login.

  • MFA adds an extra verification step (such as a code or app prompt) to confirm a user’s identity.

    ℹ️ Note: SSO focuses on access management and convenience, while MFA focuses on additional security checks. Many organisations use both together.

     

• Who manages user access once SSO is enabled?

  User access is managed through your organisation’s identity provider. MediRecords relies on that system to authenticate users.