Access policies, codes, more

There is a new version of CoovaAAA deployed! The highlights:

• Ability to create access policies defining time and data limits
• Share with users or entire realms based on a policy
• Generate a limited number of access codes based on a policy
• Support for CoovaChilli/Chillispot data limits based on a policy
• Stopping stale sessions when the NAC reboots
• Updated Facebook and new general use captive portal
• Bug fix concerning WPA-only option

Access Policies

Access policies define how access is to be provisioned. With this release, you can set the amount of access time and/or the data limits granted in a certain time frame. For instance, a policy might be for 2 hours of access, with a data cap of 10G, to be used within 24 hours. Additionally, the policy can be configured as recurring; for instance, a policy for 2 hours per any 24 hour period. Use policies to limit the access of individual users or entire realms you are sharing with. This includes Facebook users when using the Facebook captive portal.

This screenshot shows the look-and-feel of the Facebook embedded version and how users can individually be configured with an access policy. Similarly, in the next tab, Share with realms, you can configure entire realms with an access policy, specifying whether or not the limitation is for the entire realm (as in everybody has to share the same 2 hours) or if it should be per user (where a new Allowed User is added with the access policy).

Access Codes

In this release, you are able to create 10 access codes based on a access policy of your own. The limit is there while the feature is in beta. When you create an access code, you are basically creating your own usernames and passwords linked to your access policy and network (your own access points). Below, showing the standard look-and-feel, you can see the new Access tab in the manager application and some sample access codes.

Notice how access codes are considered under the realm “code” in the system. This is to not conflict with the default realm of users (i.e. the coova.org realm). Ultimately, when logging in to a network you need a username and password (“credentials”). For the access codes, this means the username, in theory, must be prefixed with this code realm according to RADIUS specification. That gets pretty technical. But, the new Facebook and general use captive portal in CoovaAAA makes it easy by providing a separate login dialog for both users and codes, as shown below. When logging in with an access code, the appropriate realm is automatically prepended.

Captive Portals

The Facebook captive portal was updated. Some adjustments were required as Facebook no longer enforces a login before viewing an application.

Which is nice - since now it is easier to put a login box for Coova-enabled user and access code logins for when the visitor is not a Facebook member.

With the same login box features of the Facebook application, there is now also a general use CoovaChilli captive portal login application. Similar to the embedded captive portal of CoovaChilli and CoovaAP, but this hosted version will be expanded and updated more frequently. It can be used with your own RADIUS back-end or take advantage of the features offered through CoovaAAA - including OpenID authentication (enabled as an option).

Learn more about this newest addition to the Coova hotspot development kit. I’m thinking of calling it this as everything Coova can not only be used as a whole, but also as bits and pieces. With more and more bits and pieces coming in the form of software, tools, resources, and services! If you find any problems or have suggestions, let us know in the forum.