Logging out update!

From Thursday 7th March 2024, we're making some small changes to how user accounts linked to a keychain log out. More information on logging out can be found here.

Help centre

Submit a ticket Log in

SAML

We (OneFile) will use yourself as the identity provider to allow your users to authentication, we support SAML2 as a service provider. Our Meta data is available at the following URL: 

https://login.onefile.co.uk/api/samlsso/meta


Provisioning SAML users

Our system employs SAML user alignment to link OneFile users with your SAML accounts. This resolves the issue of users not sharing the same email domain due to variations in systems or organisational structures.

During user provisioning, an additional API call is required to set a unique identifier for the user account used in the authentication. This ensures secure access through SAML authentication.

Enabling SAML user alignment eliminates the constraint of shared email domains, accommodating diverse users and systems. This simplifies access and enhances security, allowing users from different domains to seamlessly connect with their designated SAML accounts, irrespective of email or domain differences.


User flow

  • When configuring your SAML Integration within OneFile, you must provide a domain field. This is used on our login page, if your users arrive at our site directly. Users click SSO on our login page, type in your domain (e.g. onefilecollege.ac.uk) and we will use SAML2 Post binding to send the user with an Authnrequest. 
  • We will give you a link such as login.onefile.co.uk/api/samlsso/{guid}. This guid is unique to your integration and you can use this in a simple HTML link on your site to start the authentication process for your users. This will generate and POST the Authnrequest to your system. 


AuthnRequests

As the Service Provider we will send you an AuthnRequest

  • We only use POST binding.
  • Our Authnrequest is not signed. 


SAML Response

  • We only support POST binding. 
  • We do not process any additional attributes.  
  • We expect the Subject NameId to contain a guid, which we refer to as the SAMLID. This guid is the representation of the user in your IdP system. 
  • We do support unsolicited SAML Response processing, so you can send us a SAML Response directly. 
  • We expect your SAML response to be signed using the certificate provided to us when you configured the integration in our system. 
  • SAML Responses must be signed using SHA256. 
  • RelayState is currently not implemented.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.