Cryptlex Documentation
  • Welcome to Cryptlex!
  • Getting Started
    • Overview
    • Licensing Models
  • License Management
    • License Templates
    • Implementing License Models
    • Creating Licenses
    • License Subscriptions
    • Custom License Fields
    • Meter Attributes
    • Suspending Licenses
    • Revoking Licenses
    • Maintenance Policies
  • Feature Management
    • Overview
    • Features and Entitlement Sets
    • License Feature Entitlements
    • Accessing Feature Entitlements
    • Use Cases
  • User Management
    • Roles
    • Creating Users
    • Authenticating Users
    • Organizations
    • Resellers
    • Customer Portal
    • Reseller Portal
    • Google SSO
    • SAML SSO
  • Release Management
    • Overview
    • Creating Releases
    • Distributing Releases
  • Node Locked Licenses
    • Overview
    • Using LexActivator
      • Using LexActivator with C, C++ and Objective C
      • Using LexActivator with C#
      • Using LexActivator with VB.NET
      • Using LexActivator with Java
      • Using LexActivator with Delphi
      • Using LexActivator with Python
      • Using LexActivator with Go
      • Using LexActivator with Node.js
      • Using LexActivator with Ruby
      • Using LexActivator with Android
      • Using LexActivator with iOS
      • Using LexActivator with Flutter
    • Using Web API
    • Offline Activations
    • Proxies and Firewall
  • Floating Licenses
    • Overview
    • Hosted Floating License Server
    • On-Premise Floating Licenses
      • LexFloatServer
      • Using LexFloatClient
        • Using LexFloatClient with C, C++ & Objective C
        • Using LexFloatClient with C#
        • Using LexFloatClient with VB.NET
        • Using LexFloatClient with Java
        • Using LexFloatClient with Delphi
        • Using LexFloatClient with Python
        • Using LexFloatClient with Node.js
        • Using LexFloatClient with Go
        • Using LexFloatClient with Android
        • Using LexFloatClient with iOS
      • Offline Floating License
  • Named User Licenses
  • Timed Trials
    • Verified Trials
    • Unverified Trials
  • Licensing Docker Apps
  • Webhooks
  • Automated Emails
  • Web Integration
    • Personal Access Tokens
    • Using Web API
    • Using Zapier
    • Using FastSpring
    • Custom Development
  • Changelog
    • Web API
    • LexActivator
    • LexFloatClient
    • LexFloatServer
  • Legal
    • Terms of Service
    • Privacy Policy
    • Subprocessors
    • Data Processing Addendum
    • Service Level Agreement
    • Security, Privacy, and Compliance
    • Open Source Licenses
  • Cryptlex On-Premise
    • Overview
    • System Requirements
    • Server Layout
    • Installation Guide
      • Docker Compose
      • Kubernetes
    • Configuring Client Libraries
    • Monitoring and Error Reporting
Powered by GitBook
On this page
  • Configuring single sign-on with SAML
  • Auto-Provisioning users
  • Email
  • FirstName
  • LastName
  • Role
  1. User Management

SAML SSO

PreviousGoogle SSONextRelease Management

Last updated 10 months ago

Single sign-on (SSO) allows users of your Cryptlex account to log in using your existing SAML-enabled identity provider, such as Active Directory, OneLogin, Auth0, Okta, and many more. This reduces the number of passwords your users need to manage. It also makes provisioning new users a breeze.

Configuring single sign-on with SAML

To get started, go to Settings > Account page in the admin portal and click the Configure SAML SSO button. This will display the SAML SSO settings dialog where you can add details of your identity provider.

Cryptlex supports the SAML 2.0 standard, which provides a few ways to streamline configuration. Although each identity provider will have different interfaces and nuances, most provide configuration metadata as a URL. Since each identity provider is unique, we will only cover using Cryptlex with a generic SAML identity provider in this article.

The easiest way to configure SSO is to use a link to your identity provider's metadata file. Simply enter the URL in the SAML IdP Metadata URL input box and click Save. Cryptlex will download the configuration file, parse it, and configure everything.

Auto-Provisioning users

The SAML identity provider must be configured to provide four attributes: Email, FirstName, LastName, and Role. These attributes allow Cryptlex to properly identify the user and automatically provision users.

FirstName, LastName, and Role are only required if the auto-provisioning of users is enabled.

Email

Every user in your Cryptlex account is required to have a valid email address, even when using SSO. Since the identity provider is responsible for managing user information, it must send the user's email address to Cryptlex in its assertion. Identity providers use different naming conventions, so Cryptlex will look for an email address in the following attributes (case-insensitive) sequentially:

  • EmailAddress

  • Email

  • Mail

  • User.email

  • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

FirstName

Just like email addresses, identity providers may send the first name in several common fields. To provide out-of-the-box compatibility with most identity providers, Cryptlex will try to find the first name in the following attributes (case-insensitive):

  • FirstName

  • first_name

  • User.FirstName

LastName

Cryptlex looks for the last name in the following attributes (case-insensitive):

  • LastName

  • last_name

  • User.LastName

Role

If your identity provider supports custom attributes, you can set the Role attribute to automatically provision users with roles created in Cryptlex. Cryptlex looks for the role in the following attributes (case-insensitive):

  • Role

Role mapping

You can easily map the roles created in Cryptlex (service provider roles) with your existing roles in the identity provider. Then depending on the identity provider role in the SAML assertion, Cryptlex will use the corresponding service provider role when auto-provisioning the user.

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
http://schemas.microsoft.com/ws/2008/06/identity/claims/role