Okta SAML Authentication Login for Smart Console

[Simon_Macpherso]

Hello,

Has anyone tried integrating Okta SAML Authentication for Smart Console on R81.20? 

I have configured the Smart Console and IDP side. 

When I try to authenticate using either a local administrator account or an account that is a member of an ID administrator group, the authentication fails returning "No local administrator with the name '<email.address>' and no groups were found on the SAML Response". 

Also, after creating the identity provider object, when I try to open the object again it cannot be opened correctly retuning 'unable to load page. (see attached image). Not sure if this is cosmetic and a Smart Console bug or there is an issue with the object itself which is might be impacting the integration.   

I cant find any Okta specific documentation. The video in the below document is specific to Azure. 

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SecurityManagement_AdminGuid...

One IDP configuration item I'm not 100 sure on is the group attribute setting. I believe the Group ID or name (which return the same value) needs to be used. I've tried 'name', 'Name', 'Group-ID', 'group-id', filtering by 'starts-with', 'contains', and 'exact'. I've tried authenticating with a local user account (full email address) and with the same account that is a member of am identity provider administrator group.  

I have a TAC open.

Regards,

Simon

[PhoneBoy]

Possible the relevant group needs to be created in a manner similar to: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
(I.e. begins with EXT_ID_)

[Simon_Macpherso]

I can now get it working with a local administrator account using email address as the username. The problem here was the user name is case sensitive i.e. John.Smith@checkpoint.com.

Still can't get authentication using groups working. The problem is not knowing what to add in the name and filter on fields under the group attributes configuration on the app. 

The following is from the Okta documentation

• Group Attribute Statements (optional): If your Okta org uses groups to categorize users, you can add group attribute statements to the SAML assertion shared with your app.
  Define Group Attribute Statements

  In the Group Attribute Statements (optional) section:

  1. Enter the Name of the group attribute in your SAML app.
  2. Select a Name Format.
  3. Choose a Filtering option for your expression: Starts with, Equals, Contains, or Matches regex
  4. Enter the expression to match against the Okta GroupName values and add to the SAML assertion.
  5. Click Add Another to add an extra group statement row
  6. Repeat until all necessary groups are defined.

[PhoneBoy]

We read the group_attr field per https://support.checkpoint.com/results/sk/sk177267
I can't speak to how you configure the other fields as they appear to be largely environment dependent.

Let's assume you've configured this correctly and one of the groups returned to us is called SmartConsole_Admins.
On the Check Point side, the relevant group should be called EXT_ID_SmartConsole_Admins.

It might be useful to see what the SAML assertion says for the affected users: https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml_view-saml-response.html

[Simon_Macpherso]

Is the prefix 'EXT_ID_' definitely required on the Checkpoint side? 

I'm assuming this needs to be entered in the Group ID/Name field in the Identity Provider Administrator Group, as according to the documentation the name of the group can be anything (see below).

On the Okta side in the SAML configuration under Group Attribute Statements (optional), the attribute name is EXT_ID_smart_console_admins,  filtering on exact or contains 'OK Security Firewall', which is the name of the Okta group assigned to the Okta application. 

I've tried this and I still receive "No local administrator with the name '<email.address>' and no groups were found on the SAML Response". I've also tried it without the 'EXT_ID_' prefix on the Checkpoint side i.e. value 'smart_console_admins' in the Group ID/Name field.

For an administrator group, configure these settings:

• Name - Enter a name for the administrator group object. You can select any name.

• Group ID/name - Must be identical to the group attribute defined in the Identity Provider.

• Permission - Assign the required permission profile.

Regards,

Simon

[PhoneBoy]

We use EXT_ID_ on our end to differentiate SAML defined groups from internally-defined ones.
Which means:

• Okta should return smart_console_admins (and not EXT_ID_smart_console_admins) as part of the SAML assertion
• In Check Point, the group is defined with the name EXT_ID_smart_console_admins

Note this is how you would configure it to use SAML Authentication for Remote Access.
There isn't a similar note for SmartConsole Authentication, but I presume it works on the same principle.
The capitalization also needs to match how it is defined on the IdP.

If you can't make this work, then we'll need to see the SAML Assertion returned by Okta.

[Simon_Macpherso · Accepted solution]

Yea the EXT_ID_ prefix appears to specific to configuring SAML auth with remote access, though I'm still not sure if its required. Under Step 6 for SAML Support for Remote Access VPN in the R81.20 admin guide, when creating an internal user group object it states to create it with the name EXT_ID_<Name_of_Role>. Though this might be just to differentiate it from internally-defined groups as you have done.  

I can confirm it's not required for SAML auth with Smart Console.

I managed to get authentication working with identity provider administrator groups. 

In the Okta app SAML configuration, for the group attribute I needed to specify 'groups' for the name and for the filter use a regular expression that matches i.e. .*admins.*.. The example regex matches all Okta groups with 'admins' in the name. In the identity provider administrator group, the Group ID/Name you configure under Authentication needs to match the Okta group name you have assigned to the Okta application. Underscores are not required and spaces are accepted. 

I am still unable to view the Identity Provider object correctly in Smart Console. The object continues to return 'Unable to load page' when viewing or editing the object. At least we know this error is not affecting the operation of the IDP object and appears to be a Gaia OS or Smart Console bug.  

I am going to set up SAML authentication for remote SSL VPN access soon.

Thanks for your assistance @PhoneBoy. 

[the_rock]

Let us know how this gets solved, it will be nice to know.

[PhoneBoy]

The EXT_ID_ thing is definitely required for Remote Access groups.
It wasn't mentioned for SmartConsole configuration.

As for why you can't view/edit the IdP object, I don't have any insight.
A TAC case is definitely warranted for that.

[Simon_Macpherso]

I've got a TAC open for the IDP object issue and will let you know what the outcome is.  

[Simon_Macpherso]

TAC are still investigating the object issue.

We noticed today that the Okta app cannot be opened directly from the Okta apps dashboard. 

The following is returned:

"ERROR: error processing Saml response, it might be due to time out."

I have the Reply URLs value that is generated when creating the identity provider object configured for Single sign-on URL, recipient URL and Destination URL values in the Okta app SAML configuration per the Okta documentation below. 

The Reply URLs value is 'https://<mgmtip>/cpmws/saml/acs/sso'.

From the Okta documentation: 

• Single sign-on URL: The location to send the SAML assertion using a POST operation. This URL is required and serves as the default Assertion Consumer Services (ACS) URL value for the Service Provider (SP). This URL is always used for Identity Provider (IdP) initiated sign-on requests.
  • Use this for Recipient URL and Destination URL: Select this checkbox if you want the recipient and destination URL to be the same.
    • Recipient URL: (Appears if the previous checkbox isn't selected.) The location where the application can present the SAML assertion. This is usually the Single Sign-On (SSO) URL.
    • Destination URL: (Appears if the previous checkbox isn't selected.) The location to send the SAML Response, as defined in the SAML assertion. This should be the same location as the Single sign on URL unless your application explicitly defines a specific value.

[PhoneBoy]

The response URL is probably not something that can be reached by Okta to "check" it (assuming the management IP is private).
In which case, that is probably expected behavior.

[Simon_Macpherso]

The management IP is an external IP in the DMZ behind a gateway.  

When opening the application directly from the Okta app dashboard, a new browser window opens to 'https://<mgmt_external_ip>/cpmws/saml/acs/sso', the error '"ERROR: error processing Saml response, it might be due to time out.' is then returned. I don't see any traffic hitting the external IP from Okta, only traffic from the local users IP connecting to this destination. 

Below is the process flow. 

1. The user tries to log in to SmartConsole.

2. SmartConsole redirects the user back to the browser to a URL which is pre-configured on the Management Server.

3. The Management Server redirects the browser with a SAML request to the Identity Provider.

4. The Identity Provider authenticates the user.

5. The Identity Provider generates a SAML assertion and sends it back to the Management Server through the browser.

6. The Management Server validates the SAML assertion.

7. If the user is authenticated, the Management Server redirects the browser to SmartConsole with the necessary data required for authentication.

8. SmartConsole opens a session to the Management Server with this authentication data.

[Simon_Macpherso]

It seems SmartView web (http://mgmt_ip/smartview) does not support SSO?  There is no option to select IDP.  When opening SmartView whilst logged in to Smart Console with SSO, it just opens the login page in a new browser window. 

[PhoneBoy]

Appears you are correct.
@Tomer_Noy I assume this is something we are planning to address?

[Tomer_Noy]

Actually, Web SmartConsole includes a logs tab, which is essentially the full SmartView, embedded within that application.

Since you can use SmartView that way, we don't currently plan to integrate the additional login capabilities into the SmartView login page.

[Zerat]

could you explain why CP don't support web access with SAML?
it should be easier than with smartconsole app
we have plenty of users who just want to check some logs regarding infrastructure - they don't need full smart console functionality and it's easier for them to use web than install the app...

[PhoneBoy]

Web SmartConsole gives you the same functionality as SmartView and supports SAML Authentication.

[Zerat]

ok, I find the solution in other thread
it was my mistake, so consider the comment retracted 😉

[Chris_Newman]

We need to set this up for our environment also, wondering if TAC helped you resolve this and if you were able to get SmartConsole to work with Okta SAML?

[Simon_Macpherso]

Hi, see accepted solution.

[the_rock]

I never did that exact config before, but I had done Onelogin as saml IDP and saml on Fortigate and errors like that inidicate group name mismatch on Azure side. 

Sk phoneboy gave you looks promising.