Showing posts with label radiator as a service. Show all posts
Showing posts with label radiator as a service. Show all posts

Monday, June 6, 2016

Make your Radiator log data searchable

This is the first part of blog series that helps you to use log data that Radiator generates. Jump to second part.


Radiator exports AAA (authentication, authorisation, accounting) data to various formats. You can process the log data further by other log collection systems, such as Splunk and Elasticsearch. In this article, we briefly describe how to export data in JSON format. The common use case is to record the metrics that best describe your environment, for example, authentication, and authorisation messages.

The image below shows you an example of visualised Radiator worker statistics. The graphics were created with Grafana. Click the image for a larger view.





Adding a new field
With Radiator, it is possible to export log data in JSON format (for more information, see JSON.org). Basically, JSON is a set of name-value pairs. The values can also be ordered lists and it is possible to nest lists inside other lists. This makes it possible to express complex data structures in an universal manner with JSON.

Usually, the hardest part in modifying configuration is to figure out how to synchronise modifications everywhere, especially if the logs are centrally collected and parsed. For example, if Client-Identifier or some other RADIUS attribute is added to a log message when authentication fails, you have to ensure the log parser engine understands the new field.

This is an example of AuthLog FILE, which has date, username, and result.

Wed May 18 15:48:44 2016:mikem:FAIL

If you add a new field, the log entry looks like this:

Wed May 18 15:48:44 2016:mikem:client-1:FAIL

Here is the same information as a default JSON message without the new field:

{"timestamp":"2016-05-18T15:48:44Z","result":"reject","source_host":"osc-dev-3","username":"mikem","type":"authentication"}

Here is the JSON message with the new field: {"timestamp":"2016-05-18T15:48:44Z","result":"reject","source_host":"osc-dev-3","username":"mikem","type":"authentication", “client”:”client-1”}
With JSON, it is easy to add the new field to Radiator log message. Usually, there is no need to modify the parser configuration since the fields are just a group of name-value pairs and not fixed together in any way.

Configuring Radiator

The configuration process is straightforward: add Log <FILE, SYSLOG, ...> clause and use it in the same way as existing ones to your Radiator config and you are done. With Radiator, you can customise your own LogFormatHook and add, remove, or modify the fields. This is how Radiator extends the log usage possibilities even further.

Note: The following configuration example needs Radiator 4.16 with latest patches. You must have JSON module installed. JSON::XS module is recommended (see https://metacpan.org/pod/JSON and https://metacpan.org/pod/JSON::XS).


Configuration example: JSON output to radius.cfg (source goodies/logformat.cfg):



# This logger logs events in JSON format. It requires the Perl JSON
# module. Note the specific requirement for loading the logger module.
<Log FILE>
       Identifier mylogger-json
       Trace 4
       Filename %L/logfile.json
       LogFormatHook sub { Radius::LogFormat::format_log_json(@_); }
</Log>


# This auth logger logs both successes and failures to a JSON file.
<AuthLog FILE>
       Identifier myauthlogger-json
       Filename %L/authlog.json
       LogFormatHook sub { Radius::LogFormat::format_authlog_json(@_); }
       LogSuccess 1
       LogFailure 1
</AuthLog>


# This is the Handler-clause.
<Handler>
   <AuthBy FILE>
       Filename %D/users
   </AuthBy>
   AuthLog myauthlogger-json
   # Log accounting messages in JSON format.
   AcctLogFileName %L/acctlog.json
   AcctLogFileFormatHook sub { Radius::LogFormat::format_acctlog_json(@_); }
</Handler>



In this example configuration, all log data is saved into a single file. This may cause problems in the real configuration because of increasing log data file size. You can avoid this by using log rotation tools, for example, logrotate in Unix-based systems. Rotating log files can safely be done without restarting Radiator. Radiator also supports the special characters in the file names.

Do you want to know more?
Your JSON files are now ready, the next step is to use them efficiently. In the next part of the series, we will introduce the more detailed use cases, which will help you get the most out of Radiator logging.

Monday, December 7, 2015

Powered by Radiator: Verkkovieras.fi for simple and secure federated Wi-Fi authentication

Powered by Radiator: Verkkovieras.fi



This blog post is first one of the Powered by Radiator articles, where we and our agents or partners introduce products, services or solutions they have made using Radiator. If you have a product, service or solution you would like to introduce, please contact sales (a.t.) radiatorsoftware.com for more information.

This time it's Arch Red's turn to introduce their cloud based authentication service -- verkkovieras.fi , Powered by Radiator.

verkkovieras.fi for simple and secure federated Wi-Fi authentication

David Bleasdale: security
Verkkovieras is a Finnish word, which means network guest. Verkkovieras.fi is Arch Red's cloud authentication service for organisation’s employee and guest network access control. The service also supports authentication roaming federations such as eduroam and roam.fi making the service an easy way to deploy and serve federated network access for employees, guests and partners.

We know that maintaining user databases and RADIUS servers for employee and guest access can be difficult, especially when there’s additional complexity such as federated roaming. With verkkovieras.fi we focused in building a service, which is easy to deploy and easy to use. We thought, designed, thought some more and improved our design to be as clean and clear as possible.

Easily deployed in any Wi-Fi network

To deploy verkkovieras.fi authenticaton service you only need RADIUS capable authenticated devices such as for example almost all Wi-Fi controllers and access points. The authenticating device, usually the Wi-Fi controller, needs to be able to communicate with our cloud based servers in Internet and that’s it -- only our server details and Wi-Fi networks need to be configured in the controller.

User account registration as easy as email


Employees manage their user accounts themselves by requesting them from WWW page and after simple email-www page confirmation they activate their email address based user account. Account’s username is their email address and password is randomly generated string. We wanted to make sure that the network password is secure and on the other hand create a separate user account for network access. This was to keep more important or sensitive passwords such as Active Directory or other service passwords separate and safe. This way the employee cannot undermine the security by changing password to less secure or more sensitive one.

Federated roaming with a flick of a switch


Roaming federations and federated user access is even simpler, just select which federations and to activate or deactivate it. Your employees or visiting roaming guests are then able to roam free within federations and networks with same profiles they use for network access in your home network.

Easy guest user access or traditional vouchers -- you choose

Howard Lake: Sainsburys Active Kids vouchers
For guest user access there are two options, a simple time-limited guest user account for automated access and possibility to create and print more traditional time-limited guest user accounts before hand. Automated access means that the user account can be integrated for example with WWW page based authentication to provide guest short Internet access with just a click of a button on the authentication page. The traditional guest user accounts can be used like vouchers, the username and password must be entered on the authentication page or system dialog to get the access to network.

All this as a cloud service, ready to be deployed today

verkkovieras.fi architecture

We packaged all this in a redundant Amazon cloud based service distributed across two geographical regions, where we handle the difficult details such as scaling, server certificates, EAP methods (EAP-PEAP, EAP-TTLS, EAP-PWD) leaving you as a customer time to focus to your business and core functions.

If you are interested, contact our sales team: sales (a.t.) archred.com for more details.