Allowing Temporary Access via API

[nkarstedt]

Currently, we have a captive portal solution with a RADIUS service that sends both a session timeout and bandwidth caps with its accept messages.

The problem is, not all devices that may be on the guest network are compatible with a captive portal solution.

To make it easy for our end users, we intend to provide a page that allows users to add certain MAC addresses on their account that should be authenticated upon logging into their account (or on-demand via web interface)

End users may roam between networks within the organization and our networks must be combined networks for various reasons.

The intent was to leverage the SplashAuthorizationStatus method on the network their primary device was seen at and simply authorize all of the MAC addresses on their account, but that does not seem to be supported on a combined network.

We then thought Group Policies may work, but we want the authorization to be temporary and only triggered upon a successful authentication of an account (I.E. a cellphone login on the network, then allow access to a roku with the MAC address on file for 24 hours)

The only way we could currently accomplish this would be to have a service go through and reverse each group policy after its intended timeout.

Group Policies are intended for dynamic auth without RADIUS, but they do not seem to be a good replacement in their current state. We would very much like these features added to Group Policies & its API and/or the SplashAuthorizationStatus endpoint be upgraded to support combined networks.

[PhilipDAth]

What about having them browse directly to your splash page?

[nkarstedt]

We are allowing users to have an "account management" feature to allow them to authorize their incompatible devices. Devices like some rokus, gaming consoles, smart tvs, etc are not capable of using the splash page.

[PhilipDAth]

Tricky.

Does the Meraki system by chance send a logout/idle/disconnect event to you, that you could use to trigger the group policy removal?

I'm wondering if this might be easier to do using two SSIDs.  One with the splash page, and one using WPA2-Enterprise using MAC authentication.  Users connect to the splash page SSID, register their dumber devices, and those dumber devices connect to the WPA2-Enterprise SSID.

[nkarstedt]

Nope, RADIUS accounting is only sent for devices that were authenticated via RADIUS. No data is pushed from Meraki other than RADIUS accounting, (Except sensor polling data which would be useless).

Unfortunately, WPA-2E is not an option for us.

This is going to have to be handled via API as even RADIUS CoA messages are incapable of "pushing" an unrequested authorization and the devices have no method of requesting RADIUS authentication.

Further, access restriction is important as there are various methods of splash authorization including rotating passwords, payments, etc. which expire the user time in system configurable durations. Precision in access revocation would need to be down to the hour to be considered acceptable.

[PhilipDAth]

Forget WPA.  How about pure MAC based authentication on a second SSID?  The client doesn't need to do anything but attempt to connect for this to work.

You should get RADIUS start and stop messages this way.

[nkarstedt]

@PhilipDAth I hadn't even noticed that option! My only concern for this would be end user confusion. Having an open-access unsecured network with a somewhat similar SSID could result in an increase in support tickets.

I may actually have to convince stakeholders that WPA2-E is going to have to be the solution.

Although... do you know if MAC-based access control can be combined with Splash Page RADIUS in a logical manner or would a device need to pass MAC-auth in order to even view a splash page.

**Edit: Nope.. You'd think you could do an on-connect MAC Auth attempt and place the user in the walled garden if an Access-Deny is presented.

[PhilipDAth]

MAC based authentication is checked at WiFi connect time - before you even have an IP address.  So you wont be able to do walled garden, or anything else.  With MAC based authentication the network sets the username and password to the MAC of the device attempting to connect and sends that to the RADUS server.

Someone else might have a smarter idea, but given the restrictions, I can't think of any option part from using two SSIDs.

[nkarstedt]

Thanks for the ideas. Since other solutions will require Meraki development work, I think WPA2-E will likely be the cleanest solution for this application.

Leaving this thread running so we can hopefully get a fix for the SplashAuthorizationStatus endpoint.

[DexterLaBora]

Here is an idea..

I recently built a PoC for a similar use case. Ultimately, the goal is to allow IoT devices to join an SSID that is running a Splash Page.

Would this workflow work for you?

1. Client connects to ssid
2. No splash seen on iot device 
3. (custom admin portal)
   1. Run report of clients or manual entry
   2. Auth client via portal.. "Attach Group Policy with splash bypass option"
4. Reconnect client to network (to pull policy)

Here is an example of a similar application I wrote.

Demo (dev server): https://meraki-dashboard-pwa-admin.herokuapp.com/
Source Code (early dev work): https://github.com/dexterlabora/meraki-dashboard-pwa-admin

[nkarstedt]

Thanks for the reply. Unfortunately, that will not work for our use case as our end users get session timeouts. Group policies do not seem to allow for expirations.

Basically a user gets access to lets say 5 device connections on their account. When they first log in, they choose an option: 1 hour, 1 day, etc.

Our servers process and send RADIUS accepts that have a timeout that correlates with the amount of time they have remaining on their account (before they would have to log back in and purchase time).

Leveraging Group Policies would allow these "bypassed" devices on indefinitely or require us to:
- Maintain a list of open sessions connected via Group Policy api.

- Process session expirations via Group Policy api.

It is very easy for us to make changes on our portals application, but not at all on the services side, which is why I'm extremely hesitant to take this approach.

As brought up earlier in this thread, WPA2-E could work but would still require R&D into extending our custom RADIUS implementation to support, though I believe it would be a quicker solution and guarantee access control a bit better.

[colo]

Hi @nkarstedt, I would suggest talking to a Meraki sales rep and asking for support from an SE to make sure your use case is clearly defined. It sounds like you want to bill users for access to a network and allow them to start and stop sessions rather than have a single session length. 

Group policies can be applied at connection time using the RADIUS Accept message, and the group policy can be changed later with RADIUS CoA or using Dashboard API. The API also supports whitelist, blocklist, and even splash authorization and expiration, giving you a little more control than RADIUS.

Using a time-based solution that automatically ends the session time (pausing their time remaining) if they disconnect is possible using RADIUS Accounting information. The Dashboard API would allow for this but would require polling the devices API frequently. 

Several companies have already implemented this type of billing solution, and you can contact them from our App Directory apps.meraki.io I know Purple has this feature.