Accounts

Accounts and Tokens

The accounts identities view presents the scaffolds associated with manipulating the rXg integrated credentials database.

Identifying devices and end-users is the first step in applying policy enforcement. The rXg integrated credential database consists of several modules that are used to identify and authenticate devices and end-users via the captive portal.

In most cases, end-users will be authenticated through the captive portal web application via account (identified by a username and password combination) or a token (identified by an alphanumeric code). Both accounts and tokens become members of account groups.

Both accounts and tokens are authentication mechanisms that work with the captive portal web application. When the captive portal is enabled, the end-user must provide credentials in order to gain access to the WAN. Providing a valid login / password tuple or a valid code for a token are two of the kinds of credentials that the portal will accept.

Each account and token record contains fields that store usage minutes, transfer quotas, expiration dates and other usage restrictions. In a typical scenario, the usage restrictions in the account record are initialized by the usage plan that the end-user has selected through the captive portal web application. The usage restrictions in a token record are setup when a batch of tokens is created.

A device or end-user may be a member of more than one group. For example, a transient end-user arrives at a hotspot and connects to an rXg controlled wireless network. The end-user's laptop acquires the IP address 192.168.5.42 and attempts to surf to the Internet. A WLAN IP group is configured on the rXg with a CIDR member of 192.168.5.0/24 and a policy that has the captive portal enabled. The end-user is redirected to the captive portal then provides a token to access the Internet. The end-user is now part of a account group that the token is associated with. Thus the end-user is now part of both an IP group and a account group.

Accounts

Each record in the accounts scaffold is an end-user account that can be used for authentication via the captive portal web application. Accounts are typically created by the end-user during the captive portal sign-up process. Alternatively, the operator may choose to manually create records using the scaffold.

The group field configures group membership for this account record. A account may be a member of only one account group at a time.

The login field determines the username that the end-user will supply to the captive portal web application as part of the credential for authentication.

The password field determines the second part of the credential tuple that is supplied by the end-user to authenticate via the captive portal. To change the password, the password and password confirmation must match.

The first name and last name fields are for informational and display purposes only.

The email and email2 fields configure the destination(s) for email notifications. The email2 field is optional.

The MAC field is the last recorded MAC address of the end-user. This field is used to identify the end-user if automatic login is enabled.

Automatic login enables an operator to use the captive portal for end-user self-signup and zero intervention provisioning while retaining the appearance of unfettered WAN access. If this box is checked, the next time the same MAC address and/or browser cookie is seen on the LAN, it will automatically be logged in without a forced browser redirect.

The lock checkbox enables MAC locking. When a MAC address is locked, the device associated with the MAC address may only be used to purchase usage plans when the end-user operating the device logs in with the corresponding account. This mechanism is used in fixed wireless broadband environments to prevent end-users from avoiding disconnect, reconnect and late fees by creating a new account. This feature is incompatible with high transient (hotspot, hotzone, etc.) environments where the portal automatically creates a new account for each transaction.

The status allows the operator to manually disable this account without changing any of the usage restrictions. This is useful for a temporary administrative override (e.g., disabling an abusive end-user until their behavior is discontinued).

The time field determines the amount of online time that this account has left. This field is typically populated when the end-user selects a plan. If the end-user should have not have any online time limits (e.g., if the end-user is manually billed), check the box next to the unlimited heading.

The download quota and upload quota fields determine the amount of data that the end-user can transfer between the LAN and the WAN. These fields are typically populated when the end-user selects a usage plan. If the end-user should not have any transfer restrictions (e.g., if the end-user has purchased a premium unmetered offering), check the appropriate boxes next to the unlimited fields.

The expiration field configures a date and time when the end-user will no longer be able to connect to the WAN. This field is typically populated when the end-user selects a usage plan. The rXg automatically ensures that the maximum allowable online time never exceeds the configured expiration. When the current time is beyond that of the configured expiration , the account will no longer be able to login.

The usage plan field displays the last usage plan that the end-user selected. This field also controls the recurring billing mechanism. This account will take part in a recurring billing schedule if the usage plan chosen here has recurring billing enabled.

The bill at field stores the next date and time at which the end-user will be billed. This field is only used when the end-user is associated with a usage plan that has recurring billing enabled. This field is automatically populated based on the interval field in the usage plan.

Checking the apply plan checkbox provisions the selected usage plan to the account as if the end-user had purchased the plan through the captive portal application. This overrides any usage options or group selections entered manually. The end-user is not billed.

Checking the charge and apply plan checkbox tries to bill the end-user for the selected usage plan by charging her active payment method. If the charge is successful, the usage plan is provisioned to the account as if she had purchased the plan through the captive portal application. This overrides any usage options or group selections entered manually.

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.

Account Journal

Each user record has an accounting journal associated with it that may be displayed by clicking the Journal link.

The account journal keeps a record of all events that affect the end-user's balance. Such events include the selection of a usage plan, the redemption of a coupon, the charging of a credit card through a merchant, etc. The operator may also manually add entries to the journal through the nested scaffold.

Tokens

Each record in the tokens scaffold is a credential that can be used for authentication via the captive portal web application. Tokens can be thought of as "anonymous users." They have all of the usage restriction features present in accounts and are capable of being associated an account group in a similar fashion.

Tokens are typically created in batches by the administrator through the administrative console. The administrator can then export the tokens and integrate them into a wide variety of end-user delivery mechanisms (e.g., doing a mail merge into a word processor and printing onto labels or perforated business card printing sheets).

Alternatively, the operator may choose to use the captive portal web application to automatically create tokens. This mechanism is typically used to implement a simple "one-click free access" RGN offering. Since the end-users are authenticated as tokens , full policy management and service level differentiation is possible. This is useful if the operator wishes to have a time and transfer limited advertising supported offering side-by-side with a paid offering that has a superior experience.

The copies field enables the operator to generate multiple tokens at once. This is to facilitate generation of tokens in batches which is the typical usage scenario. This field is only accessible during the creation of tokens.

The characters and length fields control the complexity of the credential codes for the tokens being generated. An operator may choose from several different character classes and lengths. For security reasons, it is recommended that simpler character classes be used with longer lengths. For example, it is recommended that the "numbers only" class is always used with the length of 16. This field is only accessible during the creation of tokens.

The prefix and suffix fields allow the operator to specify a hardcoded prefix and suffix for the codes that are being generated. The specified prefix and suffix will be the same for all generated codes. This feature allows the operator to generate codes whose purpose that may be easily identified (e.g., 1DAY 1G2H 3J4K). The prefix and suffix may only contain simple characters (letters and numbers) and must be 4 characters long or completely omitted.

The batch field is an automatically assigned value to each set of tokens generated by the administrator. The purpose of the field is to allow the administrator to quickly locate all of the tokens that were generated at the same time. This field is not editable and is for informational purposes only, it does not affect policy management or any other end-user experience related functionality.

The group field configures group membership for this token record. A token may be a member of only one account group at a time.

The time field determines the amount of online time that this account has left. This field is typically populated when the end-user selects a usage plan. If the end-user should not have any online time limits (e.g., if the end-user is manually billed), check the box next to the unlimited heading.

If the automatic login box is checked, the next time the same MAC address and/or browser cookie is seen on the LAN, it will automatically be logged in without a forced browser redirect.

The MAC field is the last recorded MAC address of the end-user.

The relative lifetime field configures the token's usage expiration time to be dynamically set relative to the first login event, which supersedes the configured expiration field or no expiration field. This enables creating a batch of tokens with a finite and absolute shelf-life that also changes for an individual token upon its first use. This field is optional, and if left out, only the expiration field or no expiration field affect the token's lifetime.

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.

Sub-Accounts

Enabling Sub-Accounts allows the creation of child accounts that share the same pool of resources and enforcements as the primary account. For example, if the primary account has a time or quota plan, child accounts will draw down on the remaining balance of that plan. Enable Sub-Accounts within the account record by indicating the number of Sub-Accounts allowed. Once enabled, add Sub-Accounts through the end-user portal or the admin UI.

Enable Sub-Accounts by setting the number allowed within the account record.

Sub-Accounts can also be added as a plan addon. Browse to Billing >> Plans >> Plan Addons.

Creating a Sub-Account from the End-User portal

Once logged into the end-user portal, select Profile.

Scroll to the bottom of the screen, and select Create Sub-Account.

Fill in the Sub-Account details and then select Create.

Creating a Sub-Account from the Admin UI

Browse to Identities >> Accounts and select Sub-Accounts.

Select Create New.

Complete the fields indicated below. All other information will be populated based on the primary account configuration.

Devices

An entry in the devices scaffold defines a device by MAC address and associates it to an account.

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 MAC field should be populated with the device MAC address in the format xx:xx:xx:xx:xx:xx.

In the Account field you will select the account in which the device should be associated.

Static IP

An entry in the Static IP field creates a one-to-one mapping between an IP address within a span associated with an uplink and a device on the LAN. This feature is typically used to give public access to a resource that is configured on a private IP address such as a web server.

The Public IP field specifies the IP address within a span of addresses associated with an uplink that will be translated to the Device.

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.

Checking the BiNAT checkbox will give public access to the device as long as the associated account has a Max BiNAT value of 1 or greater and there is an available address in the BiNAT pool. This would typically be used for devices such as a web server or a gaming device which requires open incoming firewall ports for proper operation.

Checking the Hide from portal checkbox will hide the device from the manage devices view in the captive portal.

Fixed Hosts

An entry in the Fixed Hosts field reserves an IP address for a particular device. When a device with the MAC address specified in this record requests network configuration via DHCP, the specified IP address is offered. This mechanism is often used as an alternative to manually assigning static IP addresses to devices.

The IP field contains the IP address to be reserved for this device. It is critically important that the reserved IP be outside of any pools specified in the pools scaffold.

The MAC field contains the MAC address of the device that this reservation is being held for.

The hostname field is an optional parameter that, if specified, will cause the DHCP server to deliver a client identifier to the device via a DHCP option.

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 option group links this reservation with a set of DHCP options that control additional information that may be delivered to the device beyond IP address, hostname, subnet mask and gateway. For example, an option group may be used to specify alternative DNS servers for the device specified in this reservation.