SAML SSO for Corporate Aviation: Why Leon Uses It

Why SAML Is Leon's Preferred Way of Delivering Single Sign-On

Single Sign-On (SSO) has become a standard expectation for any serious business application, and business aviation software is no exception — whether it is flight scheduling, crew management, or a complete flight operations platform like Leon. But "SSO" is not a single technology — it is a goal that can be reached in several different ways. At Leon, our preferred way of reaching it is SAML, and the reason is simple:

Leon is a B2B system, not a B2C system. B2C sign-in connects a user. SAML connects an organisation.

This article explains what that means in practice, why it matters especially for corporate flight departments, and — very briefly — what SAML and Identity Providers actually are.

A quick primer: SAML and Identity Providers

SAML (Security Assertion Markup Language) is an open, industry-standard protocol for exchanging authentication and authorisation data between two parties:

the Identity Provider (IdP) — the system that knows who the user is and verifies their identity, and
the Service Provider (SP) — the application the user wants to access. In this case, Leon.

When a user signs in to Leon via SAML, they never type a password into Leon at all. They authenticate against their company's Identity Provider — using whatever methods the company enforces (corporate credentials, MFA, hardware keys, device checks) — and the IdP sends Leon a cryptographically signed assertion saying, in effect: "This is Jane Smith, she is an active employee, and she is allowed to use Leon."

An Identity Provider in a corporate environment is much more than a login screen. It is the central source of truth about the organisation's people: who works there, what department and role they have, which applications they may use, from which devices, and under what security policy. Common examples include Microsoft Entra ID (formerly Azure AD), Google Workspace, Okta, Ping Identity, OneLogin, CyberArk, JumpCloud, and on-premise solutions such as Microsoft ADFS, Keycloak or Shibboleth. In large corporations, the IdP is often a heavily customised internal platform — sometimes one that is not commercially available on the market at all.

The core distinction: connecting a user vs. connecting an organisation

The most popular way to add "SSO" to an application is a "Sign in with Google" or "Sign in with Microsoft" button. This is a perfectly good model — for consumer (B2C) products. It answers one question: "Is this person who they claim to be?" And it answers it at the level of an individual user and their individual account.

Leon, however, is not a consumer product. Leon is a business system, used by operators and flight departments as one element of a wider corporate ecosystem. In the B2B model, sign-in is not just a question about a person. It is a question about the relationship between two organisations' systems:

Who in the company should have access to Leon at all?
Who decides that — and where?
What happens to that access the moment an employee leaves the company?
How does Leon fit into the company's security policy, audits, and device management?

Social login cannot answer these questions, because it was never designed to. SAML was.

Signing in is only the visible tip of what a SAML integration delivers. The real value lies underneath:

Provisioning users from corporate systems. Large organisations must have a centralised way of creating users at the organisation level — and that access must propagate to every system the corporation uses. Leon is no exception: with SAML, Leon supports Just-In-Time (JIT) provisioning — a user account in Leon is created automatically the first time an authorised employee signs in through the corporate Identity Provider. Accounts originate in the company's identity system and flow into Leon, instead of being created manually, one application at a time.

Access management stays in the company's hands. Access to Leon is granted and — critically — revoked centrally. When an employee leaves the organisation, IT disables one account in the IdP, and access to Leon disappears along with access to every other corporate application. There is no risk of an orphaned account with a still-valid password.

Better fit with Mobile Device Management (MDM). Corporate IdPs work hand-in-hand with MDM platforms. Access to Leon can be conditioned on the device itself: only managed, compliant, encrypted company devices get through. For crews working on company iPads and phones, this is not a nice-to-have — it is how corporate IT expects every application to behave.

Consistent security policy. MFA rules, session lifetimes, geographic restrictions, conditional access — all enforced by the IdP, uniformly, for Leon and every other system the company uses. Leon does not become a policy exception; it becomes a policy citizen.

Universally supported — including systems you cannot buy

A key strength of SAML is its ubiquity. It is supported by practically every Identity Provider in existence: Microsoft Entra ID, Google Workspace, Okta, Ping Identity, OneLogin, CyberArk, JumpCloud, Auth0 — and equally by on-premise and internal corporate platforms built on ADFS, Keycloak, Shibboleth, or fully bespoke identity systems.

That last category deserves emphasis. Large corporations frequently run internal identity platforms that are not publicly available products. They were built or deeply customised in-house, they encode years of the company's security and compliance decisions, and they will not be replaced to accommodate a vendor's login preferences. A vendor that supports only "Sign in with Google/Microsoft" simply cannot connect to them. A vendor that speaks SAML can — because SAML is the common language these systems were designed to speak.

Why this matters most in corporate aviation

This is where the argument becomes decisive for Leon's market. Corporate flight departments belong to organisations that are almost always far larger than even the biggest charter or commercial operators. A flight department of a Fortune 500 or multinational company may have twenty people — pilots, cabin crew, schedulers, a director of aviation — but it sits inside a corporation of twenty, fifty, or a hundred thousand employees.

This is not theory. It reflects our direct experience onboarding corporate flight departments of large, multinational organisations onto Leon. In practically every such project, the flight department is not the only stakeholder: the company's IT security and identity teams are at the table from day one. Before Leon is approved for use, it goes through a formal vendor security assessment — security questionnaires, a review of authentication architecture, questions about deprovisioning and audit logging. In those reviews, one requirement comes up with remarkable consistency: integration with the corporate Identity Provider via SAML. We have simply never seen a large corporate customer for whom "your pilots can log in with their private Google accounts" was an acceptable answer.

At that scale, the rules are different:

Application access is governed by formal identity and access management (IAM) processes, not by individual sign-ups.
Every system must fit into an existing ecosystem of corporate tools — directory, MDM, SIEM, audit trails.
Compliance frameworks (SOC 2, ISO 27001, internal security standards) explicitly require centralised identity management and immediate deprovisioning.
The flight department's software — scheduling, crew planning, trip management — is treated exactly like any other enterprise application, regardless of whether the operation runs under EASA, Part 91, Part-NCC, or an AOC.

For such organisations, a standard "log in with Google or Microsoft" flow does not meet their compliance requirements — full stop. It is not a matter of preference or convenience. Corporate IT security will not approve an application that lives outside the company's identity governance. SAML-based SSO is very often the precondition for a system like Leon being allowed into the corporate ecosystem at all.

Conclusion

SAML is Leon's preferred SSO mechanism because it matches what Leon actually is: a business system that must integrate into its customers' organisations, not just authenticate their individual users. It delivers login, yes — but more importantly it delivers user provisioning from corporate systems, centralised access management, MDM alignment, and compatibility with virtually every Identity Provider on the market, including the internal, non-commercial platforms found in large corporations.

For corporate and business aviation in particular — where flight departments operate inside organisations of enormous scale and strict compliance regimes — this is not an optional extra. It is the way enterprise software is expected to work, and it is what corporate IT security teams verify before a flight operations platform is approved at all. That is what our experience with large corporate customers has taught us — and it is why, at Leon, SAML is not just one of the options. It is the one we recommend.