Implementing SAML 2.0 Assertion Encryption for Enhanced SSO Security in Genesys Cloud

What This Guide Covers

You are hardening your Genesys Cloud SAML 2.0 SSO integration by enabling assertion-level encryption - ensuring that the SAML assertion payload is encrypted with the Service Provider’s (Genesys Cloud’s) public key before transmission, so that even if the assertion is intercepted in transit, the contents remain unreadable without Genesys Cloud’s private key. When complete, your IdP encrypts every assertion it sends, and Genesys Cloud decrypts and validates it transparently - providing an additional layer of protection beyond transport-layer TLS.

---

Prerequisites, Roles & Licensing

• Licensing: Any Genesys Cloud CX tier (SSO is available on all tiers)
• Identity Provider: Any SAML 2.0-compliant IdP that supports assertion encryption: Okta, Azure AD (Entra ID), PingFederate, AD FS, OneLogin, or Shibboleth
• Permissions required:
  • Admin > Authentication > Single Sign-On > Edit in Genesys Cloud
  • Admin access to your IdP’s SAML application configuration
• Cryptographic prerequisites:
  • Genesys Cloud’s public encryption certificate (downloaded from your org’s SSO configuration)
  • Your IdP must support EncryptedAssertion element in SAML responses (all major IdPs do)
• Note: Assertion encryption is independent of and additive to assertion signing. Both should be configured - signing proves integrity and authenticity; encryption ensures confidentiality.

---

The Implementation Deep-Dive

1. Understanding SAML Assertion Encryption vs. Transport Encryption

A common architect’s blind spot: SAML assertions over HTTPS are already encrypted at the transport layer (TLS). Why add assertion-level encryption?

Transport encryption (TLS) protects data in motion between two hosts. Once the assertion arrives at the Service Provider’s HTTPS termination point (a CDN, load balancer, or reverse proxy), the transport encryption ends. If your HTTPS termination is in a WAF, CDN, or TLS-inspecting proxy, the assertion is visible in plaintext at that termination point before being forwarded to Genesys Cloud.

Assertion encryption (SAML EncryptedAssertion) protects the payload end-to-end - from IdP encryption to Genesys Cloud decryption. Intermediate hops (WAFs, CDNs, logging infrastructure) that intercept the SAML POST see only ciphertext. For environments with TLS inspection appliances or regulatory requirements for end-to-end encryption of identity tokens (common in healthcare and finance), assertion encryption addresses what TLS alone cannot.

The Trap - disabling signing when adding encryption: Some engineers, when adding assertion encryption, inadvertently remove assertion signing from the IdP configuration thinking encryption is sufficient. Encryption ensures confidentiality; signing ensures authenticity and integrity. An attacker cannot read an encrypted assertion, but without a signature, they could potentially replay a valid encrypted assertion from a previous session. Always configure both: sign the assertion first (the IdP’s private key), then encrypt it (with Genesys Cloud’s public key).

---

2. Downloading Genesys Cloud’s Encryption Certificate

Genesys Cloud’s SP metadata includes the public encryption certificate used to encrypt assertions destined for your org. This certificate is unique per Genesys Cloud organization.

Navigate to Admin > People & Permissions > Single Sign-On.

In the SSO configuration section, locate your existing SAML integration. Click Download SP Metadata. The SP metadata XML includes two KeyDescriptor elements:

<!-- Signing certificate: IdP uses this to verify Genesys Cloud's AuthnRequests -->
<md:KeyDescriptor use="signing">
  <ds:KeyInfo>
    <ds:X509Data>
      <ds:X509Certificate>MIIDa...your_signing_cert...</ds:X509Certificate>
    </ds:X509Data>
  </ds:KeyInfo>
</md:KeyDescriptor>

<!-- Encryption certificate: IdP uses this to encrypt assertions -->
<md:KeyDescriptor use="encryption">
  <ds:KeyInfo>
    <ds:X509Data>
      <ds:X509Certificate>MIIDa...your_encryption_cert...</ds:X509Certificate>
    </ds:X509Data>
  </ds:KeyInfo>
</md:KeyDescriptor>

Extract the use="encryption" certificate. This is what you upload to your IdP.

If Genesys Cloud’s SP metadata does not include a separate encryption KeyDescriptor, it may be using the same certificate for both signing and encryption. Some IdPs require a dedicated encryption certificate uploaded separately from the signing certificate - in this case, contact Genesys Cloud support to confirm whether a dedicated encryption certificate is available for your org.

---

3. Configuring Assertion Encryption in Okta

Step 1: Upload Genesys Cloud’s Encryption Certificate to Okta

In your Okta SAML application:

1. Navigate to Applications > [Genesys Cloud App] > General > SAML Settings > Edit
2. In the Encryption section, click Upload Certificate
3. Upload the encryption .cer or .pem file extracted from Genesys Cloud’s SP metadata
4. Set Assertion Encryption to Enabled

Step 2: Select encryption algorithm

Okta supports:

• AES-128-CBC (acceptable)
• AES-256-CBC (recommended for new deployments)
• 3DES-CBC (legacy - avoid)

Select AES-256-CBC. The key transport algorithm should be RSA-OAEP (preferred over RSA-v1.5 which is vulnerable to padding oracle attacks).

Step 3: Verify the Okta SAML response

After enabling encryption, Okta’s SAML response will contain <saml:EncryptedAssertion> instead of <saml:Assertion>:

<samlp:Response ...>
  <saml:EncryptedAssertion>
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" ...>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
      <ds:KeyInfo>
        <xenc:EncryptedKey>
          <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
          <!-- Encrypted symmetric key, encrypted with Genesys Cloud's RSA public key -->
          <xenc:CipherData><xenc:CipherValue>...</xenc:CipherValue></xenc:CipherData>
        </xenc:EncryptedKey>
      </ds:KeyInfo>
      <!-- Encrypted assertion body -->
      <xenc:CipherData><xenc:CipherValue>...</xenc:CipherValue></xenc:CipherData>
    </xenc:EncryptedData>
  </saml:EncryptedAssertion>
</samlp:Response>

---

4. Configuring Assertion Encryption in Azure AD (Entra ID)

Azure AD supports assertion encryption via the Token Encryption feature in Enterprise Applications.

Step 1: Upload the encryption certificate

# Install Microsoft Graph PowerShell module if not present
Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Get the Enterprise Application ID for Genesys Cloud
$app = Get-MgApplication -Filter "displayName eq 'Genesys Cloud'"

# Upload the encryption certificate
$certPath = ".\genesys_cloud_encryption.cer"
$certBase64 = [Convert]::ToBase64String([System.IO.File]::ReadAllBytes($certPath))

$certConfig = @{
    keyCredentials = @(
        @{
            type = "AsymmetricX509Cert"
            usage = "Encrypt"
            key = [System.Convert]::FromBase64String($certBase64)
        }
    )
}

Update-MgApplication -ApplicationId $app.Id -BodyParameter $certConfig

Step 2: Enable token encryption in the Azure portal

Navigate to Azure Active Directory > Enterprise Applications > [Genesys Cloud] > Single Sign-On > Token Encryption. Toggle Token Encryption to On and confirm the uploaded certificate appears.

The Trap - Azure AD’s token encryption requiring SAML not OAuth: Azure AD’s Token Encryption feature applies only to SAML token-based SSO, not to OAuth/OIDC flows. If your Genesys Cloud SSO is configured as an OIDC app (using the OAuth2 flow instead of SAML), assertion encryption does not apply - OIDC uses JWT tokens with a different encryption mechanism (JWE). Confirm your Genesys Cloud SSO protocol under Admin > SSO > Protocol before proceeding.

---

5. Configuring Assertion Encryption in AD FS

For on-premises AD FS deployments:

# In AD FS management - import Genesys Cloud's encryption certificate
$certBytes = [System.IO.File]::ReadAllBytes("C:\certs\genesys_cloud_encryption.cer")
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certBytes)

# Update the Relying Party Trust to encrypt assertions
Set-AdfsRelyingPartyTrust -TargetName "Genesys Cloud" `
  -EncryptionCertificate $cert `
  -EncryptClaims $true `
  -SamlResponseSignature AssertionOnly

-SamlResponseSignature AssertionOnly configures AD FS to sign the inner assertion (not just the response envelope), which is required for Genesys Cloud to validate the signature after decrypting.

For PingFederate, configure assertion encryption under SP Connection > Credentials > Back-Channel Authentication > Assertion Encryption - upload Genesys Cloud’s certificate and select AES-256-CBC / RSA-OAEP.

---

6. Testing and Validation

Step 1: Capture a SAML assertion for inspection

Use the SAML Tracer browser extension (Chrome/Firefox) to capture the SAML POST request during a login attempt. In the SAML response, verify:

• The response contains <saml:EncryptedAssertion> (not <saml:Assertion> in plaintext)
• The EncryptionMethod algorithm matches what you configured (aes256-cbc)
• The KeyEncryptionMethod is rsa-oaep-mgf1p

Step 2: Confirm successful login

A successful encrypted assertion login should be indistinguishable to the end user from an unencrypted login. If users receive “authentication failed” or “SAML response could not be processed” errors after enabling encryption, the most common causes are:

---

Validation, Edge Cases & Troubleshooting

Edge Case 1: Certificate Expiration Breaking SSO

The encryption certificate uploaded to your IdP has an expiration date. When it expires, the IdP can no longer encrypt assertions (it will either error or fall back to unencrypted assertions, depending on IdP configuration). Build a rotation process:

1. 90 days before expiry, generate a new encryption key pair or obtain the updated certificate from Genesys Cloud’s SP metadata
2. Upload the new certificate to the IdP alongside the existing one (dual-certificate mode, if supported)
3. After all active sessions rotate to the new certificate, remove the old certificate
4. Monitor SSO login success rates during the transition window

Edge Case 2: IdP-Initiated SSO vs. SP-Initiated SSO Behavior

Assertion encryption applies identically to both IdP-initiated (user clicks the Genesys Cloud app tile in Okta/Azure) and SP-initiated (user navigates to Genesys Cloud, is redirected to IdP for authentication) SSO flows. No special configuration is needed to differentiate the two - the encryption is applied at the assertion generation step, regardless of how the flow was initiated.

Edge Case 3: Mobile SDK and API Clients

Genesys Cloud mobile apps and API integrations that use OAuth2 (not SAML) for authentication are not affected by assertion encryption configuration. Only browser-based SSO flows that use the SAML protocol are impacted. API service accounts using OAuth Client Credentials are entirely separate and do not traverse the SSO path.

Edge Case 4: Multi-IdP Configurations

If your Genesys Cloud org is configured with multiple identity providers (one for employees, one for contractors), each IdP connection has its own assertion encryption configuration. You must upload Genesys Cloud’s encryption certificate to each IdP separately and enable encryption per connection. Verify all IdP connections after any encryption certificate rotation.

---

Official References

• Genesys Cloud Single Sign-On (SSO) Configuration - Resource Center
• Okta SAML Assertion Encryption Configuration Guide
• Azure AD Token Encryption for SAML Applications
• OASIS SAML 2.0 XML Encryption Schema (SAML Core Specification)