Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

User Role Firewall Security Policies

 

User role firewall policies allows the administrators to permit or restrict network access for users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more informative forensic resources, improve record archiving for regulatory compliance, and enhance routine access provisioning.

Understanding User Role Firewalls

Network security enforcement, monitoring, and reporting based solely on IP information soon will not be sufficient for today’s dynamic and mobile workforce. By integrating user firewall policies, administrators can permit or restrict network access of employees, contractors, partners, and other users based on the roles they are assigned. User role firewalls enable greater threat mitigation, provide more informative forensic resources, improve record archiving for regulatory compliance, and enhance routine access provisioning.

User role firewalls trigger two actions:

  • Retrieve user and role information associated with the traffic

  • Determine the action to take based on six match criteria within the context of the zone pair

The source-identity field distinguishes a user role firewall from other types of firewalls. If the source identity is specified in any policy for a particular zone pair, it is a user role firewall. The user and role information must be retrieved before policy lookup occurs. If the source identity is not specified in any policy, user and role lookup is not required.

To retrieve user and role information, authentication tables are searched for an entry with an IP address corresponding to the traffic. If an entry is found, the user is classified as an authenticated user. If not found, the user is classified as an unauthenticated user.

The username and roles associated with an authenticated user are retrieved for policy matching. Both the authentication classification and the retrieved user and role information are used to match the source-identity field.

Characteristics of the traffic are matched to the policy specifications. Within the zone context, the first policy that matches the user or role and the five standard match criteria determines the action to be applied to the traffic.

The following sections describe the interaction of user and role retrieval and the policy lookup process, methods for acquiring user and role assignments, techniques for configuring user role firewall policies, and an example of configuring user role firewall policies.

User Role Retrieval and the Policy Lookup Process

For policy lookup, firewall policies are grouped by zone pair (the from zone and to zone). Within the context of the zone pair, IP-based firewall policies are matched to traffic based on five criteria—source IP, source port, destination IP, destination port, and protocol.

User role firewall policies include a sixth match criteria—source identity. The source-identity field specifies the users and roles to which the policy applies. When the source-identity field is specified in any policy within the zone pair, user and role information must be retrieved before policy lookup can proceed. (If all policies in the zone pair are set to any or have no entry in the source-identity field, user and role information is not required and the five standard match criteria are used for policy lookup.)

The user identification table (UIT) provides user and role information for an active user who has already been authenticated. Each entry in the table maps an IP address to an authenticated user and any roles associated with that user.

When traffic requires user and role data, each registered UIT is searched for an entry with the same IP address. If a user has not been authenticated, there is no entry for that IP address in the table. If no UIT entry exists, the user is considered an unauthenticated user.

Policy lookup resumes after the user and role information has been retrieved. The characteristics of the traffic are matched against the match criteria in the policies. The source-identity field of a policy can specify one or more users or roles, and the following keywords:

authenticated-userUsers that have been authenticated.
unauthenticated-userUsers that have not been authenticated.
anyAll users regardless of authentication. If the source-identity field is not configured or is set to any in all of the policies for the zone pair, only five criteria are matched.
unknown-userUsers unable to be authenticated due to an authentication server disconnection, such as a power outage.

For example, consider user-c who is assigned to the mgmt role. When traffic from the trust zone to the untrust zone is received from user-c at IP address 198.51.100.3, policy lookup is initiated. Table 1 represents three policies in a user role firewall for the trust to untrust zone pair.

Table 1: Trust Zone to Untrust Zone Policy Sequence

src-zone

src-zone

dest-zone

src-IP

dest-IP

source-identity

Application

Action

Services

P1

trust

untrust

192.0.2.0

203.0.113.0

any

http

deny

P2

trust

untrust

any

any

mgmt

any

permit

P3

trust

untrust

198.51.100.3

any

employee

http

deny

All policies for the zone pair are checked first for a source-identity option. If any of the policies specifies a user, a role, or a keyword, user and role retrieval must occur before policy lookup continues. Table 1 shows that policy P2 specifies mgmt as the source identity, making this a user role firewall. User and roles must be retrieved before policy lookup can continue.

Note

User and role retrieval would not be performed if the keyword any or if no source identity was specified in all of the policies in the zone context. In such cases, only the five remaining values are matched to the policy criteria.

The UIT represented in Table 2 is checked for the IP address. Because the address is found, the username user-c, all roles listed for user-c (in this case, mgmt and employee), and the keyword authenticated-user become data used to match the traffic to the source-identity field of a policy.

Table 2: UIT Authentication Details

Source IP Address

Username

Roles

192.0.2.4

user-a

employee

198.51.100.3

user-c

mgmt, employee

203.0.113.2

user-s

contractor

Policy lookup resumes and compares the match criteria in each policy in Table 1 to the incoming traffic. Assuming all other criteria match, the first policy that specifies user-c, mgmt, employee, authenticated-user, or any in the source-identity field could be a match for this traffic. Policy P1 matches one of the retrieved roles for user-c, but the source IP address does not match; therefore policy lookup continues. For policy P2, all criteria match the traffic; therefore the policy action is followed and the traffic is permitted. Note that the traffic also matches policy P3, but user firewall policies are terminal—policy lookup ends when the first policy match is found. Because policy P2 matches all criteria, policy lookup ends and policy P3 is not checked.

Policies can also be based on the classification assigned to a user from the user and role retrieval results. Consider a different set of policies for the same zone pair represented by Table 3. If traffic is received from user-q at IP 198.51.100.5, user and role retrieval is required because the source-identity field is specified in at least one of the policies.

Table 3: Trust Zone to Untrust Zone Policy Sequence

policy-name

src-zone

dest-zone

src-IP

dest-IP

source-identity

application

action

Services

P1

trust

untrust

any

any

un-

authenticated-

user

http

deny

P2

trust

untrust

any

any

mgmt

any

permit

P3

trust

untrust

198.51.100.3

any

employee

http

deny

When the UIT entries in Table 2 are checked, no entry is found for IP address 198.51.100.5. Therefore, the user is considered an unauthenticated user. When policy lookup resumes, the traffic matches policy P1 and the traffic is denied.

Understanding the User Identification Table

On the SRX Series device, the user identification table (UIT) contains the IP address, username, and role information for each authenticated user. Entries are ordered by IP address. When username and role information is required by a security policy, all UITs are checked. Finding the IP address in an entry in one of the UITs means that the user at that address has already been successfully authenticated.

Each authentication source maintains its own UIT independently and provides query functions for accessing data. Three types of UITs are supported—the local authentication table, the Unified Access Control (UAC) authentication table, and the firewall authentication table.

Local authentication tableA static UIT created on the SRX Series device either manually or programmatically using CLI commands. All users included in the local authentication table are considered authenticated users. When a matching IP address is found, user and role information is retrieved from the table entry and associated with the traffic. User and role information can be created on the device manually or ported from a third-party authentication server, but the data in the local authentication table is not updated in real time.
UAC authentication tableA dynamic UIT pushed from the Junos Pulse Access Control Service to the SRX Series device. The UAC authentication table of a Junos Pulse Access Control Service contains an entry for each authenticated user. The data in this table is updated and pushed to the SRX Series device whenever its authentication table is updated. Depending on the device configuration, authentication could occur on the Junos Pulse Access Control Service itself or on a third-party authentication server. If the Access Control Service is relaying data from a third-party server, the data is restructured by the Access Control Service to match the file format of its authentication table and pushed to the SRX Series device.
Firewall authentication tableA dynamic UIT created on the SRX when user-firewall is specified as the firewall authentication type in a security policy. This UIT provides an alternative user role source to UAC when firewall authentication is already in use on your SRX Series device. In this way, users defined for pass-through authentication can also be used as a source for usernames and roles when the user-firewall option is specified as the firewall authentication type in a policy.

The user-firewall authentication type initiates firewall authentication to verify the user by using either local authentication information or external authentication servers supporting RADIUS, LDAP, or SecureID authentication methods. When this type is specified for firewall authentication, the username and associated groups (roles) from the authentication source are mapped to the IP address and added to the firewall authentication UIT.

Local Authentication Table

The local authentication table is managed with CLI commands that insert or delete entries. A local authentication table can be used as a backup solution when a dynamic UIT is not available, or to assign user and role information to devices that cannot authenticate to the network, such as printers or file servers. The local authentication table can be used for testing or to demonstrate how a user role firewall works without firewall authentication or the Access Control Service configured.

The IP addresses, user names, and roles from a third-party authentication source can be downloaded and added to the local authentication table programmatically using CLI commands. If an authentication source defines users and groups, the groups can be configured as roles and associated with the user as usual.

To be compliant with the UAC authentication table, user names are limited to 65 characters and role names are limited to 64 characters. The local authentication table has a maximum of 10,240 authentication entries on SRX1500 devices and above, 5120 authentication entries on SRX650 devices and below, depending on the Junos OS release in your installation. The local authentication table has 5120 authentication entries on the vSRX. Each authentication entry can be associated with up to 200 roles. The maximum capacity is based on an average of 10 roles assigned to each user. This is the same capacity specified for a UAC authentication table.

Use the following command to add an entry to a local authentication table. Note that each entry is keyed by IP address.

The role option in a single CLI command accepts up to 40 roles. To associate more than 40 roles with a single user, you need to enter multiple commands. Keep the following characteristics in mind when adding or modifying authentication user and role entries.

  • Role names cannot be the same as usernames.

  • Using the add option with an existing IP address and username aggregates the role entries. The table can support up to 200 roles per user.

  • Using the add option with an existing IP address and a new username overwrites the existing username for that IP address.

  • Role aggregation does not affect existing sessions.

  • To change the role list of an existing entry, you need to delete the existing entry and add an entry with the new role list.

  • To change the IP address of an existing entry, you need to delete the existing entry and add an entry with the new IP address.

An entry can be deleted by IP address or by username.

The local authentication table can be cleared with the following command:

To display the content of the local authentication table, use the following show... command:

The brief option (the default) displays information in a tabular format sequenced by IP address. User names and role lists are truncated to fit the format.

The extensive option displays the full content for each field. Other options limit the display to a single username, IP address, or role.

UAC Authentication Table

An SRX Series device can act as an enforcer for a Junos Pulse Access Control Service. In this implementation, the SRX Series device acts as a Layer 3 enforcement point and controls access to resources with IP-based resource policies that have been pushed down from the Access Control Service.

When implemented as a user role firewall, the SRX Series device can access the UAC network in a similar way for user role retrieval. In this instance, user and role information for all authenticated users is pushed from the Access Control Service.

The SRX Series device configuration is similar to that of an enforcer. To establish communication, both devices require configuration and password settings to recognize the other. From the SRX Series device, connect the Access Control Service as an infranet controller.

From the Access Control Service, define the SRX Series device as a New Enforcer. Use the same password specified on the SRX Series device.

Users and passwords are defined on the Access Control Service as in a standard authentication configuration. One or more roles can also be associated with users. When a user is authenticated, an entry containing the IP address, username, and associated roles is added to the UAC authentication table on the Access Control Service.

The UAC authentication table is pushed from the Access Control Service to the SRX Series device when the connection between the two devices is initialized. Whenever an entry is added, removed, or updated on the Access Control Service, the updated UAC authentication table is pushed to the SRX Series device.

Resource access policies are not necessary on the Access Control Service for a user role firewall implementation. The access behavior is provided in the policy configurations on the SRX Series device. If resource access policies are defined on the Access Control Service, they are pushed to the SRX Series device, but they are not used unless a specific firewall policy implements UAC policies in the policy’s action field.

The following show services command displays the content of the UAC authentication table on the SRX Series device, confirming that the table has been pushed from the Access Control Service successfully:

The SRX Series device monitors connections and detects if communication to the Access Control Service has been lost. Based on the UAC configuration, the SRX Series device waits for a response for a configured interval before issuing another request. If a response is received, the Access Control Service is considered functional. If no response is received after a specified timeout period, communication is considered lost and the timeout action is applied. The following UAC command syntax configures the interval, timeout, and timeout action:

During a disconnection, if user and role lookup is attempted for the disconnected device, it returns a failure code regardless of the timeout action. If access to all authentication sources is lost, the keyword unknown-user is associated with the IP address. When policy lookup resumes, a policy with unknown-user as the source identity would match the traffic. By implementing a specific policy for unknown-user, you can create a method for handling the loss of authentication sources.

Firewall Authentication Table

Firewall authentication requires users to authenticate to the SRX firewall before permitting access between zones and devices. When traffic is received, the user is prompted for a username and password, and verified against a specified profile of valid users. Depending on the device configuration, firewall authentication verifies that telnet, HTTP, HTTPS (for SRX5800, SRX5600, and SRX5400 devices), and FTP traffic has been authenticated locally or by a RADIUS, LDAP, or SecureID authentication server.

If firewall authentication is in use on a device, the authentication process can also provide the username and role information needed for user role firewall match criteria. In this case, the information is collected and maintained in a UIT called the firewall authentication table. One or more access policies in the edit access hierarchy define authentication methods to be used for firewall authentication.

The firewall authentication table must be enabled as the authentication source for user role information retrieval. The priority option specifies the sequence in which all UITs will be checked.

In a firewall policy for a given zone pair, the firewall-authentication service specified for the permit action initiates authentication of matching traffic. The user-firewall authentication type generates the UIT entry for the authenticated user. The name specified in the access-profile option identifies the profile to be used to authenticate valid users.

The UIT table entry contains the IP address of the traffic mapped to the authenticated user and the user’s associated groups. When the user is no longer active, the entry is removed from the table. Because entries are continuously added and removed as the traffic and authenticated users change, the firewall authentication table is considered dynamic.

When policies within the same zone pair specify the source-identity field as part of its match criteria, all enabled UITs are searched for an entry corresponding to the IP address of the traffic. If found, the associated username and groups are retrieved for source-identity matching. (User authentication group names are considered role names for source-identity matching.)

Policy Provisioning With Users and Roles

All users and roles, whether defined on the SRX Series device or on the Access Control Service, are maintained in a user role file on the SRX Series device. To display all users and roles available for provisioning, use the following show security... commands.

Note

Usernames and roles in the firewall authentication table are not included in the following displays.

  • To display all of the roles that are available for provisioning, use the show security user-identification role-provision all command. Note that the roles from all UITs are listed together.

  • To display all of the users that are available for provisioning, use the show security user-identification user-provision all command.

  • To display all of the users and roles that are available for provisioning, use the show security user-identification source-identity-provision all command.

When a policy configuration is committed, the user role file is checked to determine if all users and roles specified in the policy are available for provisioning. If a user or role is not found, a warning identifies the missing user or role so that you can define it later.

Note

The policy is committed even if a user or role is not yet defined.

Obtaining Username and Role Information Through Firewall Authentication

User role firewall policies can be integrated with firewall authentication both to authenticate users and to retrieve username and role information. The information is mapped to the IP address of the traffic, stored in the firewall authentication table, and used for user role firewall policy enforcement.

The following CLI statements configure firewall authentication for user role firewall enforcement.

  1. If not already established, define the access profile to be used for firewall authentication. You can skip this step if an existing access profile provides the client data needed for your implementation.

    The access profile is configured in the [edit access profile] hierarchy as with other firewall authentication types. It defines clients as firewall users and the passwords that provide them access. Use the following command to define a profile and add client names and passwords for firewall authentication.

  2. If HTTPS traffic is expected, define the access profile to be used for SSL termination services. You can skip this step if an existing SSL termination profile provides the services needed for your implementation.

    The SSL termination profile is configured in the [edit services ssl] hierarchy.

  3. Enable the firewall authentication table as an authentication source.

    The priority value determines the sequence in which authentication sources are checked. The default value is 150 for the firewall authentication table. (It is 100 for the local authentication table and 200 for the Unified Access Control (UAC) authentication table.) By default, the local authentication table is checked first, the firewall authentication table is next, and the UAC authentication table is third if it is enabled. You can change this sequence by changing the priority value of one or more of the tables.

  4. Configure policies that permit traffic for user firewall authentication.

    When unauthenticated traffic is permitted for firewall authentication, the user is authenticated based on the access profile configured in this statement. The ssl-termination-profile option is needed only for HTTPS traffic.

    By specifying the authentication type user-firewall, the firewall authentication table is propagated with the IP address, the username, and any group names associated with the authenticated user. (Group names from firewall authentication are interpreted as roles by the user role firewall.) Any further traffic from this IP address will match the IP address in the firewall authentication table, and not require authentication. The associated username and roles are retrieved from the table for use as potential match criteria in subsequent security policies.

Configuring a User Role Firewall For Captive Portal Redirection

To automatically redirect unauthenticated users to the Access Control Service, use the UAC captive portal feature. The following syntax defines the profile for the captive portal:

The Kerberos protocol, used for authentication encryption, identifies the Access Control Service only by its service principal name (SPN). The protocol does not accept an IP address. Therefore, the format for the redirect URL must be

In this implementation, the service is HTTP and the hostname is the FQDN of the Access Control Service. Options specified after the hostname pass additional information to the Access Control Service directing the user back to the original destination, to the SRX Series device, or to the policy that originated the redirection. You can configure the options using the following keyword and variable pairs:

?target=%dest-url%Specifies the protected resource which the user is trying to access.
&enforcer=%enforcer-id%Specifies the ID assigned to the SRX Series device when it is configured as an enforcer by the Access Control Service.
&policy=%policy-id%Specifies the encrypted policy ID for the security policy that redirected the traffic.

The following statements define the profile of the captive portal named auth-redirect. The captive-portal redirects unauthenticated users to the URL of the Access Control Service for authentication. After successful authentication, the traffic will be directed back to the SRX Series device.

A defined captive-portal profile is displayed as part of the UAC configuration.

After the profile is defined, a policy can apply the captive portal as an application service when certain criteria is matched. Whenever a user role is unauthenticated, auth-redirect captive portal diverts the traffic from trust zone to untrust zone. The following example defines policy P1 to apply the auth-redirect captive portal profile to any HTTP traffic from the trust to untrust:

Example: Configuring a User Role Firewall on an SRX Series Device

The following example configures a user role firewall on an SRX Series device. The firewall controls access from the trust zone to the untrust zone based on active, authenticated users or their associated roles. User role firewall policies establish the following restrictions:

  • Only authenticated users are permitted from the trust zone to the untrust zone.

    Unauthenticated users are redirected to an Access Control Service for authentication.

  • Traffic from IP 192.0.2.0 to IP 203.0.113.0 within the zone context is restricted. Only the traffic from users with the dev-abc, http-juniper-accessible, or ftp-accessible role is permitted. Permitted traffic is further evaluated by AppFW rules.

    • Permitted traffic identified as junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK, or junos:MEEBO application traffic is denied.

    • Permitted traffic for any other application is permitted.

  • All other traffic from the trust zone to the untrust zone is permitted.

Requirements

Before you begin, ensure that the SRX Series device with Junos OS Release 12.1 or later is configured and initialized.

In this example, user and role information associated with the IP address of the traffic is provided by an Access Control Service. For instructions on configuring the Access Control Server, see Acquiring User Role Information from an Active Directory Authentication Server.

Overview

Table 4 outlines a firewall that meets the requirements for this example. The user role firewall consists of four policies.

Table 4: User Role Firewall Policies

policy-name

src-zone

dest-zone

src-IP

dest-IP

source-identity

application

action

Services

user-role-fw1

trust

untrust

any

any

un-

authenticated-

user

http

permit

UAC captive portal

user-role-fw2

trust

untrust

192.0.2.0

203.0.113.0

dev-abc

http-juniper-

accessible

ftp-

accessible

http

permit

AppFW ruleset RS1

user-role-fw3

trust

untrust

192.0.2.0

203.0.113.0

any

http

deny

user-role-fw4

trust

untrust

any

any

any

http

permit

Because the source-identity field is specified for at least one of the policies in this firewall, user and role information must be retrieved before policy lookup is conducted. The source IP of the traffic is compared to the items in the UIT. If the source IP address is found, the keyword authenticated, the username, and any roles associated with this user are stored for later use in policy lookup. If a matching entry for the IP address is not found in the UIT, the keyword unauthenticated-user is stored for policy lookup.

After retrieving the username, roles, and keywords, policy lookup begins. Characteristics of the incoming traffic are compared to each policy’s match criteria. If a match is found, the action specified in that policy is taken.

A policy match is a terminal event, and no policies after the match are checked. Policy sequence influences the action to be taken for matching traffic. In this example, policies are applied in the following sequence:

user-role-fw1Applies the UAC captive portal service to matching HTTP traffic with the unauthenticated-user keyword, and redirects it to the Access Control Service for authentication. A UAC profile must also be configured to identify the captive portal specifications.
user-role-fw2Applies an AppFW rule set to any HTTP traffic from address 192.0.2.0 to address 203.0.113.0 that has a matching username or role. An application firewall must also be configured to define the rule set.
user-role-fw3Denies all remaining HTTP traffic from address 192.0.2.0 to address 203.0.113.0 for this zone pair.
user-role-fw4Permits all remaining HTTP traffic for this zone pair.

Configuration

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User guide.

Configuring Redirection For Unauthenticated Users

Step-by-Step Procedure

When an IP address is not listed in the UIT, the unauthenticated-user keyword is used in policy lookup. Instead of denying access to this traffic, a policy can redirect the traffic to a UAC captive portal for authentication.

Note

It is important to position a redirection policy for unauthenticated-user before a policy for “any” user so that UAC authentication is not shadowed by a policy intended for authenticated users.

To configure redirection from the SRX Series device to the Access Control Service:

  1. From configuration mode, configure the UAC profile for the captive portal acs-device.
  2. Configure the redirection URL for the Access Control Service or a default URL for the captive portal.

    This policy specifies the default target and enforcer variables to be used by the Access Control Service to direct the user back after authentication. This ensures that changes to system specifications will not affect configuration results.

    Note

    When variables, such as ?target=, are included in the command line, you must enclose the URL and variables in quotation marks.

  3. Configure a user role firewall policy that redirects HTTP traffic from zone trust to zone untrust if the source-identity is unauthenticated-user. The captive portal profile name is specified as the action to be taken for traffic matching this policy.
  4. If you are done configuring the policies, commit the changes.

Results

From configuration mode, confirm your configuration by entering the show services and show security policies commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

[edit]
user@host# show services
user@host# show security policies

Creating a User Role Policy With an Application Firewall

Step-by-Step Procedure

This policy restricts traffic from IP192.0.2.0 to IP 203.0.113.0 based on its user and roles, and also its application. The configuration defines an application rule set and applies it to matching user role traffic.

  1. Configure the AppFW rule set rs1. The following rule set denies junos:FACEBOOK-ACCESS, junos:GOOGLE-TALK, or junos:MEEBO application traffic. It applies the default setting, permit, to the remaining traffic.
  2. Configure a policy to apply the rs1 application firewall rule set to traffic from IP 192.0.2.0 to IP 203.0.113.0 with the dev-abc, http-mgmt-accessible, or ftp-accessible user role.
  3. If you are done configuring the policy, commit the changes.

Results

Verify that the AppFW rule set is configured properly. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

[edit]
user@host# show security application-firewall

Creating Remaining Security Policies Based on User and Role

Step-by-Step Procedure

The following procedure configures policies for the remaining traffic.

  1. Configure a policy to deny traffic with the same source and destination address but with different user and role criteria than specified in the user-role-fw2 policy.
  2. Configure a security policy to permit all other HTTP traffic from zone trust to zone untrust.

Results

Verify the content and sequence of the user role firewall policies. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

[edit]
user@host# show security policies

Configuring Resource Policies Using UAC

When using the user role firewall feature, resource policies are not necessary on the Access Control Service. If, however, resource policies exist, they are pushed to the SRX Series device at connection. You can create policies that use these resource policies by applying the UAC application service in the policy configuration. Table 5 shows three firewall policies that use the UAC resource policies exclusively:

Table 5: User Role Firewall Usage

policy-name

src-zone

dest-zone

src-IP

dest-IP

source-identity

application

action

Services

P1

zone1

zone2

any

192.0.2.1

any

http

permit

UTM

P2

zone1

zone2

any

net2

any

http

permit

IDP

P3

zone1

zone2

any

any

any

any

permit

UAC

The policies for traffic from zone1 to zone2 do not initiate user and role retrieval because any is specified in the source-identity field of every policy. In this example, traffic to the IP address 192.0.2.1 is permitted, but must meet processing requirements for the specified application service, in this case, UTM. Traffic to net2 is permitted and processed by the IDP processing requirements. Any remaining traffic is permitted and processed by the UAC processing requirements.

The configuration for this firewall policy would be as follows:

[edit]
user@host# show security policies

In this sample configuration, the action fields in P1 and P2 apply any requirements that have been configured for IDP and UTM respectively. By specifying the uac-policy option, the resource policies pushed to the SRX Series device determine whether the destination is accessible.

A user role firewall can implement both user role policies and the resource policies pushed from the Access Control Service. Table 6 shows the policies for three zone pairs.

Table 6: User Role Firewall Usage

policy-name

src-zone

dest-zone

src-IP

dest-IP

source-identity

application

action

Services

P1

zone1

zone2

any

any

unauthenticated-user

any

permit

UAC captive portal

P2

zone1

zone2

any

192.0.2.1

role2

http

permit

IDP

P3

zone1

zone2

any

net2

authenticated-user

http

permit

UTM

P4

zone1

zone2

any

any

any

any

permit

P5

zone1

zone3

any

any

any

any

permit

UAC

P6

zone2

zone3

any

any

any

any

permit

UAC

Traffic from zone1 to zone2 is subject to one of four user role policies. The first of these policies uses the UAC captive portal to redirect unauthenticated users to the Access Control Service for authentication.

The access of traffic from zone1 to zone3 and from zone2 to zone3 is controlled by the resource policies pushed from the Access Control Service.