Security

I have been trying to configure Clearpass and Okta to be able to enable Onboarding process. Currently we are buying Clearpass but I am testing on the evaluation license POC how this will work when we deploy in production. The way I thought this might work is that after i configure the settings our users will be able to see a Clearpass Onboard icon in their Okta dashboard that will give them access to onboard their devices onto the corporate network.

I have tried to followed these two documents when configuring this:

1. "SAML Configuration Guide v1.5"
2. "Clearpass Configuration Guide Onboard and Cloud Identity Providers"

Both of these guides did not help me get this configured at all. The SAML guide was created in 2017 and the Okta interface has changed. The other guide was more helpful but I still get this error:

HTTP Status 403 – Forbidden
Type Status Report

Message RelayState missing/invalid

Description The server understood the request but refuses to authorize it

I checke Okta logs and it says that the connection attempt was successful. In Clearpass I see nothing in the Event Viewer or the Access Tracker. I then I went to Server Configuration and collected the logs. In the network-services.log.0 I saw this statement:

2020-10-13 15:19:04,320 [ajp-apr-8009-exec-8] [R:] ERROR com.avenda.tips.webauthservice.sso.saml.SamlSp - RelayState missing

There is nothing in either of those guides that mention anything about configuring the relay state. Please help. 

Hi,

ClearPass/SP server adds relay state to the SAML Request when redirecting the client to the IDP (note: ClearPass supports SP initiated SSO flow) and expects the same relay state in the SAML Response from IDP (i.e. when the idp/Okta sends the client back to the ClearPass with SAML response). 

The observed error could mean that idp/Okta did not return the relay state or returned a different relay state in the response.

Okta may have default relay state configuration which would be used for all idp responses ignoring the relay state sent by SP. 

See if the default relay state is enabled in Okta and disable it to run the test again.

You can use SAML tracer extension on client browser to debug this further.

So I must not be understanding this correctly. So this is only for SP initiated SSO flow and my users cannot use their Okta dashboard to gain access to the Onboarding process. I have already been testing via the Okta dashboard. That being said can you please let me know how the flow should work using Okta? Is this entire setup just to be able to use Okta as an authentication source?

I am not sure how to test the connection using SAML tracer because I am not sure how I should be accessing the Onboard process. 

Hi,

AFAIK, ClearPass supports SP initiated OnBoarding where the users land in ClearPass OnBoard portal and then get redirected to idp/OKTA login page. After a successful login, OKTA will redirect the clients back to ClearPass to continue with device enrollment.

You can configure OKTA as IDP server in the ClearPass for authentication. Follow the same tech notes you have referred for SP initiated authentication to set up Onboarding.

IdP-initiated is not supported.

I was having the same problem / receiving the same error messages. I can confirm that the Default Relay State should be blank in the SSO config and it is not a requirement for CPPM. 

My issue turned out to be DNS related. While I did add the URL that I use to log into CPPM with under the SAML Requestable SSO URLs, after a successful SAML auth, when CPPM tries to redirect you back to the originally requested CPPM page, it defaults to the Hostname in the browser URL if there is no FQDN defined in CPPM. After I added a DNS record for the hostname of my CPPM and added the hostname as a Requestable SSO URL in OKTA, the "RelayState missing/invalid" error went away, and I was redirected to CPPM.

The caveat with this is, the hostname defined on my CPPM is a different domain than my HTTPS cert. So while the above workflow worked, I did receive a cert error on the final redirect to CPPM. This was easily fixed by adding an FQDN on CPPM / Server Config with a DNS name that my client can resolve and trust via CPPM's HTTPS cert.

After updating the FQDN, I was able to remove the CPPM hostname defined in the SAML Requestable SSO URLs and my client was able to login in end-to-end with no cert errors.