IF-MAP Federation Use Cases

This section describes the various IF-MAP use cases. Using IF-MAP federation the users can seamlessly access with a single log in to corporate resources protected by the firewall. It provisions seamless access between the user sessions of ICS and IPS.

Access Control in the Federated Enterprise

In a federated enterprise, a user can log in to a IPS or ICS device for authentication or remote access and access the resource protected by the firewall connected to another IPS. The session information is shared across IPS or ICS device using IF-MAP protocol through IF-MAP server.

The federation requires dynamic auth table provisioning on the SRX firewall and allows access to the protected resource based on the resource access policies that are configured on IPS.

The access solution serves the following objectives:

  • Ensures that the employees can access the corporate network and can access resources and data in both local and remote locations without having to specify their authentication credentials at each security policy enforcement point.
  • Enhances security by enforcing role or policy based access control.

The session federation work flow is described below:

  1. The user connects to network and authenticates with IPS/ICS (FC1).
  2. Authentication information such as IP address, MAC address, username, and roles are published to the IF-MAP server.
  3. The user tries to access protected resource from the branch office.
  4. The firewall blocks the access.
  5. The firewall requests IPS (FC2) for session details such as user roles. IPS device subscribes to session information and other endpoint data based on the originating IP address.
  6. The federation server sends the search result based on the search request from IPS (FC2).
  7. IPS (FC2) send roles and policy information to the firewall.
  8. The firewall allows or denies traffic based on the resource access policies received from FC2.

Session Migration across ICS and IPS using IF-MAP

IF-MAP federation allows seamless access to the users connected through remote access and on premise network without re-authenticating. For example, a user can connect from home through ICS and then arrive at work and connect through IPS without logging in again. The session migration also enables users to access different resources within the network that are protected by internal devices without repeatedly providing credentials.

When a session is migrated, realm role-mapping rules determine user access capabilities. You can import user attributes when a session is migrated, or you can configure a dedicated directory server to look up attributes for migrated user sessions. To ensure that session migration retains user sessions, configure a limited access remediation role that does not require a Host Checker policy. This role is necessary because the Host Checker timeout can be exceeded if an endpoint is in hibernation or asleep. With the new remediation role, the user's session is maintained. The session migration works only with same authentication group.

If additional Host Checker policies are configured on a role or realm to which a migrated session applies, the policies are performed before allowing the user to access the role or realm. Administrators of different Ivanti servers should ensure that Host Checker policies are appropriately configured for endpoint compatibility.

The session migration workflow is as follows:

  1. User connects to ICS and the information is published to the federation server, which includes session identifier.
  2. The session identifier information is also communicated to Pulse client.
  3. When user connect to IPS in the same authentication group after arriving at office network using Pulse client.
  4. The Pulse client sends session identifier to IPS.
  5. IPS appliance uses the session identifier to look up the session information in the IF-MAP server and request to migrate the session from ICS to IPS.
  6. IPS create a local session for the endpoint.

To permit session migration for users with the Pulse client, perform the following tasks:

  1. Configure location awareness rules within a client connection set to specify locations included in the scope of session migration for users. For example, configure location awareness rules for a corporate IPS server connection and a ICS server connection.
  2. Configure an IF-MAP federated network, with the applicable Ivanti servers as IF-MAP Federation clients of the same IF-MAP Federation server.
  3. Ensure that user entries are configured on the authentication server for each gateway.
  4. Ensure that user roles are configured for all users on each gateway.
  5. Define a remediation role with no Host Checker policies to allow user sessions to be maintained when an endpoint is sleeping or hibernating.
  6. Configure role-mapping rules that permit users to access resources on each gateway.
  7. Enable and configure session migration from the User Realms page of the admin console.
  8. Distribute the Pulse client to users.

Configuring Session Migration for Pulse Client

Ensure that all of the IPS and ICS servers for which you want to enable session migration are IF-MAP

Federation clients of the same IF-MAP Federation server. Additionally, make sure that each gateway is configured according to the procedures outlined in this section.

To configure session migration:

  1. In the admin console, select Users > User Realms.
  2. Select an existing realm, or create a new realm.
  3. On the General page, select the Session Migration check box. Additional options appear.
  4. In the Authentication Group box, enter a string that is common to all of the gateways
  5. that provision session migration for users. The authentication group is used as an
  6. identifier.
  7. Select for either the Use Attributes from IF-MAP option button or the Lookup Attributes using Directory Server option.

Select Lookup Attributes using Directory Server only if you are using an LDAP server. Attributes are served faster with an LDAP server.

Authentication Server Support

The behavior of session migration depends to some extent on the authentication server on the inbound side.

The following list provides a summary of authentication server support:

  • Local authentication server-Migration succeeds if the username is valid on the local
  • authentication server.
  • LDAP server-Migration succeeds if the LDAP authentication server can resolve the username to a distinguished name (DN).
  • ACE server-Migration always succeeds.
  • RADIUS server-Migration always succeeds. If you select Lookup Attributes using Directory Server, no attributes are present in the user context data.
  • Active Directory-Migration always succeeds. The Lookup Attributes using Directory Server option may not work, depending on your configuration.
  • Certificate-Migration succeeds if the certificate is valid.
  • SAML-Migration always succeeds because Identity provider is external server.