Table of Contents:
Tying it all together
Cloud Connectivity Blade FAQ
How to configure Cloud Connector
The increased use of SaaS (Software as a Service) applications by enterprises creates new security risks.
Corporations risk losing control over data and assets that are managed by SaaS applications. With end users logging in from unauthorized computers and mobile devices, IT managers lose control and visibility of user actions. This has other implications, which include failing to meet compliance requirements.
In addition to the security challenge introduced by a growing number of SaaS applications, each end user is required to have a different set of credentials for each application. One possible solution to this problem is integrating a Single Sign-On system, but these are normally difficult to maintain and sometimes unable to support different environments. (such as different web browsers and mobile devices).
In order to protect company assets stored in the cloud, IT managers must be able to quickly revoke access to applications when a user leaves the organization. Waiting for the user account information to be synchronized to the SaaS application could leave a window of opportunity, which a disgruntled employee could take advantage of.
Logging all login attempts to all SaaS applications in a single place allows IT managers to have better insight into user activities, and facilitates any forensic investigation when the need arises.
Users may have difficulties remembering a different set of credentials for each SaaS application they use. This results in users forgetting passwords and increases the work load of help desks.
Having a different set of credentials for each SaaS application is cumbersome to users that need to remember all of them.
By using a single set of credentials - the corporate credentials - and eliminating the need for a separate set of credentials for each SaaS application for each user, IT saves the costs involved in managing a plethora of user credentials.
IT managers would like to be able to enforce a single password complexity policy to meet security and regulatory requirements. While some SaaS applications allow IT managers to set such a policy, each SaaS application would need to be configured separately.
The Cloud Connector feature solves these problems and allows IT managers to regain the control they have lost when applications were moved to the cloud.
This is achieved by providing the following services:
- Identity mapping
- Logging and reporting
Users that are logging in to a SaaS application are redirected to a portal on the Check Point Security Gateway.
The portal authenticates the users with their corporate credentials.
This can be achieved in several forms including:
- Automatically: for internal users, using Kerberos
- Automatically: for remote access users, who are connected to the organization over a VPN terminated by the Security Gateway
- If all else fails, through a Web UI with username and password.
Users, whose AD account has been disabled by the IT administrator are not granted access.
All authentication attempts are logged by the Security Gateway.
The Security Gateway enforces a security policy that can determine which user is allowed to which application, and from which network the login is allowed.
All authorization decisions are logged by the Security Gateway.
(IV) Identity mapping
Each user normally has a corporate account alongside an account in each SaaS application.
While some SaaS applications might be configured to recognize users by their corporate usernames, others might be configured to recognize them by their e-mail addresses or some other unique token.
The Cloud Connector can be easily configured to map corporate identities to SaaS application identities in an intuitive and simple manner.
It also support use cases where a group of corporate users share the same SaaS application user account.
All identity mapping decisions are logged.
(V) Tying it all together
The Cloud Connector feature uses a protocol called SAML.
SAML stands for Security Assertion Markup Language.
A typical SAML environment consists of:
- A user
- A SAML Service Provider
- A SAML Identity Provider
In a typical use case, the user is trying to login to a web application provided by a Service Provider.
Common examples for such Service Providers are SalesForce, Google Apps and Office 365.
The service provider redirects the user's web browser to the Identity Provider.
The Identity Provider is implemented by the Check Point Security Gateway.
The Identity Provider authenticates the user and creates a SAML assertion - a signed XML document attesting to the user's identity.
The Identity Provider automatically redirects the web browser to submit the assertion to the Service Provider.
The Service Provider verifies the digital signature on the assertion, then gives the user access to the application.
(VI) Cloud Connectivity Blade FAQ
Click Here to Show Entire FAQ
- What is SAML?
Quote from http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language:
Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). SAML is a product of the OASIS Security Services Technical Committee.
- What version of SAML do you support?
We support both SAML v1.1 and SAML v2.0.
- What SAML use cases do you support?
We support both SP (Service Provider) initiated, as well as IdP (Identity Provider) initiated logins.
- How is the feature delivered?
The feature requires a Check Point Security Gateway running R77.30 (and higher), which is managed by a Security Management Server / Multi-Domain Security Management Server running R77.20 (or higher) with the relevant Management Add-On enabled.
- On which Security Gateway should I enable this feature?
In terms of network topology, the Security Gateway should be accessible to all users that are using SaaS applications.
- What cloud applications are supported?
Refer to last step in section How to configure Cloud Connector below.
In addition, we can work with other applications that support the SAML standard.
- Is any configuration or software needed on the end-user side?
SAML works with web application.
- What web browsers do you support?
We support the following web browsers:
- Internet Explorer
- iOS Safari
- Android Internet
- What types of users are supported?
The following user types are supported:
- remote access (IPsec and SSL)
- What kind of authentication do you support?
We support LDAP-based and AD-based authentication.
Two factor authentication mechanism are not supported at the moment.
- Do you support automatic Single-Sign-On (SSO)?
SSO is supported in two use cases:
- Internal users that are logged in to the corporate Domain Controller would be automatically logged in.
- If a remote access user is connected to the organization over a VPN terminated by the Security Gateway.
- What about High Availability?
There are two options:
- Deploy the Cloud Connectivity blade on top of a ClusterXL.
- Deploy the Cloud Connectivity blade on two different Security Gateways.
Both Security Gateways would need to use the same URL for their Cloud Connectivity blade portal (e.g., https://sso.acme.com/connect).
The host name would then have to be resolved to the IP addresses of both Security Gateways.
If one Security Gateway fails, then web browsers would fallback to use the IP address of the 2nd Security Gateway.
- I am getting an error message: "
XMLHttpRequest is not enabled or supported by your web browser"
You are either using an unsupported web browser (e.g., Internet Explorer 6), or your web browser is not configured properly.
If you are using Internet Explorer, go to '
Tools' menu - click on '
Internet Options' - go to '
Advanced' tab - in the '
Security' section, verify that this box is checked: Enable native XMLHTTP support.
- Remote Access (IPsec) users are not automatically logged in and are prompted for user name and password, what should I do?"
The Identity Awareness will automatically authenticate Remote Access (IPsec) users, if their traffic is sent over an IPsec tunnel.
Make sure the URL of the Identity Awareness Captive Portal can be resolved to an internal IP address, which is inside the Security Gateway's encryption domain and not the external IP address of the Security Gateway.
(VII) How to configure Cloud Connector
- Install R77.20 Add-On / R77.30 Add-on on your Security Management Server / Multi-Domain Security Management Server.
Enable the Captive Portal feature (also referred to as "Browser-Based Authentication") of the Identity Awareness Software blade in the object of your Security Gateway.
Follow these instructions in Identity Awareness Administration Guide:
- Chapter 2: Configuring Identity Awareness
- Chapter 3: Identity Sources
Since SAML assertions are time-stamped, make sure NTP is enabled and working on the Security Gateway:
Configure Cloud Connector to work with your SaaS application: