Skip to main content
ON24 Knowledge Center

ON24 Federation Technical Handbook

The information provided in this document allows partners to set up their federation servers to initiate federated identity management with ON24.

Federation Summary

Federated identity management (or “identity federation”) enables enterprises to securely exchange identity information across Internet domains. Federation also enables secure SSO between distinct business units within a single organization. As organizations grow through acquisitions, or when business units maintain their own user repositories and authentication mechanisms, a federated solution to secure SSO is desirable.

SAML (Secure Assertion Markup Language) is an open standard for Web SSO, single logout (SLO), and the cross-domain transfer of user attributes. It specifies a set of XML formats and transport mechanisms designed to enable secure, decentralized identity management over the Internet.

In many cases, SAML is the foundation of current identity federation activity.  SAML defines a security token format (called an “assertion”) and profiles that define methods for using these assertions to provide Web SSO. In addition, SAML defines a SOAP protocol through which assertions may be served.  SAML has gone through three releases (none of which is compatible with the others): 1.0, 1.1, and 2.0.  SAML 2.0 is seen as a point of convergence between Liberty and SAML because it incorporates all of Liberty’s early ID-FF 1.1 and 1.2 functionality. 

SAML 2.0 is the protocol of choice for most new federations, due to the convergence of the use cases from the previous protocols.

Federation Terminology

Single Sign-On (SSO)
Single Sign-On (SSO) is a method of leveraging security tokens to indicate authentication between multiple domains, rather than requiring each member of a security domain to re-verify authentication credentials. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

Identity Provider (IdP)
An entity that makes various claims about an entity (ex. End User) to SPs. SPs take these claims and make a decision about whether to act on them as true. With SSO, these claims are meant to provide the service with enough information to consider a user authenticated.  With respect to federating with ON24, the IdP (client) would be the identity provider.

Service Provider (SP)
An SP is a consumer of claims from an Identity Provider. Based on the evaluation of the claims as well as any pre-existing relationship between the service and the Identity Provider, the information conveyed can be used for authentication, authorization, and to provide the claims as additional data into other business processes. Within the definitions of SAML, an SP is merely an entity providing a service to others, while an Identity Provider is the “SAML authority,” is a system entity that authenticates a user, or “SAML subject,” and transmits referential identity information based on that authentication. With respect to federating with ON24, ON24 would be the service provider.

Assertion/Token
Assertions are XML documents sent from an IdP to an SP. Each assertion contains identifying information about a user who has initiated a SSO request. Three types of statements can be conveyed in SAML assertions:

  • A piece of data produced by a SAML authority regarding an act of authentication performed on a subject
  • Attribute information about the subject
  • Authorization data applying to the subject with respect to a specified resource

Attribute/Claim
Attributes are distinct characteristics of an object (in SAML, of a subject). An object’s attributes are said to describe it. Attributes are often specified in terms of physical traits, such as size, shape, weight, and color, etc., for real-world objects. Objects in cyberspace might have attributes describing size, type of encoding, network address, etc.

Attributes are often represented as pairs of "attribute name" and "attribute value(s). Often, these are referred to as "attribute value pairs". Note that identifiers are essentially "distinguished attributes". Claims are statements about various attributes/characteristics of an entity.

Bindings
A SAML binding describes the way messages are exchanged using transport protocols. 
Some common SAML 2.0 bindings are:

  • HTTP POST – Describes how SAML messages are transported in HTML form-control content, which uses a base-64 format.
  • HTTP Artifact – Describes how to use an artifact to represent a SAML message. The artifact can be transported via an HTML form control or a query string in the URL.
  • HTTP Redirect – Describes how SAML messages are transported using HTTP 302 status-code response messages.
  • SOAP – Describes how SAML messages are to be transferred across the back channel.

Most common SAML bindings are:

  • HTTP POST – Describes how SAML messages are transported in HTML form-control content, which uses a base-64 format.
  • HTTP Artifact – Describes how to use an artifact to represent a SAML message. The artifact can be transported via an HTML form control or a query string in the URL.

Profiles
Profiles describe processes and message flows combining assertions, request/response message specifications, and bindings to achieve a specific desired functionality or use case.  SAML 2.0 is the most commonly used profile currently in the industry.

Metadata
SAML 2.0 defines an XML schema to standardize metadata to facilitate the exchange of configuration information among federation partners. This information includes, for example, profile and binding support, connection endpoints, and certificate information. Exchanging metadata files as “Best Practices” is common in the industry.

SSO Methods

IdP-Initiated SSO: POST (SAML 2.0)
In this scenario, a user is logged on to the IdP and attempts to access a resource on a remote SP server. The SAML assertion is transported to the SP via HTTP POST. 

  1. NOTE: If a user attempts to access ON24’s Protected Resources without being first authenticated at the IdP site, ON24 will simply redirect the user (http code 302 - NOT truly SP-Initiated SSO) to the IdP’s external SSO page for authentication purposes.
     

clipboard_e21359ab0eb96318cb85f09e43b4e4457.png

Processing Steps: 

  1. A user has logged on to the IdP. 
  2. The user requests access to a protected SP resource. The user is not logged on to the SP site.
  3. Optionally, the IdP retrieves attributes from the user data store. 
  4. The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.  Note: SAML specifications require that POST responses be digitally signed.

(Not shown) If the signature and assertion are valid, the SP establishes a session for the user and redirects the browser to the target resource.

SP-Initiated SSO: POST/POST (SAML 2.0)
In this scenario a user attempts to access a protected resource directly on an SP Web site without being logged on. The user does not have an account on the SP site, but does have a federated account managed by a third-party IdP. The SP sends an authentication request to the IdP. Both the request and the returned SAML assertion are sent through the user’s browser via HTTP POST. 
 

clipboard_e2209209ee3c204fd361538bc6db8fddb.png

Processing Steps: 

  1. The user requests access to a protected SP resource. The request is redirected to the federation server to handle authentication. 
  2. The federation server sends an HTML form back to the browser with a SAML request for authentication from the IdP. The HTML form is automatically posted to the IdP’s SSO service. 
  3. If the user is not already logged on to the IdP site or if re-authentication is required, the IdP asks for credentials (e.g., ID and password) and the user logs on. 
  4. Additional information about the user may be retrieved from the user data store for inclusion in the SAML response. 
  5. The IdP’s SSO service returns an HTML form to the browser with a SAML response containing the authentication assertion and any additional attributes. The browser automatically posts the HTML form back to the SP.

Federation Criteria with ON24

Request Signing
IdP (client) and ON24 (SP) must agree if requests are to be signed.  The standard specification requires signing for compliance.

Response Signing
IdP (client) and ON24 (SP) must agree if responses are to be signed.  The standard specification requires signing for compliance.

Response Encryption
IdP (client) and ON24 (SP) must agree if the data in the SAML responses are to be encrypted.  This can include the entire assertion and/or data in the assertion.

Digital Signature Exchange 

Digital Signature – used in electronic documents (requests, responses, and assertions) to verify that a person or entity is who they say they are. 

IdP (client) to ON24 (SP) Exchange
Based on the mutually agreed upon digital signature requirements, IdP (client) should provide the following:

  • The SAML response signing certificate which has the public key.
  • All applicable cert chain(s) of signing certificate (for self-signed certificates only).

ON24 (SP) to IdP (client) Exchange
Based on the mutually agreed upon digital signature requirements, IdP (client) should provide the following:

  • The SAML response signing certificate which has the public key.
  • All applicable cert chain(s) of signing certificate (for self-signed certificates only).

Digital Signature Policy Coordination
IdP (client) and ON24 (SP) must exchange certificates (containing the public keys) out-of-band. Both IdP (client) and ON24 (SP) must import these certificates into their respective federation systems for validation upon receipt of a signed message. 

Identity Mapping
Identity Mapping is the process in which users authenticated by IdP (client) are associated with user accounts local to the ON24 (SP).
 

The client must provide the attribute name(s) that will be included in the assertion. The ON24 team will need the attribute names to setup the mapping.

ON24 Support for Deep-link Dynamic using RelayState/TARGET Parameter

ON24 provides SAML SSO integration access to Elite and/or WCC Enterprise administrators for contracted clients. SAML access can either be enabled at the master account or a subset of sub-accounts.

Each enabled account provides a distinct URL (https://wcc.on24.com/webcast/sso/######) wherein ###### represents the ON24 client ID.

When a user accesses the above URL, the SP (ON24) or idP (client) configured connection URL is parsed for the RelayState/TARGET parameter, supplies the accessed URL as value and forwards the request.  Typically, the way this workflow is achieved by IdP supporting a parameter to their external SSO login page. The value of this parameter is set as RelayState when sending the assertion to the ON24 (SP).
 
On a successful IdP SAML assertion, ON24 SSO systems look at the RelayState parameter to determines the URL attempting to access. 

ON24 Federation Standards and Defaults

Item Name Standard
1 SSO Method IdP-Initiated
2 Profile SAML v2.0
3 Bindings HTTP-POST
4 Assertion Digital Signing Required
5 XML Encryption Required

Data Flow – idP Initiated

clipboard_eb84e6af2608b60fc6aee150ce396bb4d.png

Data Flow Steps Summary

  1. User A clicks on Platform URL.
  2. User A lands at ON24’s site (Protected Page).
  3. ON24’s application redirects user A (http code 302 – NOT SP-Initiated SSO), back to IdP’s external SSO login page.
  4. User A gets authenticated at IdP site. 
  5. IdP’s SSO system constructs SAML assertion and sends user A to ON24’s ACS (Assertion Consumer Service), along with RelayState parameter appended to the assertion.
  6. ON24’s Federation system decrypts and validates assertion.
  7. ON24’s Federation system sends user A to ON24 Platform URL based on RelayState.
  8. User A gets logged into ON24’s Platform.

Technical Diagram

clipboard_e4d3ac3629be03eecfa2de92c8b4b6a56.png

Attribute Designations

The following data elements should be used when configuring an IdP (client) connection with ON24 (SP)

Definitions

Entity ID: An entity ID is a globally unique name given to a SAML entity, either an Identity Provider (IdP) or a Service Provider (SP).

Attribute Contract: A list of attributes, agreed to by the partners in an identity federation, representing information about a user (SAML Subject).  The attributes are sent from IdP (client) to ON24 (SP) during SSO. Please refer to the below section for a list of required and optional attributes.

Assertion Consumer Service (ACS): The location where the ON24 (SP) receives and consumes assertions. SAML 2.0 defines the Assertion Consumer URL for the POST method.  

Target URL (TargetResource or RelayState): The URL for the protected resource that the Identity Provider (client) is trying to access at ON24 (SP).

  • Was this article helpful?