Single Sign‑On (SSO) Integration

Contents

1. What is Single Sign‑On (SSO)?
2. Benefits of using SSO
3. Activating Single Sign‑On (SSO)
4. Configuring Single Sign‑On (SSO)
5. Setting Up Your Identity Provider
6. Frequently Asked Questions

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

   
    

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 MediRecords side. 
   

   
    

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.

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.

     

     

• What happens if I also have MFA turned on along with SSO?
  If you currently have MFA enabled and then enable SSO, MediRecords' own MFA will be bypassed, authentication relies entirely on your identity provider instead. Once a user successfully authenticates through your identity provider, they'll be logged in to MediRecords directly.
   
• Are there any important considerations before enabling SSO?
  Yes. We recommend the following:
  • Do not enable SSO before your MediRecords go‑live

  • Ensure required API keys are created before SSO is switched on

    Be aware that MediRecords Support may require screen sharing to assist with troubleshooting once SSO is enabled

     

    ✅ Tip: Your Customer Success Manager can guide you through readiness checks.

     

     

• 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.