Protocols and standards

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.

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 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.

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:

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 (like First Name, Last Name, Email Address, and so on) and configured in the Advanced Settings (formerly Classic Experience Web Admin).

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 SecureAuth IdP and service provicer (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 Advanced Settings realm. For SSO, the Advanced Settings 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.

The SecureAuth Identity Platform can work with IPv6, but it has some limitations on what it can do. The Identity Platform runs on a Windows Server using IIS, and it relies on the Windows operating system to support IPv6. But, there are certain things, like finding the geo-location of an IP address and threat scoring, that won't work when using IPv6. If you need help setting up IPv6 on Windows Server and IIS, you can check out the instructions provided by Microsoft.

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.

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:

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:

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

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 Advanced Settings (formerly Classic Experience) certificate enrollment realm and an established, trusted relationship between the SP and the Identity Platform (through configuration).

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.

The SecureAuth Identity Platform release 19.07 or later hybrid model can be integrated with cloud and web applications, as well as VPNs and devices. To learn more, see Integrations for your Identity Platform release.