Thursday, November 15, 2018

Transition from ISP to LTE Carrier - with the help of Radiator products

Recently, we have seen a transition with many operators evolving from traditional Internet Service Providers (ISPs) to LTE carriers who provide fixed line, WiFi, and mobile connections. At the same time, their needs for authentication, authorization, and accounting (AAA) become more complex. As an example, on top of a standard RADIUS AAA infrastructure, these carriers may need Diameter interfaces and a 3GPP AAA server.

For Radiator customers, we have made this transition as easy as possible - and with the flexibility of Radiator, it is easy to bring it to different infrastructures as a new solution.

How Radiator can help

As many of our customers have evolved from ISPs to LTE Carriers, their needs for different features have evolved at the same time. For these needs, we have developed Radiator Carrier class product line. In order to ensure cost-effective solutions, we offer a modular approach where you can purchase only the components that you will need in your project.

For example, many of our customers have used Radiator for both fixed and WiFi access for years. When they need to enable VoWiFi calling features, they can just add Radiator SIM Module to their network, and in this way, enable different EAP-SIM / EAP-AKA / EAP-AKA’ authentication methods and have a fully featured 3GPP AAA Server in their network as well.

Another example is our Radiator GBA/BSF Module that provides easy authentication for VoLTE supplementary services. This way you can ensure that VoLTE supplementary services (call forwarding, knocking, call barring) are in use in your LTE infrastructure without resorting to 2G/3G infrastructure.

Would you like to know more?

If you are interested in Radiator features such as Diameter interfaces, online charging, VoWiFi, or 3GPP AAA Server, you can find more details in our website or contact our sales team at sales@radiatorsoftware.com. We will be happy to help you with your project.

Monday, October 15, 2018

Improved support for Hotspots and subscription quotas!


New Radiator release version 4.22 will introduce an improved support for Hotspot functionality, including differentiated services and prepaid/postpaid quotas.

The release will include following new and updated modules which can be used to implement various service provider use cases:

A new module class called 'ServiceDatabase' which handles differentiated services and subscriptions:

  - <ServiceDatabase INTERNAL> stores service definitions and subscription data within in-memory.

  - <ServiceDatabase SQL> stores service definitions and subscription data within SQL database.

Existing <SessionDatabase INTERNAL> and <SessionDatabase SQL> modules have been updated to work seamlessly with new <ServiceDatabase> modules for RADIUS accounting based quota control.

A new generic <AuthBy HOTSPOT> module which combines <ServiceDatabase>, <SessionDatabase>, an authenticating <AuthBy>, and possible <AuthBy DYNAUTH> (RADIUS Dynamic Authorization) for sending CoA/DM e.g. after a successful authentication or when a quota has been depleted, into a working solution which can be used with captive portals (for example MikroTik) and network access controllers supporting RADIUS. Beside Hotspot use-case, the same solution can also be used to implement a quota control for fixed-line access or cellular APN.

A new <AuthBy HOTSPOTFIDELIO> module based on <AuthBy HOTSPOT> which uses Radiator Fidelio/Opera PMS integration for authenticating and billing guests. Note that <AuthBy HOTSPOTFIDELIO> obsoletes previous <AuthBy FIDELIOHOTSPOT> module.

Implementing a guest network access with Radiator using Fidelio/Opera PMS integration.

Examples

To demonstrate how new <AuthBy HOTSPOT> and <AuthBy HOTSPOTFIDELIO> combine these new features, see a following configuration examples of new Radiator Hotspot functionality:

Example 1. Using in-memory <ServiceDatabase INTERNAL> and <SessionDatabase INTERNAL> with <AuthBy HOTSPOT> and <AuthBy FILE>

# See goodies/hotspot.cfg for a full example config

...

### Service and Session databases ###

# ServiceDatabase INTERNAL for Services and Subscriptions
<ServiceDatabase INTERNAL>
  Identifier ServiceDatabase-INTERNAL

  # Service definitions
  # Service 1: free, 1 hour, 50M data, no policers  Service name:free price:0 prepaidTime:1h prepaidQuota:50M replyItems:"OSC-AVPAIR=Test1,OSC-AVPAIR=Test2" 
  # Service 2: price 1000 cents, 1 day, 100M data, 100M/10M policers
  Service name:premium price:1000 prepaidTime:24h prepaidQuota:100M prepaidUpRate:10M prepaidDownRate:100M

  # Service 3: price 2000 cents, 1 day, 1G data, 100M/100M policers
  Service name:gold price:2000 prepaidTime:24h prepaidQuota:1G prepaidUpRate:100M prepaidDownRate:100M
</ServiceDatabase>

# SessionDatabase INTERNAL for Sessions
<SessionDatabase INTERNAL>
  Identifier SessionDatabase-INTERNAL
</SessionDatabase>

...

### AuthBy Modules ###

# Authenticate Hotspot users with AuthBy FILE
<AuthBy FILE>
  Identifier AuthBy-FILE

  Filename %D/users
  NoDefault
</AuthBy>

<AuthBy HOTSPOT>
  Identifier AuthBy-HOTSPOT

  # Authenticate Hotspot users with AuthBy FILE
  AuthBy AuthBy-FILE

  # Use ServiceDatabase-INTERNAL for services and subscriptions
  ServiceDatabase ServiceDatabase-INTERNAL

  # Lookup a subscription based on username (%1) and Calling-Station-Id MAC address
  SubscriptionId %1-%{Calling-Station-Id}

  # Use SessionDatabase-INTERNAL for sessions
  SessionDatabase SessionDatabase-INTERNAL

  # Lookup a session based on username (%1) and Calling-Station-Id MAC address
  SessionId %1-%{Calling-Station-Id}
  # Empty SessionAttribute
  SessionAttribute

  # If RADIUS accounting will be used for quota monitoring,
  # create a new session upon a successful authentication
  #PreProvisionSession

  # Alternatively, reply with remaining time quota
  #UsageMonitoring
  # and remaining data quota
  #ReplyWithDataQuota
  #DataLimitAttribute Mikrotik-Total-Limit
  #DataLimitGigawordsAttribute Mikrotik-Total-Limit-Gigawords

  # Use service 'free' as a default service
  DefaultService free
  ServiceAttribute OSC-Service-Identifier
  #ServiceAttributePrefix Service=
</AuthBy>

# AuthBy DyNAUTH for creating DM/CoA requests for exceeded sessions
<AuthBy DYNAUTH>
  Identifier AuthBy-DYNAUTH

  SessionDatabase SessionDatabase-INTERNAL

  # Send Change-Filter-Request (CoA) to NAS UDP port 3799
  #RequestType Change-Filter-Request
  # Send Disconnect-Request (DM) to NAS UDP port 3799
  RequestType Disconnect-Request
  DynAuthPort 3799

  # Do not try to lookup a session again
  NoSessionMapping

  # Send CoA/DM to IP address within NAS-IP-Address RADIUS attribute
  NasAddrAttribute NAS-IP-Address

  # Identify user session by User-Name, Acct-Session-Id and NAS-Port
  DynAuthAttribute User-Name
  DynAuthAttribute Acct-Session-Id
  DynAuthAttribute NAS-Port
</AuthBy>

# AuthBy RADIUSBYATTR for sending out DM/CoA requests for exceeded sessions
<AuthBy RADIUSBYATTR>
  Identifier AuthBy-RADIUSBYATTR
</AuthBy>

### Request Handlers ###

# Accounting Handler
<Handler Request-Type=Accounting-Request>
  Identifier Accounting-Handler

  # Acknowledge Accounting-Request immediately
  AccountingAccepted

  AuthByPolicy ContinueUntilRejectOrChallenge

  # Handle RADIUS accounting
  AuthBy AuthBy-HOTSPOT
  # Send DM/CoA request for exceeded session
  AuthBy AuthBy-DYNAUTH
</Handler>

# Outgoing DM/CoA Handler
<Handler DynAuthRequest=1>
  Identifier Handler-DYNAUTH

  AuthBy AuthBy-RADIUSBYATTR
</Handler>

# Default Handler
<Handler>
  Identifier Default-Handler

  # Handle RADIUS authentication
  AuthBy AuthBy-HOTSPOT

  RejectHasReason
</Handler>
Example 2. Using <ServiceDatabase SQL> and <SessionDatabase SQL> with <AuthBy HOTSPOTFIDELIO>

# See goodies/hotspot-fidelio.cfg for a full example config
#
# Requires SQL definitions from goodies/hotspot.sql and goodies/hotspot-fidelio.sql
# See goodies/README.hotspot-fidelio for more information
#

...

### Service and Session databases ###

# ServiceDatabase SQL for Services and Subscriptions
<ServiceDatabase SQL>
  Identifier ServiceDatabase-SQL

  # Details of how to contact the service and subscription database
  DBSource   dbi:SQLite:dbname=hotspot.db
  #DBSource   dbi:mysql:hotspot
  DBUsername mikem
  DBAuth     fred
</ServiceDatabase>

# SessionDatabase SQL for Sessions
<SessionDatabase SQL>
  Identifier SessionDatabase-SQL

  # Details of how to contact the session database
  DBSource   dbi:SQLite:dbname=hotspot.db
  #DBSource   dbi:mysql:hotspot
  DBUsername mikem
  DBAuth     fred

  # Modified SQL queries/statements for a new session database schema (goodies/hotspot.sql)
  CountQuery SELECT nas_id, nas_port, id, ipv4 FROM SESSIONS WHERE user_name=%0
  ClearNasQuery DELETE FROM SESSIONS WHERE nas_id='%0'
  AddQuery
  DeleteQuery
  ClearNasSessionQuery
</SessionDatabase>

...

### AuthBy Modules ###

<AuthBy HOTSPOTFIDELIO>
  Identifier AuthBy-HOTSPOTFIDELIO

  # Use ServiceDatabase-SQL for services and subscriptions
  ServiceDatabase ServiceDatabase-SQL
  # Lookup a subscription based on username (%1), Fidelio PMS    Guest Number (%2) and Calling-Station-Id MAC address
  SubscriptionId %1-%2-%{Calling-Station-Id}

  # Use SessionDatabase-SQL for sessions
  SessionDatabase SessionDatabase-SQL
  # Lookup a session based on username (%1), Class (%3) and    Calling-Station-Id MAC address
  SessionId %1-%3-%{Calling-Station-Id}
  # Empty SessionAttribute
  SessionAttribute

  # If RADIUS accounting will be used for quota monitoring,
  # create a new session upon a successful authentication
  PreProvisionSession

  # Alternatively, reply with remaining time quota
  #UsageMonitoring
  # and remaining data quota
  #ReplyWithDataQuota
  #DataLimitAttribute Mikrotik-Total-Limit
  #DataLimitGigawordsAttribute Mikrotik-Total-Limit-Gigawords

  # Details of how to contact the Fidelio posting database
  # See AuthSQL for details
  DBSource   dbi:SQLite:dbname=hotspot.db
  #DBSource   dbi:mysql:hotspot
  DBUsername mikem
  DBAuth     fred

  # Fidelio PMS interface
  Protocol tcp
  Port 5010
  Host localhost

  # Validity time in seconds of plan purchased
  # Default 86400 seconds (1 day)
  BlockDuration 86400

  # Default price for plan
  # Price in database overrides this value
  BlockPrice 900

  # ServiceAttribute defines the RADIUS attribute that is
  # used select the desired prepaid service or plan. On
  # Mikrotik login page you can create a menu as shown
  # below to display the different purchase
  # options. Note: "name=radius0-9048" is OSC-AVPAIR.
  #  <tr><td>Service:</td><td>
  #  <select name="radius0-9048">
  #  <option value="Mikrotik-Service=free">best effort (free)  </option>
  #  <option value="Mikrotik-Service=premium">premium ($5)</option>
  #  </select></td></tr>
  ServiceAttribute OSC-AVPAIR

  # If it is possible that there are multiple instances
  # of the ServiceAttribute in the request, you can use
  # an optional prefix to choose the correct instance.
  ServiceAttributePrefix Mikrotik-Service=

  # By default upgrade or renewal of the current plan is
  # automatically processed and charged. With this option
  # you can ask the guest to confirm the charge first.
  # With Mikrotik you can show the message to the guest
  # by including
  #  $(if error)<br /><div style="color: #FF8080; font-size: 14px">$(error)</div><br>$(endif)
  # on the Mikrotik login page
  #ConfirmUpgradeOrRenew
  #ConfirmationMessage "You are going to upgrade or renew your plan, please login again to confirm the charge"

  # This one uses the last part of the guest name (case sensitive) as the
  # password. This is usually the guest surname
  UserPasswordHook sub {my @n = split(/\s/, $_[1]->{'GN'}); return $n[$#n];}

  # Need this to ensure the Guest Number is included in the postings
  # Required when there are multiple guests per room
  #PostingExtraFields G#,%4

  # You can add extra attributes in the reply here if you wish
  # to set limits or controls over access
  #AddToReply Mikrotik-Recv-Limit-Gigawords=1,Mikrotik-Xmit-Limit-Gigawords=1
</AuthBy>

# AuthBy DyNAUTH for creating DM/CoA requests for exceeded sessions
<AuthBy DYNAUTH>
  Identifier AuthBy-DYNAUTH

  SessionDatabase SessionDatabase-SQL

  # Send Change-Filter-Request (CoA) to NAS UDP port 1700
  #RequestType Change-Filter-Request
  # Send Disconnect-Request (DM) to NAS UDP port 1700
  RequestType Disconnect-Request
  DynAuthPort 1700

  # Do not try to lookup a session again
  NoSessionMapping

  # Send CoA/DM to IP address within NAS-IP-Address RADIUS attribute
  NasAddrAttribute NAS-IP-Address

  # Identify user session by User-Name, Acct-Session-Id and NAS-Port
  DynAuthAttribute User-Name
  DynAuthAttribute Acct-Session-Id
  DynAuthAttribute NAS-Port
</AuthBy>

# AuthBy RADIUSBYATTR for sending out DM/CoA requests for exceeded sessions
<AuthBy RADIUSBYATTR>
  Identifier AuthBy-RADIUSBYATTR
</AuthBy>

### Request Handlers ###

# Accounting Handler
<Handler Request-Type=Accounting-Request>
  Identifier Accounting-Handler

  # Acknowledge Accounting-Request immediately
  AccountingAccepted

  AuthByPolicy ContinueUntilRejectOrChallenge

  # Handle RADIUS accounting
  AuthBy AuthBy-HOTSPOTFIDELIO
  # Send DM/CoA request for exceeded session
  AuthBy AuthBy-DYNAUTH
</Handler>

# Outgoing DM/CoA Handler
<Handler DynAuthRequest=1>
  Identifier Handler-DYNAUTH

  AuthBy AuthBy-RADIUSBYATTR
</Handler>

# Default Handler
<Handler>
  Identifier Default-Handler

  # Use SessionDatabase-SQL
  SessionDatabase SessionDatabase-SQL
  # Don't try to delete a session before authentication
  SessionDatabaseOptions NoDeleteBeforeAuthentication

  # Handle RADIUS authentication
  AuthBy AuthBy-HOTSPOTFIDELIO

  RejectHasReason
</Handler>

Tuesday, September 18, 2018

Radiator as a Cisco ACS replacement

We have been contacted by customers looking for a replacement for Cisco ACS (Secure Access Control System) because it is near of its end of support. Radiator AAA Server Software is a fully featured and cost-effective solution that is known in the market as the “Swiss Army of AAA Servers for RADIUS, Diameter and TACACS+”.

To assist with migration, we are also selling consulting services. As we have had a wide range of customers with different needs migrating to Radiator, we can easily tailor a cost-effective consulting package for your needs. Because of our experience in similar projects, Radiator configuration can be adjusted to new environments without any extra hassle.

At the same time, Radiator is actively developed and it runs with variety of platforms, including Linux, Windows and others. You can be sure that you will have a supported AAA solution that is always kept up to date. Radiator has at least two releases per year, with interim patches made available for those who require the latest updates. Radiator is actively used by thousands of companies and organisations in over 180 countries.

Other key features of Radiator include:

  • Supports authentication by over 60 different types of methods
  • Interoperates with a huge range of devices, databases, billing packages, and tokens
  • Includes RadSec - secure, reliable RADIUS proxying
  • Includes Diameter - the RADIUS successor protocol used already by mobile operators
  • Includes TACACS+ - for infrastructure management

Would you like to know more?

With Radiator, you get direct professional technical support for configuration, for deployment, and for development. We have consultation and support packages ranging from limited email support to 24x7 telephone support, provided by Radiator experts. Additionally, Radiator Software and its partner companies provide installation and consultation support whenever needed. If you would like to know more about Radiator, licensing options, and support, please contact our team at info@radiatorsoftware.com

Thursday, September 6, 2018

Radiator GBA/BSF Module: Seamless authentication to VoLTE Supplementary services

VoLTE (Voice over LTE) calling is now being used by mobile carriers in their networks all over the world.

With VoLTE calling, there is no dependency on the legacy circuit-switched voice network to be maintained, which has many benefits for the carrier infrastructure. As a part of this, the carrier network will need an easy way to authenticate also to VoLTE supplementary services, such as call forwarding, knocking and call barring.

For this need, we have created Radiator GBA/BSF Module on top of our Radiator. Radiator GBA/BSF Module makes authentication for VoLTE supplementary services easy by using General Bootstrapping Architecture (GBA). In addition to this GBA enables also extending SIM authentication to any operator WWW services. In addition, SIM authentication itself has authentication federation support, which can be used to produce services across virtual and other operators.

Our product, Radiator GBA/BSF Support Module works as an authentication proxy between the end-user UE and HSS. It authenticates user requests, and also separates the authentication procedure and the Application Specific server (AS) specific application logic to different logical entities.

Radiator GBA/BSF Architecture


Main technical product features

Radiator GBA/BSF Module is already being used in live networks in multiple countries. The main technical features include:
  • Authenticating LTE subscribers for VoLTE supplementary services such as multimedia telephony service (MMTel) and multimedia telephony application server (MTAS)
  • BSF server (Ub interface)  
  • Authenticating Proxy (NAF/AP, Ut/Ua interface)
  • Interoperable with all major EPC vendors (Nokia, Ericsson, Huawei)
  • Interoperable with all major handset vendors (Samsung/Android, Apple, Nokia, Microsoft)
Would you like to know more?

Recently we introduced release 1.5.0 of Radiator GBA/BSF Module, with more focus on configuration examples and installation process - making it even easier product to implement in different carrier infrastructures. Our team at info@radiatorsoftware.com is happy to share with more info about our Radiator GBA/BSF Module product.

Friday, August 31, 2018

Radiator interacting with Microsoft Azure Multi-Factor Authentication

One Radiator’s key strengths is flexibility in different environments and authentication use cases.

Recently, a customer had a new case for authenticating network device administrators with Microsoft Azure Multi-Factor Authentication (MFA). The devices use TACACS+ and a solution was required to integrate with Azure MFA Radius. Thanks to the flexibility of Radiator, this can be done without any extra hassle.

When a user logs in, the device sends the username, static password and one-time passcode with TACACS+ authentication request to Radiator. Radiator processes the TACACS+ request and starts MFA authentication by first sending the password as RADIUS Access-Request. Azure MFA responds by replying with Access-Challenge prompting for the passcode. In turn, Radiator responds with password reminder (passcode of 6 numbers) to complete the authentication.

After this, authentication REPLY is delivered to the TACACS+ client and access is granted.



Would you like to know more?

In many recent customer cases, we have implemented various authentication solutions to interact with Microsoft Azure, including Multi-Factor Authentication use case mentioned above. We are happy to tell about this, and other use cases. If you should like to know more, please contact info@radiatorsoftware.com

Thursday, June 28, 2018

Radiator 4.21 now available

We are happy to announce that Radiator 4.21 has been released. This release covers a number of enhancements, bug fixes, and some new features. Here are some examples:
  • Fixed nested and cascaded AuthBy GROUPs that stopped working in Radiator 4.20.
  • Unified AuthBy HANDLER functionality and reverted some of its changes done in Radiator 4.20.
  • JSON authentication and accounting log now formats time as numeric type instead of string.
  • ServerTACACSPLUS connection handling had major updates.
For a detailed list of changes, visit the Radiator revision history page.

Tuesday, May 22, 2018

RAdmin version 1.16 is released

We are pleased to announce that RAdmin version 1.16 is now released. RAdmin is our tool for managing RADIUS users. With RAdmin you can check usage summaries, drill down to usage details and much more that is needed when managing your RADIUS traffic and users.

For this revision, we have implemented one key security fix, multiple bug fixes and and other enhancements. With 2-factor authentication, for example, support for using Yubikey 2-factor authentication tokens has now been updated. This release allows our customers to be sure that the software we provide is up-to-date and can be run on the current Windows, Linux and other platforms. 

For detailed list of enhancements, please see RAdmin revision history

New features

In addition of providing new bugfixes, version 1.16 also provides new enhancements for RAdmin UI. One example of these is providing a better way to listing usage of different users and sessions (see picture below). In addition other new usability and UI fixes are now available in order to provide a user-friendly way for managing network users.



Would you like to know more?

We are happy to provide RAdmin, like other Radiator products for evaluation.

RAdmin is designed especially for ISPs, CSPs and other companies or organizations that have the need to manage their RADIUS users. When contacting our sales team at info@radiatorsoftware.com we are happy to provide more info about use cases for Radiator and RAdmin.