SAML

What is SAML?

SAML (Security Assertion Markup Language) is an open standard that lets different systems securely share authentication and authorization information. In practical terms, it allows an identity provider (the system that confirms who you are) to hand off your login credentials to a service provider (the app you're trying to use). This XML-based protocol has become fundamental to enterprise security, especially when implementing single sign-on across a bunch of different applications.

The process involves three key players: the principal (usually you, the user), the identity provider (IdP), and the service provider (SP). Here's what happens when you try to access an app: the service provider bounces you over to the identity provider to log in. Once you've authenticated successfully, the identity provider generates a SAML assertion, which is basically a digitally signed token that says who you are and what you're allowed to do. That token goes back to the service provider, and you're in.

SAML has been around since 2005 when OASIS (Organization for the Advancement of Structured Information Standards) released version 2.0. It's still going strong in enterprise settings where organizations juggle user access across dozens of internal and external applications while keeping security tight.

Key Characteristics of SAML

• XML-Based Protocol: SAML structures its authentication messages in XML, giving you a standardized, readable format for passing identity data between systems.
• Identity Provider Trust: Organizations set up a trust relationship between their identity provider and various service providers. This allows credentials to be exchanged securely without ever sharing the actual passwords.
• Assertion-Based Security: Those SAML assertions contain digitally signed statements about who the user is, whether they're authenticated, and what they're authorized to do. The digital signatures keep the data intact during transmission.
• Built for Enterprise SSO: SAML was designed with enterprise web browser single sign-on in mind, so it works particularly well for traditional web applications.
• Federated Identity Support: One of SAML's strengths is enabling federated identity management. Organizations can extend authentication across different security domains and even partner companies.

SAML Examples

Example 1: Corporate Application Access

Picture a healthcare organization that needs employees to access their electronic health records system, HR portal, and training documentation platform. With SAML, staff authenticate once through the corporate identity provider, and that's it. SAML takes care of passing their credentials and role information to each application. The EHR system receives SAML assertions containing department and role attributes, so appropriate access levels are granted automatically.

Example 2: Cloud Service Integration

A manufacturing company has their on-premises Active Directory but also uses several cloud applications: CRM, supply chain management, and quality documentation systems. SAML bridges the gap, letting employees access all these cloud services with their existing corporate credentials. Meanwhile, IT keeps centralized control over access policies and can shut off access across every system instantly when someone leaves the company.

SAML vs OAuth

SAML and OAuth get mentioned together a lot, but they actually serve different purposes in identity and access management.

How Glitter AI Helps with SAML

Glitter AI supports SAML authentication so it can plug right into your existing enterprise identity management setup. Organizations can configure SAML-based single sign-on, which means team members access Glitter's documentation and training content using the same corporate credentials they already have. No separate login to remember, no extra password to manage. People can just start creating screen recordings, process documentation, and training materials.

For companies with strict security requirements, SAML integration means access to documentation repositories follows the same role-based access control policies you use everywhere else. IT administrators keep visibility and control over who can access, create, and share documentation. Compliance requirements get met, but the documentation workflow stays smooth.