Protocols and standards

Updated April 30, 2021

Integrate the SecureAuth® Identity Platform hybrid model with service providers (SPs) for cloud, web, VPN, or mobile by using industry-standard protocols. Because the Identity Platform acts as a Security Token Service (STS), it can quickly convert one type of access token (e.g., SAML token) to another (e.g., WS-Federation) for frictionless user access.

The Identity Platform fits into the equation in many ways depending on the protocol workflow; in any instance, the SecureAuth Connector can perform the following flexible authentication to validate a user's identity before generating the access token that allows the user into the resource.

  • SecureAuth's flexible Two-Factor Authentication (2FA) includes 25+ second factor methods and takes something a user knows (username and password) and combines it with something the user has (phone, email, PIN, etc.) or is (fingerprint, face) to ensure security before granting access.

  • SecureAuth's Adaptive Authentication uses risk analysis, along with restrictions to IP addresses, country, group, user, and geo-velocity, to analyze login attempts, and enables immediate and customizable reactions to threats.

  • The Authentication API embeds the Identity Platform functionality into a custom application, which enables personalized workflows and user interfaces. The Identity Platform uses a RESTful API encrypted over Secure Sockets Layer (SSL) to validate users through 2FA and evaluate IP address risk.

SAML and WS-*

SAML and WS-* protocols are typically deployed for cloud and web integrations. WS-* works with Microsoft applications and thick clients. SAML works with a range, from a variety of cloud and web providers to VPNs and other devices.

  • Security Assertion Markup Language (SAML) is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider (IdP) and an SP.

  • WS-* is a prefix used to indicate specifications associated with Web Services, which include WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust standards. The Identity Platform supports both WS-Federation and WS-Trust for SP integrations.

60566493.png

The Identity Platform fits into the SAML integration environment as the trusted partner, to whom the SP can communicate in an understood language, SAML. The SP requests a signed SAML assertion before granting access to a user, and the Identity Platform creates the assertion and signs it with a certificate. A SAML assertion is an XML-based message that is formatted specifically for SAML, and includes user information, any required attributes, the federated ID expected by the SP, and the public key of the certificate used to sign the assertion.

WS-Federation integrations work similarly to SAML integrations, but the XML assertion is wrapped with additional WS-Federation requirements. The SAML and WS-Federation assertion type is considered passive (redirecting users back and forth through a browser), while the WS-Trust assertion type is considered active.

In WS-Trust integrations, the SP or thick client makes web service calls to the Identity Platform (which acts as the STS) that sends a Request Security Token (RST) continually until the Identity Platform responds with an RST Response (RSTR), which would be a SAML or other XML assertion. Upon receiving the RSTR, users are allowed access to the SP.

The Identity Platform can also consume SAML assertions, by acting as the SP that then asserts users securely to another resource. This workflow can be applied if using another IdP for user validation or for transforming SAML assertions into another type of access token. When using another IdP, the Identity Platform accepts the SAML assertion and any required profile data, reformats it for any purpose (e.g., another access token or SSO), and then asserts the user through to the target resource.

SecureAuth's Transformation Engine enables the Connector to modify profile or attribute data on the fly, after authentication and before assertion to the SP. This can include global alterations to all users and if/else statements that enable immediate modifications if a user's profile meets certain criteria.

OAuth 2.0 and OpenID Connect

OAuth 2.0 and OpenID Connect are typically deployed for cloud applications, creating a connection between a relying party (app) and protected resource (web API, resource server, etc.) in which data is passed through an authorization server (IdP) between the two.

60566494.png
  • OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and IoT devices.

  • OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol that allows clients to verify the identity of the user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the user in an interoperable and REST-like manner.

An OAuth 2.0 integration workflow starts with the resource owner (user) accessing an application that then needs data from another client. The relying party sends parameters to the authorization server, that then authenticates the user, in whatever way the realm is configured.

After authentication is completed, the authorization server can return either an authorization code (as shown in the previous image) or an access token, depending on the parameters sent. Sending an authorization code increases the security by allowing the application and the Identity Platform to communicate behind the scenes and away from the browser to further validate the session.

The app then returns the authorization code back to the authorization server to receive the access token. The access token is then sent to the protected resource to request the required data.

Upon receiving the access token, the protected resource returns the data to the app and the workflow is completed.

The parameters sent to the authorization server vary depending on the resources required; however, the required elements include the following:

  • Client ID - Similar to a username, used along with a Client Secret, shared between the two to create a trusted relationship

  • Response Type - Tells the Identity Platform whether to send an authorization code or access token

  • Scope - Permissions that the user must authorize for the app to retrieve data

  • Redirect URI - Required only for authorization code workflows, a white-listed page to where the client application can be redirected to capture the Identity Platform responses

  • State - A random value generated by the app, sent to the Identity Platform, and sent back to enhance the trusted relationship, is recommended

OpenID Connect integrations follow the same path, with the Response Type and Scope dictating the workflow, but include user profile information in the Identity Platform response. The Identity Platform returns the access token to the application, in addition to an ID Token that contains profile claims. Claims are user attributes, mapped to the Identity Platform Profile Properties, and configured in the Classic Experience Web Admin (e.g., First Name, Last Name, Email Address, etc.).

HTTP

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems, and is the foundation of data communication for the World Wide Web.

The Identity Platform uses HTTP and HTTPS in numerous processes of the Connector, including for message level encryption of communication to the Cloud Services, transferal of user data between IdP and SP, form-post integrations, and cookie or token delivery and acceptance.

All communication between the Connector and the Cloud Services, or between the Connector and the user are completed over HTTPS. The Identity Platform client-side pages are all browser-based for familiar user interaction and for secure transactions. Form-post integrations include the Identity Platform posting user credentials to an application, as well as applications posting credentials to the Identity Platform.

The Identity Platform employs cookies or tokens for various product functionality, including assertion, SSO, and consumption. All user profile information that is required in a post-authentication assertion is sent over in an HTTP cookie. These cookies can contain various items, all depending on what is configured in the Classic Experience realm. For SSO, the Classic Experience realms are connected together by employing the same tokens and keys to create a relationship of credentials. Once the Identity Platform validates the user in one realm, the tokens are then recognized as acceptable and enable the user to access the remaining realms in the SSO group.

The Identity Platform uses Begin Sites, which allow users to bring something with them to the Identity Platform, such as user credentials. At a begin site (depending on the type), the Identity Platform can consume a token and then use the information within it to progress the user further into the workflow.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication and authorization management for users that connect and use a network service. The Identity Platform can be used as a RADIUS Server, authenticating users attempting to access a RADIUS Client to gain entry into a protected resource.

A RADIUS Client can be a Network Access Server (NAS), a VPN server, or something similar that acts as a gateway to protected resources, and uses the RADIUS protocol to validate user identities before enabling access.

In a RADIUS integration, the workflow initiates with the user logging into the RADIUS Client, with username, password, and certificate or token (depending on the client requirements). The client then sends an Access-Request Message to the RADIUS Server (the Identity Platform). When the Identity Platform acts as a RADIUS Server, it can authenticate users through the Password Authentication Protocol (PAP). The SecureAuth RADIUS Server also supports the Protected Extensible Authentication Protocol (PEAP) and MS-CHAPv2 protocols.

60566495.png

The Identity Platform responds to the client with an Access-Challenge, which is then forwarded to the user, with the following two-factor authentication options available for selection:

  • Time-based Passcode (TOTP/HOTP) - A time-based one-time passcode (OTP) that is generated on a mobile, desktop, or browser application

  • SMS OTP - An OTP delivered by Short Message Service (SMS) text message

  • Phone OTP - An OTP delivered by phone call

  • Email OTP - An OTP delivered by email message

  • Login Notification - An OTP delivered (pushed) to a pre-enrolled mobile device

  • Push-to-Accept - A login request delivered to a pre-enrolled mobile device with Accept or Deny push options

  • Symbol-to-Accept - A login request delivered to a pre-enrolled mobile device to tap a symbol that matches the one on the VPN screen

  • Link-to-Accept - A login request delivered (pushed) to a pre-enrolled mobile device to tap a link in an email or SMS/text

  • PIN - A login request delivered to a VPN response screen to enter a pre-enrolled personal identification number (PIN)

  • Yubico OTP Token - An OTP delivered automatically from the Yubico security token to the login app

  • Help Desk OTP - An OTP delivered by Help Desk after end user calls to request the code

  • Fingerprint - A login request delivered to a pre-enrolled mobile device to provide a pre-enrolled fingerprint on the SecureAuth Authenticate app

  • Face Recognition - A login request delivered to a pre-enrolled mobile device to show a pre-enrolled face on the SecureAuth Authenticate app

After the user has provided the challenge data to the client, it is sent to the Identity Platform, with another Access-Request Message. the Identity Platform can then respond with one of three options:

  • Access-Reject - The user is denied access to the RADIUS Client

  • Access Challenge - The user must provide additional challenge data before being granted access (e.g., another two-factor authentication method)

  • Access-Accept - The user is granted access to the RADIUS Client

If the Identity Platform returns an Access-Accept response, then the client grants the user access to the protected resources.

Certificate delivery

Certificate-based authentication and assertion enables SPs to grant users access only after they present a valid, trusted certificate. the Identity Platform, as a trusted issuer, enables users to securely enroll for certificates that are employed to log into the protected resource.

Because of the Identity Platform's functionality, no Certificate Authorities (CAs) are required; however, CAs can be integrated with the Identity Platform via SCEP if preferred. Without that extra baggage, certificate-based integrations flow smoother and require less maintenance.

For resources that require user certificates for access, the integration requires an Identity Platform Classic Experience certificate enrollment realm and an established, trusted relationship between the SP and the Identity Platform (through configuration).

60566496.png

The Identity Platform supports a SHA256 (SHA2) certificate infrastructure for SecureAuth Cloud communications (two-factor authentication methods), browser-web server communication, profile data encryption, and SP integrations. Certificate delivery integrations are typically used for VPNs and other devices; however, because of SecureAuth's flexibility, it can be employed for any type of SP that requires it.

Integration and configuration guides

The SecureAuth Identity Platform v19.07+ hybrid model can be integrated with cloud and web applications, as well as VPNs and devices. To learn more, see SecureAuth Integration & Configuration Guides.