Integrations

Single sign-on (SSO)

What’s single sign-on (SSO)?

Single sign-on (SSO) allows your users to enjoy a seamless experience when logging into the learning platform or visiting an O’Reilly content page. They’ll automatically log into their O’Reilly account using your company’s identity provider—no need for a username or password.

Benefits of using SSO include:

  • Improved online experience for your account members
  • Increased productivity
  • Reduced risk by minimizing bad password habits
  • Reduced help desk costs
  • Accelerated adoption of company-promoted apps

The O’Reilly SSO experience

When implementing SSO with O’Reilly, you’ll work with our integration team to create a simple and intuitive login experience for your users. You can customize login options based on your organization’s unique needs, so whether you have multiple accounts with us or use more than one identity provider (IdP), we’ll create a single unified login experience. Once your account has SSO configured and home realm discovery enabled, your users can also log in with SSO on the mobile app. If your IdP is behind a firewall, users will need to connect with mobile device pairing for mobile app logins.

To log in, users will simply enter their organization email address, select their group from the dropdown list (if applicable), and click Sign In with SSO. They won’t need to log back in to the platform unless they sign out or too much time has passed since their last login—a time frame you can choose (30 days by default).

User management with SSO

When integrated with SSO, you can use just-in-time user provisioning to manage your users’ accounts. This means the first time a user logs in, an account will automatically be created for them in O’Reilly. And you can set up no-touch reactivation so your deactivated users are automatically reactivated when they attempt to log in and open seats are available. These features help reduce the amount of time you’ll spend manually managing user accounts from your Admin Console.

You can also use settings within your identity provider to determine who can log in to O’Reilly. If that isn’t possible, we can evaluate the attributes sent for a user to determine whether or not they’re permitted to log in. Check with your local IT department to discover how authorization to applications is managed at your organization.

SAML 2.0

O’Reilly provides SSO through the well-established open source Security Assertion Markup Language (SAML), which is supported by most identity providers to authenticate users within corporations today. O’Reilly supports SAML 2.0, the most up-to-date version of the protocol. Our SAML service provider is Auth0. Below you’ll find the details you’ll need to configure your SAML identity provider for O’Reilly.

Supported SAML SSO flows

O’Reilly supports identity provider- and service provider-initiated SSO.

Service provider-initiated SSO flow:

  • A visitor requests an SSO-protected target resource from O’Reilly.
  • O’Reilly sends a SAML request to the partner identity provider.
  • The identity provider authenticates the visitor using its local authentication mechanism.
  • The identity provider sends O’Reilly a SAML response containing the visitor’s required information.
  • O’Reilly validates and confirms the SAML response, then grants access to the requested resource.

Identity provider–initiated SSO:

  • A visitor requests an SSO-protected resource via the identity provider.
  • The identity provider authenticates the visitor using its local authentication mechanism.
  • The identity provider sends O’Reilly a SAML response containing the visitor’s required information.
  • O’Reilly validates and confirms the SAML response, then grants access to the requested resource.

Recognized email domains (home realm discovery):

Users who visit the login page (https://learning.oreilly.com/accounts/login/) can trigger a service provider-initiated SAML login by entering an email address whose domain is registered to your corporate subscription.

SAML attributes

As a service provider (SP), we rely on assertions from our identity providers to perform account creation and user authorization. To provide the best user experience, we require the data below to be released as attributes in your SAML response.

O’Reilly attribute names Example source attributes Description of data
user_id urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

urn:oasis:names:tc:SAML:attribute:pairwise-id

user.ObjectID

eduPersonTargetedID		 Primary user identifier—must be unique, should never change.

Opaque privacy-preserving identifiers are strongly preferred, but we can use any attribute that is unique for each individual in your user base, even an email address, if necessary.
email urn:oid:0.9.2342.19200300.100.1.3

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress		 Deliverable email address
given_name urn:oid:2.5.4.42

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname		 First name(s)/given name(s)
family_name urn:oid:2.5.4.4

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname		 Last name(s)/surname(s)/family name(s)

How to provide O’Reilly with your own attributes

O’Reilly can capture optional attributes, a feature you can use to pass along any attributes that you use on your own site for role-based authorization, reporting usage, and other tasks. For example, if your identity provider system sends a ”department” attribute in its SAML response, we’re able to capture and store that data for you. We can also map our attributes to attributes with other names that you may use for similar purposes.

If you need to prevent access to O’Reilly for a subset of users, we can evaluate their attributes to determine whether or not to allow them to log in to the platform. This should be discussed in detail to ensure we’re implementing your business rules as intended.

User anonymity

Upon request, we offer the ability to create anonymous user accounts. This can be done by using the customer-provided unique and unchanging identifier we require for each licensed user (see “SAML attributes” above). This allows the use of the O’Reilly learning platform without sharing any personal information.

Identity provider configuration

Once the service provider has been configured by O’Reilly, we’ll provide you with the following information via email:

  • A unique connection string
  • The entity ID of the service provider
  • The SP metadata download link
  • The assertion consumer service URL (a.k.a. postback URL or SSO URL)
  • The SP signing certificate
  • A dedicated sign-in URL for your users
  • Instructions for completing setup and testing

We have detailed steps on the setup needed within commonly used identity providers:

Our SAML requests are signed using a SHA256 hash algorithm. If needed, we can downgrade to signing requests using SHA1 or to unsigned requests. However, doing so is strongly discouraged. We require signed SAML responses and support attribute-level encryption.

Academic customers

For our academic library customers, our configuration is anonymous, based on a unique, persistent user identifier, such as eduPersonTargetedID or pairwise-id. We don’t accept user identifiers that are PII-based and contain any portion of a library user’s first name, last name, or email address. If this isn’t possible for your identity provider, it can be discussed when you work with our integration team.

We have two general methods for SAML integrations for our academic customers:

  1. Multilateral SAML: We’re a member of InCommon and export our SP metadata through eduGAIN to numerous associated federations. This allows for easy SSO setup and management for the SSO integration. The entityID of our multilateral service provider is https://api.oreilly.com/samlsp.
  2. Bilateral SAML: Metadata is externally exchanged and manually managed. This does require some manual work by the IT staff on both sides of the integration.

Have a problem or question? Reach out.

For issues and support regarding your O’Reilly account, please contact your account admin directly or email the customer support team at