Use Case for Step-Up Authentication

Last updated
Save as PDF

This use case is supported when a user wants to create a new cloud access policy and add an action as Step-Up Authentication. For example, when the CAP policy is triggered on POST requests in Salesforce, the users are directed to two-factor (2FA) authentication.

IdP and SP Side Configuration

On the IdP side, you can configure the different ways to authenticate through an AuthnContext URI. The URI look similar to: urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.

For example, you can use the PasswordProtectedTransport AuthnContext for a normal username or password and use the X.509 AuthnContext to authenticate using a certificate. This activates multi-factor authentication.

In addition, some providers allow Levels of Assurance (LOA), where each level can have a variety of options for authentication. For example, an LOA of 2 can allow authentication from different devices. These levels are also expressed using a URI.

The AuthnContext URI is sent with the SAML request in the RequestedAuthnContext element. The IdP sends the correct type of authentication and once it succeeds, it returns the SAML response with the AuthnContext URI specified in the AuthnStatement element. To trigger 2FA on the proxy, create a SAML request with a specific AuthnContext value and send it to the IdP to handle the response back.

Tenant-Level Properties

Configure the following tenant service-level properties in Skyhigh CASB:

2fa.enabled. (Boolean value) Enables step-up auth with the following properties.
2fa.authncontext.loa. (Integer value) Sets the Level of Assurance value of the action. If this property isn't set, 2FA is skipped.
2fa.authncontext.loa[#].uri. (string) The AuthnContext URI for a certain LOA (specified by the [#] value – like 2fa.authncontext.loa2.uri).
2fa.forceauthn. (Boolean value) Sets whether to turn on ForceAuthn. If ForceAuthn is true, then the IdP forces authentication every time instead of having the auth session last.
2fa.saml.binding. (HTTP-POST or HTTP-Redirect) SAML request binding; the method that the request should be sent.
2fa.saml.destination. (string) IdP destination; where the SAML request goes.
2fa.saml.endpoint. (string) SP endpoint; where the SAML response goes.
2fa.saml.issuer. (string) Issuer; should match in SP/IdP.
The 2fa.saml values should already be specified on the SP (SFDC) settings.

For example, the tenant service level properties values are:

2fa.enabled = true
2fa.authncontext.loa = 1
2fa.authncontext.loa1.uri = urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport 
2fa.authncontext.loa2.uri = urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken 2fa.forceauthn = false
2fa.saml.binding = HTTP-POST
2fa.saml.destination = http://idp.net:8080/openam/SSOPOST/metaAlias/idp
2fa.saml.endpoint = https://chapman1crm.bell.devshn.net?so=00Do0000000aEGT&shnsaml
2fa.saml.issuer = https://chapman1crm.bell.devshn.net/

Limitation

You must manually enter the properties and values at this point. SP properties must be repeated on the proxy side, and SP or IdP metadata are not accepted.

Validate IdP and SP Side Configuration

To enable 2FA using AuthnContext values, the step-up authentication requires modifications on IdP and SP sides.

Before you begin with the validations, configure SAML proxy for Salesforce. For details, see Integrate Skyhigh CASB for Salesforce with PingFederate SSO.

Once you configure SAML proxy for Salesforce, you can view these configured screens.

Log in to Salesforce to view the SP configurations.
You can see the Ping Federate IdP configurations.
While validating SP and IdP configurations, check these criteria:
- The SP Issuer should match the IdP Virtual Server ID field.
- The SP Entity Id should match the IdP Entity ID field.
- The Salesforce Login URL should be set as the Assertion Consumer Service URL. Append the Proxy URL and &shnsaml for the ACS URL at the end.
- The Identity Provider Certificate in Salesforce should be set as Skyhigh CASB proxy certificate.
- The Request Signing Certificate in Salesforce and the Selected Certificate in Ping IdP should be uploaded to the proxy.

Configure 2FA in the IdP

To configure 2FA with Ping IdP, set up Adapters to log in. The two Adapters are:

OTIdPJava adapter. You can login from a sample IdP website, where the username/password can be configured in the file /shn/ping/pingfederate-7.1.1_idp_sp_sample/pingfederate/server/default/deploy/IdpSample.war/config/pingfederate-idp-demo-users.props.
google2 adapter. You can log in through a Google account.

Map Results to Adapter Instances

Log in to PingFederate and go to IdP Configuration on the Home page > Application Integration Settings > Adapter Selection.
Activate the Enable Adapter Selection.
Select an adapter instance to map with results. Let's say, there is a test selector instance of type SAML Authn Context Adapter Selector, meaning that the adapter chosen depends on the AuthnContext value sent in the SAML request.
Each result value is mapped to an appropriate Adapter Instance. Here, PasswordProtectedTransport is mapped to OTIdPJava, and MobileOneFactorUnregistered is mapped to google2.
In the actual SP connection, add both adapters so Ping knows that you are using the adapters in the connection.
To enable the 2FA feature in proxy, add these properties in Skyhigh CASB as mentioned in the Tenant Level Properties.

As a result of the above 2FA configurations:

When you log in to Salesforce, you are prompted to the regular IdP login.
When you try to export a report, you are prompted to the Google login.

NOTES:

With these settings, the Salesforce email should be equal to the IdP login username, which should be the same as the Google account name.
If required, the Salesforce email can be replaced by the Federation ID value by changing the SAML Identity Type in the Salesforce SSO settings.
The Federation ID value can be manually set for each user when you edit a user in Salesforce.

Supportability

Logs should be comprehensive. The main places to enable logs are:

com.shn.http.proxy.auth.SAMLProxyHandler
com.shn.http.proxy.app.SimpleProxyApplication

NOTE: SHN-Request-Content cookie is a base 64 encoded JSON string. The SHN-2FA-Request cookie is encrypted.