SSO integration connects a legal technology platform to your organization’s identity and access management system, so users sign in once through the company identity provider and reach the legal platform without a separate password. For Onit ELM and SimpleLegal, that means lawyers, legal operations staff, and business requesters use the same login they use for email. It also means your security team’s password, multi-factor authentication, and access policies apply to legal systems automatically, with a few important exceptions covered below.
What is SSO integration for a legal platform?
SSO integration for a legal platform is the configuration that lets the platform trust your identity provider to authenticate users, typically through SAML, and create or match a user account from the identity data it receives. Authentication moves to the identity provider, and the legal platform keeps control of roles and permissions.
That split matters. Single sign-on answers “who is this person?” The legal platform still answers “what may this person do?” Most problems in legal platform rollouts come from assuming the identity provider handles both. For a front door used by thousands of employees, SSO is also what makes a legal front door easy enough that people actually use it, since nobody abandons a request because they forgot a password.
Which identity providers can connect to Onit and SimpleLegal?
Onit and SimpleLegal connect to most enterprise identity providers through standard protocols, with SAML the most common. SimpleLegal integrates through Auth0, which supports SAML, Ping, Azure, Okta, OneLogin, and Windows Active Directory.
- SimpleLegal. Connects to your enterprise identity system through Auth0, so the choice of provider rarely limits the project.
- Other Onit products. Several Onit products support SAML 2.0 single sign-on with Microsoft Active Directory, Okta, and OneLogin. Configuration steps can differ between products, so confirm the process for your specific module.
- Directory ownership. Before configuration starts, confirm which provider owns employee identities, who administers it, and whether contractors or external users sit in a separate directory. Those answers shape the whole design.
The SimpleLegal platform for mid-market ELM and Onit Unity for larger programs handle identity through the same principles.
How does SSO create user accounts in a legal platform?
SSO creates user accounts in a legal platform through automatic provisioning at first login: when your identity system grants a user access, SimpleLegal creates a matching account the first time that user signs in. An administrator still configures the user’s role.
Automatic creation suits large populations of business requesters, who can be given a standard low-privilege role and start submitting requests immediately. Pre-provisioning, where administrators create accounts directly and set permissions before the user first signs in through SSO, suits lawyers, approvers, and administrators, whose access must be right on day one.
Most programs use both. Pre-provision the 20 to 100 legal and operations users whose roles matter, and let the wider business population be created automatically.
Which user attributes should the identity provider send?
The identity provider should send the attributes the legal platform needs to create and recognize each user, and SimpleLegal requires three: first name, last name, and email address. Any further attributes depend on your own design.
- Required attributes. First name, last name, and email identify the user and link their account across logins. Email must be unique and stable.
- Optional mapped attributes. Department, business unit, region, title, or manager can be mapped where your configuration uses them, for example to prefill intake forms or drive routing. Confirm each one in your tenant documentation before relying on it.
- Data quality. Directory data is often incomplete. Check a sample of 50 to 100 records for missing departments or outdated managers before any routing depends on them.
An email address that changes, after a name change or domain migration, can create a duplicate account. Agree how those cases are handled before go-live, including who merges the records and how open requests move to the surviving account.
How should roles and permissions work with SSO?
Roles and permissions with SSO should be assigned by the legal platform’s administrators, with every new user receiving a default least-privilege role and any higher access granted through an approved request. SSO proves identity, and the platform decides access.
- Default role. New business users receive a requester role that lets them submit and track their own requests, and nothing more.
- Elevated access. Triage, matter management, approval, and administrator roles are granted by a named administrator after approval, and recorded.
- Group mapping. Some implementations map identity provider groups to platform roles. Treat this as a tenant-specific design choice, and test it carefully before relying on it.
Most departments need four to six standard roles. Review elevated access quarterly, and test every role before launch, because skipping role-based security testing leads to chaotic go-lives.
How should MFA and session timeouts be handled?
MFA and session timeouts should be handled mainly through your identity provider, so legal platform access follows the same security policies as every other enterprise application. Onit supports multi-factor authentication through the SSO provider. Strong sign-in controls matter because an analysis of 12,195 confirmed breaches found credential abuse was the most common way attackers got in, at 22 percent.
Apply your standard MFA and conditional access policies to the legal platform application in the identity provider, and confirm device or location rules with your security team. For session behavior, SimpleLegal’s default inactivity timeout is eight hours, and SSO users are reauthenticated smoothly after a timeout. Test login, logout, timeout, and reauthentication before launch.
Users can reach SimpleLegal through the company application dashboard, a bookmarked login page, or the SSO option on the login screen. Pick the one you will promote in training and use it consistently.
Why does offboarding need a separate step with single sign-on?
Offboarding needs a separate step with single sign-on because disabling a user in your identity system may not automatically deactivate their account in the legal platform. An administrator should confirm the deactivation directly in the platform. Where the platform supports it, automatic deprovisioning deactivates accounts in connected systems when people leave the organization, and the manual check becomes a backstop.
- Joint process. Add legal platform deactivation to the leaver checklist, with a target of completion within one business day of the identity system change.
- Reconciliation. Compare active platform accounts with active directory accounts monthly, and deactivate any account whose identity no longer exists.
- Ownership transfer. Reassign open requests and matters before deactivating a lawyer or triage user, so nothing is left without an owner.
How do you test SSO integration across environments?
SSO integration is tested separately in each environment, usually development, user acceptance testing, and production, because each has its own identifiers, endpoints, and certificates. A configuration that works in testing proves nothing about production until production has its own run.
- Configuration checks. Confirm the identity provider and service provider identifiers, endpoints, certificates, and redirect settings for each environment. Note every certificate expiry date, and set a reminder at least 30 days ahead.
- User scenarios. Test first login, repeat login, pre-provisioned users, automatic account creation, attribute mapping, and duplicate handling. A typical plan covers 20 to 30 scenarios per environment.
- Access and exit scenarios. Test each role, MFA, session timeout, and a full leaver case through to platform deactivation.
Deployment testing from sandbox to production should include SSO as its own line item.
How do you roll out SSO to legal and business users?
SSO should roll out first to the legal team and a small pilot group of business users, then to the wider business once login, roles, and routing are proven. A short pilot catches attribute and role problems before they reach thousands of requesters.
- Pilot group. Start with 10 to 20 users covering legal, legal operations, and two or three business functions, for one to two weeks.
- Wider launch. Communicate the single login link, confirm help desk scripts for sign-in issues, and monitor duplicate accounts and failed logins daily for the first two weeks.
- Local passwords. Once users move to SSO, remove or disable any local platform passwords where your configuration allows it. A second way in is a second thing to secure, audit, and offboard.
Plan SSO early. It is one of the first dependencies in an Onit ELM implementation, and security teams often need several weeks to schedule the configuration work.
Conclusion
SSO integration gives legal platform users one familiar login and puts authentication under your enterprise security policies. It works well when the identity provider sends clean required attributes, the platform assigns least-privilege roles, MFA is enforced at the provider, and offboarding includes a direct platform deactivation step. Test every environment on its own, pilot with a small group, and keep roles and leaver checks under regular review.
How Basla can help
Basla provides delivery teams for Onit implementation, covering legal technology consulting on single sign-on requirements, identity attribute mapping, role and permission design, environment configuration support, role-based security testing, documentation, and hypercare. The team works with your IT and security staff to test every login, role, and leaver scenario before launch, alongside the wider matter management and eBilling build.
Frequently asked questions
What is SSO integration for a legal platform?
SSO integration for a legal platform lets users sign in through the company identity provider, typically using SAML, without a separate password. The identity provider authenticates the user, and the legal platform controls roles and permissions.
Which identity providers work with SimpleLegal?
SimpleLegal connects to enterprise identity systems through Auth0, supporting options including SAML, Ping, Azure, Okta, OneLogin, and Windows Active Directory.
What user attributes does SimpleLegal need for SSO?
SimpleLegal needs the identity provider to send first name, last name, and email address. Other attributes such as department or region can be mapped where a specific implementation uses them.
Does SSO assign user roles automatically?
SSO can create user accounts automatically, but an administrator still configures each user’s role in the legal platform. Many programs pre-provision legal users and give business users a default requester role.
Does disabling a user in the identity provider remove their legal platform access?
Disabling a user in the identity provider may not automatically deactivate their SimpleLegal account. Administrators should deactivate the account directly in the platform as part of the leaver process.
How is MFA handled with SSO on Onit platforms?
MFA on Onit platforms can be applied through the organization’s SSO provider, so legal platform access follows the same multi-factor and conditional access policies as other enterprise applications.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*