Groups

The group identities view presents the scaffolds associated with manipulating the rXg internal credential database and integrated authentication mechanisms.

Policy enforcement on the rXg begins with groups. The rXg group objects ( IP groups , MAC groups and account groups ) may all be associated with a policy object. The policy object is then associated with any of the various end-user communication and control features of the rXg.

Devices may be directly authenticated by operator specified IP address and/or MAC address. This is accomplished by adding IP and MAC members to IP group and MAC group records. When the captive portal disabled, direct authentication through groups is required for policy enforcement.

All group objects have a priority field to to disambiguate the choice of a policy when an end-user or device is a member of more than one group. By default, IP groups have a lower priority than MAC groups which have a lower priority than account groups. This default is designed around the concept of creating a default policy via IP groups (typically portal enabled, no access to the WAN) with exceptions specified via MAC groups and account groups.

IP Groups

An entry in the IP groups scaffold defines a group object that contains IP blocks as members.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The priority field determines the effective group when an end-user or device is a member of more than one group. By default, IP groups have the lowest possible priority.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The addresses and static routes fields are easy ways to add an entire subnet to the IP group. For example, selecting an address configured with 192.168.5.1/24 is equivalent to entering 192.168.5.0/24 in the IPs sub form. Similarly, selecting a static route with a destination of 10.1.0.0/24 is equivalent to entering 10.1.0.0/24 in the IPs sub form.

The IPs sub form enables specification of IP ranges that are to be assigned to the IP group. To specify a single IP address as a member of a group, enter the IP address followed by a suffix of /32(e.g., 192.168.8.168/32).

The policy field associates this group object with a policy object. The policy object relates the group to objects that specify the configuration of the control and communication features of the rXg that determine the end-user experience.

In a typical scenario, each and every address range on the LAN of the rXg will be a member of an IP group. This is used to set the default policy for all devices on the rXg managed network. The default policy for IP groups typically incorporates a policy that specifies denial of all routing or redirection of all traffic to the portal.

Multiple IP groups are configured in scenarios when the rXg managed LAN has well understood IP boundaries with differing policy enforcement requirements. For example, location-based services that require displaying a different captive portal is one common reason why numerous IP groups are created. Deploying a DMZ for servers which require direct access to the WAN is another common scenario where multiple IP groups are needed.

MAC Groups

An entry in the MAC groups scaffold defines a group object that contains MAC addresses as members.

The priority field determines the effective group when an end-user or device is a member of more than one group. By default, MAC groups have a priority of 2, placing them higher than the default priority of IP groups.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The MACs sub form enables specification of MAC addresses that are to be assigned to the MAC group. MAC addresses must be specified in hexadecimal in any of the typical MAC address formats. MACs will be scrubbed and normalized to a colon-separated tuple format (e.g., 01:23:45:67:89:ab) before being stored in the database.

MAC groups are typically used to identify specific end-user devices that require a different policy from the default policy for the IP range specified by an IP group. MAC groups are also the only way that headless and browser-less devices may be identified.

For example, MAC groups are typically used to identify infrastructure equipment (switches, access points, power controllers, etc.) and handheld devices used by administrators. The higher default priority is typically used to enable access to the WAN as the IP groups are usually set to deny all access.

Account Groups

An entry in the account groups scaffold defines a group object that contains accounts members.

The priority field determines the effective group when an end-user or device is a member of more than one group. By default, account groups have a priority of 3, placing them higher than the default priority of both IP groups and MAC groups.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

By checking the box next to a usage plans , end-users will be automatically added to this account group when they select the specified usage plan. This is the primary mechanism that enables zero operator intervention self-provisioning of end-users. By associating plans with groups and groups with policies, end-users are delivered operator specified RGN offerings in a completely automated fashion.

Unlike other group objects, membership in a account group is controlled exclusively within the account record. This is because production rXg units will have hundreds of accounts in a account group making a membership UI in the account group to be ineffective.

account groups are typically the most specific (and hence by default have the highest priority) identification mechanism. An end-user may be a member of more than one account group so long as none of the account groups have the same priority. This is a scenario which is typical of an end-user who has selected a plan that enables a basic level of access but then later upgrades to a different plan that has enhanced access. Careful configuration of the group priority is a critical facet of delivering a deterministic and reliable RGN product to the end-user population.