Single Sign-on with SAML 2.0

Organizations have been moving to centralize their user access either through third party identity management SaaS services, such as Azure AD, or through on-premise identity providers. Moving to an identity provider allows organizations to centrally manage user access and permissions based on roles for improved security while helping to improve the user experience for internal users.

With 7.7, we offer Single Sign-On (SSO) support for web-based access to the Indeni platform by supporting Security Assertion Markup Language (SAML) 2.0. This means that your users can use your own company’s identity management system to authenticate on the Indeni platform. Users no longer need to remember a separate set of credentials to access the Indeni web-based application.

For information about the configurations involved in integrating SAML 2.0 with Indeni, please refer to the Indeni 7.0 User Guide – SAML 2.0 Integration.

How it works

Scenario:

Company Acme uses Cyberark Idaptive as its identity provider. The organization policy is to have all users access their applications via SSO. Bob is the administrator for the Indeni platform so he requires administrative access. The other firewall engineers only require read-only access.

Here’s a walkthrough of how SSO works:

The Idaptive administrator adds the Indeni web application for SSO to Idaptive. The administrator sets up accounts for Bob and the other firewall engineers.
As the Indeni administrator, Bob is responsible for setting up the SAML integration. He assigns a default role of read-only to all the users from the SSO integration configuration.
The Idaptive administrator notifies Bob and the other firewall engineers that their accounts have been set up. The users have the option to access the Indeni web application from their identity provider user portal (Identity Provider initiated sign-in flow) or they can access Indeni by clicking the SSO LOGIN button (Service Provider initiated sign-in flow).
Bob goes to the Indeni platform login page and hits the SSO LOGIN button. When Bob hit the SSO LOGIN button, the login request was redirected to Idapative. Since Bob is already authenticated to Idaptive, he is immediately redirected to the Indeni landing page, without having to enter a password. Behind the scenes, the Indeni platform receives the assertion for Bob, verifies the assertion and accepts the login request.
The first time Bob signed in with SSO, a new username bob@acme.com is created in the local database. To change his role to admin, Bob can sign into Indeni using the admin user. From Settings -> Users, he can explicitly assign role=admin for his Idaptive username bob@acme.com.
Alice is a firewall engineer. She accesses the Indeni web application from the Idaptive user portal. The flow is similar to 4. above. The new user name alice@acme.com is created after the first login. Since Alice requires read-only access to Indeni, no further action is required from Bob.

Migration Considerations

If you are migrating from local users to using SAML SSO and you want to enforce SSO, you should remove the user from the local user database. This way the local authentication will fail.

Note: To ensure that you will not be logged out of the Indeni system, you can continue to use the admin user to sign in to the Indeni server.

Check Point Device Hardening

In 7.7, we added a couple of new device hardening Auto-Detect Elements to provide a strong first line of defense for your Check Point devices.

Device management accessible from the management LAN network only (the interface can be a dedicated physical interface or a virtual interface.)
Ensure activity logs and audit records are enabled.