# Getting Started

Get started with your Cusna account a few steps:

1. [Prepare your WiFi network](/wifi-integration/summary-of-supported-wifi-vendors)
2. [Connect your Cusna account](/wifi-integration/summary-of-supported-wifi-vendors) to the WiFi management system
3. Setup your general service options, such as VLAN assignment mode and [WiFi Portal](/service-management/wifi-portal-and-onboarding/wifi-portal-options) capabilities in the [General](/service-management/general-options) options
4. Create [Networks](/service-management/managing-networks)
5. [Provision accounts](/service-management/managing-accounts)

### Main doc sections

{% content-ref url="/pages/XwL8CDRIh3NAV88MuItf" %}
[Service management](/service-management/dashboard)
{% endcontent-ref %}

{% content-ref url="/pages/CdKKkpOOtNtN7JwufEwD" %}
[APIs](/apis/getting-started)
{% endcontent-ref %}

### Taxonomy

* **MSP:** it refers to a service providers who have access to a dedicated dashboard to support multiple clients (Organizations)
* **Organization**: it refers to a Cusna product account associated to a specific business
* **Org Admin**: it refers to a product user who has the role and permission to manage an Organization
* **Network Admin**: it refers to a product user who has the role and permission to manage Accounts in a specific Network
* **Network:** it refers to the entity that usually is associate to a physical location (building, site, campus) that usually maps an equivalent entity in the network 
* **Account**: it refers to the artifact associated to a user or a device for which Cusna reserve a dedicated PPSK. There are different type of accounts (Tenants, IoT Groups, Spaces, Group Members)
* **Group**: it refers to a group of Accounts. The members of the Group are called Group Members
* **WiFi Portal**: it refers to the portal where users can self-onboard or access to retrieve their WiFi access service credentials and details
* **MAA** (Monthly Active Accounts): this metric tracks the maximum number of accounts in an "enabled" status on any given day within a month.


# Summary of supported WiFi vendors

<table><thead><tr><th width="213"></th><th>Max PSKs</th><th>PAN</th><th width="130">Groups-based policies</th><th>Group-based PAN</th><th>Roaming</th></tr></thead><tbody><tr><td><a href="/pages/gdUmIv98nNSXR2wbBKNN#cisco-meraki">Meraki</a> (iPSK w/o RADIUS)</td><td>5000 / network</td><td>WPN</td><td>Group-based Group Policies</td><td>No</td><td>No</td></tr><tr><td><a href="/pages/FCBgmkSkFS4keAPcJqxQ">Meraki (Easy PSK)</a></td><td>Unlimited</td><td>WPN or VLAN</td><td>Yes </td><td>VLAN</td><td>Yes</td></tr><tr><td><a href="/pages/qIEatyqvHRKJU8hztCD0">Aruba (Unbound MPSK)</a></td><td>Unlimited</td><td>VLAN</td><td>No</td><td>VLAN</td><td>Yes</td></tr><tr><td><a href="/pages/rxbrI8NmMTDiA2SvXIQl">Cisco Catalyst 9800</a> (Easy PSK)</td><td>Unlimited</td><td>UDP or VLAN</td><td>No</td><td>VLAN</td><td>Yes</td></tr><tr><td><a href="/pages/gdUmIv98nNSXR2wbBKNN#extreme-network-extreme-cloud-iq">Extreme Networks</a></td><td>5000</td><td>PCG</td><td>No</td><td>Yes</td><td>On same Network Policy</td></tr><tr><td><a href="/pages/gdUmIv98nNSXR2wbBKNN#cambium-cnmaestro">Cambium Networks</a></td><td>5000</td><td>VLAN</td><td>No</td><td>Yes</td><td>On same WLAN Profile</td></tr><tr><td><a href="/pages/gdUmIv98nNSXR2wbBKNN#juniper-mist">Juniper Mist</a></td><td>5000</td><td>VLAN or L3</td><td>No</td><td>VLAN only</td><td>Site or Org scope</td></tr><tr><td><a href="#huawei-cloudcampus">Huawei</a></td><td>-</td><td>VLAN</td><td>No</td><td>Yes</td><td>On same Site</td></tr><tr><td><a href="/pages/uW8ZTSgCaf2T5GAg7eQU">TP-Link Omada</a></td><td>1024</td><td>VLAN</td><td>No</td><td>Yes</td><td>On same SSI</td></tr></tbody></table>


# Cisco Meraki

Cisco Meraki integration is based on the [iPSK without RADIUS](https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_Authentication_without_RADIUS) feature, with support of [Wi-Fi Personal Network](https://documentation.meraki.com/MR/Encryption_and_Authentication/Wi-Fi_Personal_Network_\(WPN\)) (WPN) capabilities. It also relies on Group Policies to differentiate Tenant services (such as VLAN and bandwidth).&#x20;

{% hint style="info" %}
Cusna relies on iPSK without RADIUS and WPN is supported only on MR devices with 29.4.1+ firmware. However, to benefit form the possibility to manage up to 5,000 iPSK per SSID, you need to use firmware versions **MR 30.1 and newer**.

All APs in your network must be **Wi-Fi 5 Wave 2** (MR20, MR30H, MR33, MR42, MR42E, MR52, MR53, MR53E, MR70, MR74. MR84), **Wi-Fi 6** (MR28, MR36, MR36H, MR44, MR46, MR46E, MR56, MR76, MR78, MR86, MR45/55), **Wi-Fi 6E** (MR57, CW9162I, CW9164I, CW9166I) or newer.
{% endhint %}

## Meraki setup

Each **Location** in Cusna is associated to a **Network** in the Meraki dashboard.&#x20;

1. Create a Network in Meraki as described in the official [Meraki documentation](https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Creating_and_Deleting_Dashboard_Networks).

2. Next, you need to create an SSID configured to support iPSK. Navigate to **Wireless** > **Configure** > **SSIDs**, enable an SSID from the list and rename it with your desired network name, e.g. "*Tenant WiFi" (note: you cannot change the SSID name once you linked it to a Cusn aNetwork)*. Click **Save Changes** at the bottom of the page.

3. On the desired SSID, click "**edit settings**" link to navigate to the **Access Control** page for this SSID.

4. On the Access control Page, Select **Identity PSK without RADIUS** under **Security** and click on **Add an Identity PSK**

5. Configure a name and passphrase; select a group policy.

   \
   ![](/files/mw9IGJUNQi3J1yDDwM8m)

6. Set **Wi-Fi Personal Network (WPN)** to **Enabled**

   \
   ![](/files/sQ1WEGhXeDYBcXanUtYI)\
   \
   *Note: The "Enabled/Disabled WPN" option is only displayed when at least one iPS group is configured.*

7. Click **Save changes** on the bottom of the page.

<details>

<summary>IoT SSID - optional</summary>

If you need to support [IoT Devices Authentication](/service-management/wifi-portal-and-onboarding/iot-devices-authentication) via MAC authentication, you need to add an additional dedicated SSID in each of the Networks configured for the service.

1. Navigate to **Wireless** > **Configure** > **SSIDs**, enable an SSID from the list and rename it with your desired network name, e.g. "*IoT Devices*". Click **Save Changes** at the bottom of the page.
2. On the above SSID, click "**edit settings**" link to navigate to the **Access Control** page for this SSID.
3. On the Access Control page, select **Identity PSK without RADIUS** under **Security** \
   ![](/files/GWbunrfpy5FafzbQDSKN)
4. Select "None (direct Access)" in the Splash Page section\
   ![](/files/UsloW154G2cQ9NHFSB9R)
5. Finally, expand the **RADIUS** section and add Primary and Secondary RADIUS data for both the **RADIUS servers** and **RADIUS Accounting servers** sections.\
   The RADIUS data (IP addresses, Ports and Secrets are delivered as part of your onboarding email).<br>

   <figure><img src="/files/WZkNhbJkopAtqPp7ryPU" alt=""><figcaption></figcaption></figure>

</details>

## Cusna setup

{% hint style="info" %}
Check the guide for the [integration using oAuth](/wifi-integration/summary-of-supported-wifi-vendors/cisco-meraki/meraki-oauth-integration)
{% endhint %}

To connect Cusna to your Meraki account, you need to generate an API Key in your Meraki account:

1. Navigate to **Organizations** > **Settings**.
2. Ensure the option **Enable access to the Cisco Meraki Dashboard API** is **enabled**.
3. Navigate to your profile by clicking your account email address in the upper-right > **My profile** to generate the API key.
4. Save this key in a secure location as it represents your admin credentials.

Once the key is generated from the Cisco Meraki dashboard:

* Log in to your Cusna account and click **Setting**.&#x20;
* Expand the **WiFi setup** card, select **Meraki** and enter your **API Key.**&#x20;
* The Organization menu will load the list of Meraki Organizations enabled on your API Kay; select the Organization that you want to link to your Cusna account.&#x20;
* Click **Save**.

<figure><img src="/files/qVLLfSrYzI84jf5hSjgm" alt=""><figcaption></figcaption></figure>

Next, you need to setup at least one **Network Policy**.  Once you have set up the Meraki integration, the **Network Policy** section appears.

{% content-ref url="/pages/Xwf29ezjdhAgu9OvXO59" %}
[Network Policies](/service-management/network-policies)
{% endcontent-ref %}

{% hint style="info" %}
When using Meraki, Cusna does not allwo to manually or automatically set the VLAN on the individual tenant, since the VLAN is handled by the assigned Group Policy.
{% endhint %}

## Operating Cusna

### Creating Networks

When you create or edit a Property in the Cusna dashboard, in the WiFi configuration section, you have to pick the **Network** and **SSID** related to the Network and the Network Policy you want to assign by default to the new tenant accounts (you can select a custom Network Policy while creating a new Tenant)

![](/files/Dgid68R9lkllRSrpisfb)

Note: when selecting the SSID, Cusna verifies in real-time if the SSID is properly configured with work with iPSK without RADIUS and the other settings required by Cusna. If not compliant, you'll see a notification message. You can still select the SSID and save the Network and fix the SSID configuration later or.

<div align="left"><figure><img src="/files/iwDCRE3gdoZa4uyBPe5N" alt="" width="375"><figcaption></figcaption></figure></div>

### Managing Units

Meraki support Cusna Units management, where each unit can be associated with a Wired access point. Cusna configure the ETH ports to be in the same personal area network as the device connecting with the iPSK of the Account associated to the Unit.

{% hint style="info" %}
This feature is currently supported only on MR36H
{% endhint %}

{% content-ref url="/pages/y1n7wDDQiX9JxZy76QDh" %}
[Units](/service-management/units)
{% endcontent-ref %}

### Creating Accounts

When you create a new Account, a new iPSK user will be created in your Meraki account with a predefined WiFi Passphrase.&#x20;

In the Account setup page, you need to chose a **Network Policy** to assign to the user in the related menu. Select "**Default**" to assign the Network Policy that has been selected as the default one for the Network where you are activating the Account

![](/files/VSwC3RNZTocYjy9XveZc)

The Account of type Tenant and Visitors receive an activation email with the default passphrase and QR code, and a link to the Tenant Portal where can change the passphrase.

{% hint style="danger" %}
To avoid synchronization problems, please do not manage manually the iPSKs in the Meraki dashboard.
{% endhint %}

## Meraki WPN Limitations

* 5,000 iPSK groups per SSID and 2x SSIDs with WPN enabled per dashboard network are supported.
* Wireless devices connected to a WPN-enabled SSID *cannot* communicate with wired devices on the *same* VLAN (L2 domain) except for the default gateway.&#x20;
* Wireless devices connected to a WPN-enabled SSID *can* communicate with wired devices on a *different* VLAN through L3 routing.
* **Meraki AP assigned (NAT mode)** is not supported on an SSID with WPN enabled. **External DHCP server assigned** mode must be used instead.
* Wired AP ports using [port profiles](https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Port_Profiles) do not support WPN.


# Meraki oAuth integration

Cisco Meraki recently introduce the option to authenticate integrations using oAuth authentication instead of the legacy static API Keys.

All Organizations adhering to the Beta Program will now see this option when connecting Meraki to Cusna.

&#x20;On the **Setup**, **Integrations** page, on the **WiFi Network** card, select Meraki form the **WiFi Vendor** dropdown.

<figure><img src="/files/S2UWOptUPivmWTQTXw90" alt=""><figcaption></figcaption></figure>

Check the toggle **Connect via oAuth**. The button **Connect with Meraki** appears instead of the API Key input.

Click the Connect with Meraki button, to get redirected to the Meraki Authorization page.

<figure><img src="/files/DUzElb07P1VT1eyjJ32Y" alt=""><figcaption></figcaption></figure>

In the **Select an organization** dropdown, select the Organization you want to link to your Cusna accoutn and click **Allow**.

You'll be redirected to the Cusna dashboard. Initially you may see the button with the label "pending",  while the integration gets finalized.&#x20;

<figure><img src="/files/veZR3Ixzx3IcSOIa4fag" alt=""><figcaption></figcaption></figure>


# Cisco Catalyst WLC (IOS-XE)

{% hint style="info" %}
This is a Beta feature only for partners and customer with access to the Beta Program.
{% endhint %}

{% hint style="info" %}
Check the official Cisco documentation to understand requireiments and limitations:\
<https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-6/config-guide/b_wl_17_6_cg/m_epsk.html>
{% endhint %}

**Cisco Easy PSK** is a new solution that leverages RADIUS authentication while overcoming the limitations of traditional MAC-based authentication. The RADIUS platform performs a user lookup by analyzing the EAPOL parameters included in the RADIUS request to identify potential user matches.

Cusna leveraged the **Cisco** **UDN** (**User Defined Network**) technology to create personal area network without requiring complex VLAN-based orchestrations.

## Cisco WLC Setup

### AAA Server

Click **Configuration > Security > AAA** on the left. Select the **Servers / Groups** tab and click **Add**. Configure with:

| Name:                       | Cusna\_Radius\_1                   |
| --------------------------- | ---------------------------------- |
| IPv4 / IPv6 Server Address: | \*insert radius\_server\_ip here\* |
| Key Type:                   | 0                                  |
| Key:                        | \*insert radius\_secret here\*     |
| Confirm Key:                | as above                           |
| Auth Port:                  | 1812                               |
| Acct Port:                  | 1813                               |
| Server Timeout:             | 10                                 |
| Retry Count:                | 3                                  |
| Support for CoA:            | Enabled                            |

Click **Apply to Device** to save. Next, click **Add** again and configure with:

| Name                        | Cusna\_Radius\_2                    |
| --------------------------- | ----------------------------------- |
| IPv4 / IPv6 Server Address: | \*insert radius\_server2\_ip here\* |
| Key Type:                   | 0                                   |
| Key:                        | \*insert radius\_secret here\*      |
| Confirm Key:                | as above                            |
| Auth Port:                  | 1812                                |
| Acct Port:                  | 1813                                |
| Server Timeout:             | 10                                  |
| Retry Count:                | 3                                   |
| Support for CoA:            | Enabled                             |

Click **Apply to Device** to save. On the **Server Groups** sub tab, click **Add**. Configure with:

| Name              | Cusna\_Radius\_Group                |
| ----------------- | ----------------------------------- |
| Group Type:       | RADIUS                              |
| MAC-Delimiter:    | hyphen                              |
| MAC-Filtering:    | mac                                 |
| Assigned Servers: | Cusna\_Radius\_1, Cusna\_Radius\_2, |

Click **Apply to Device** to save. Next, click on the **AAA Method List** tab, **Authentication** sub nav menu. Click **Add** and configure with:

| Method List Name        | Cusna\_AuthN  |
| ----------------------- | ------------- |
| Type:                   | dot1x         |
| Group Type:             | group         |
| Assigned Server Groups: | Cusna\_Radius |

Click **Apply to Device** to save. Next, click the **Authorization** sub nav menu on the left and click **Add**. Configure with:

<table data-header-hidden><thead><tr><th width="392">Method List Name:</th><th>guest_acct</th></tr></thead><tbody><tr><td>Method List Name</td><td>Cusna_AuthZ</td></tr><tr><td>Type:</td><td>network</td></tr><tr><td>Assigned Server Groups:</td><td>Cusna_Radius</td></tr></tbody></table>

Click **Apply to Device** to save. Next, click the **Accounting** sub nav menu on the left and click **Add**. Configure with:

<table data-header-hidden><thead><tr><th width="392">Method List Name:</th><th>guest_acct</th></tr></thead><tbody><tr><td>Method List Name</td><td>Cusna_Acct</td></tr><tr><td>Type:</td><td>identity</td></tr><tr><td>Assigned Server Groups:</td><td>Cusna_Radius</td></tr></tbody></table>

Click **Apply to Device** to save. Next, click the **AAA Advanced** tab and then the **Show Advanced Settings >>>** option. Configure both **Accounting** and **Authentication** with:

| Call Station ID:      | ap-macaddress-ssid |
| --------------------- | ------------------ |
| Call Station ID Case: | upper              |
| MAC-Delimiter:        | hyphen             |
| Username Case:        | lower              |
| Username Delimiter:   | none               |

### Wireless AAA Policy

Click **Configuration > Security > Wireless AAA Policy** on the left. Click **Add** or edit an existing Wireless AAA Policy and configure with:

| Setting         | Value              |
| --------------- | ------------------ |
| Policy Name     | Cusna\_AAA\_Policy |
| NAS-ID Option 1 | AP MAC Address     |
| NAS-ID Option 2 | AP Site Tag        |
| NAS-ID Option 3 | SSID               |

### WLANs

Click **Configuration > Tags & Policies > WLANs** on the left. Click **Add** or edit an existing WLAN and configure with:

On the **General** tab:

| Setting         | Value                         |
| --------------- | ----------------------------- |
| Profile Name    | Cusna Profile                 |
| SSID:           | ResNet (or whatever you wish) |
| Status:         | Enabled                       |
| Radio Policy:   | All                           |
| Broadcast SSID: | Enabled                       |

On the **Security > Layer 2** tab:

| Setting                | Value                                                  |
| ---------------------- | ------------------------------------------------------ |
| Layer 2 Security Mode: | WPA + WPA2                                             |
| MAC Filtering:         | Enabled                                                |
| 802.1x                 | Disabled                                               |
| PSK                    | Enabled                                                |
| Easy-PSK               | Enabled                                                |
| Authorization List     | Cusna\_AuthZ *(Authorization List previously created)* |
| Fast Transition        | Disabled or Enabled (not Adaptive Enabled)             |

On the **Security > AAA** tab:

| Authentication List | Cusna\_AuthN *(Authentication List previously created)* |
| ------------------- | ------------------------------------------------------- |

### Policy

Click **Configuration > Tags & Profiles > Policy** on the left. Click **Add**, leaving all settings at default apart from the following:

On the **General** tab:

| Setting | Value         |
| ------- | ------------- |
| Name:   | Cusna\_Policy |
| Status: | Enabled       |

On the **Advanced** tab:

| WLAN Timeout     |       |
| ---------------- | ----- |
| Session Timeout: | 43200 |
| Idle Timeout:    | 3600  |

| AAA Policy          |                                            |
| ------------------- | ------------------------------------------ |
| Allow AAA Override: | Enabled                                    |
| Accounting List:    | Cusna\_Acct                                |
| Policy Name         | [Cusna\_AAA\_Policy](#wireless-aaa-policy) |

| User Defined (Private) Network |          |
| ------------------------------ | -------- |
| Status                         | Enabled  |
| Drop Unicast                   | Disabled |

### Tags

Click **Configuration > Tags & Profiles > Tags** on the left. Click **Add** and configure with:

| Setting         | Value                    |
| --------------- | ------------------------ |
| Name:           | Cusna\_Tag               |
| WLAN Profile:   | [Cusna Profile](#wlans)  |
| Policy Profile: | [Cusna\_Policy](#policy) |

## Cusna setup

Cusna does not integrate directly with on-prem Cisco Catalyst 9800 WLCs.

* Log in to your Cusna account and click **Setting**.&#x20;
* Expand the **WiFi setup** card, select **Cisco WLC**&#x20;
* Enter a **Name** for your WLC and click **Save**.

## Creating Networks

Although Cusna does not integrates directly with the WLC via APIs, the Network artifact is used in Cusna to define the Home Network of each Account, for the use cases that require PAN orchestration.

The Network an Account is associated with, becomes the account "Home Network". Only when the user is connected to an Access Points of its Home Network, Cusna enforces the Account UDN.

The Network the user is connected form is detected by means of **Site Tags**.  When you setup a Network you need to specify:

* **SSID Name**: the PPSK generated for the user will work only on this SSID name
* **Site Tag**: the Site Tag that can be used to match the authentication request with this Cusna Network.

<figure><img src="/files/bqRwjtipyBH7GY0IGN67" alt=""><figcaption></figcaption></figure>


# Cisco Meraki Easy PSK

Traditional RADIUS-based iPSK relies on MAC authentication, requiring each device to be pre-onboarded individually to collect its MAC address. While onboarding through a captive portal can simplify the process for non-headless devices, it still requires manually collecting and adding the MAC addresses of headless devices (such as smart TVs, printers, smartwatches, etc.), which can be challenging. Additionally, the MAC addresses of many personal devices may change over time due to the aggressive MAC randomization and rotation policies in modern operating systems.

**Cisco Meraki Easy PSK** is a new solution that leverages RADIUS authentication while overcoming the limitations of traditional MAC-based authentication. The RADIUS platform performs a user lookup by analyzing the EAPOL parameters included in the RADIUS request to identify potential user matches.

Key Advantages of This Approach:

* **Scalability:** Supports deployments larger than 5,000 users, overcoming the limit of Meraki iPSK without RADIUS, which supports up to 5,000 iPSKs per network.
* **Seamless Roaming:** Enables users to roam across any network deployed within the project without reauthentication issues.
* **Selective PAN Enforcement:** In multi-network deployments, Cusna can enforce Personal Area Network (PAN) segmentation on specific networks, such as a user’s home network. For example, in a large campus with multiple networks, a user can connect with their iPSK anywhere, but PAN enforcement applies only when connected to their dormitory network.
* **Advanced Connection Logs and Reports:** Provides detailed RADIUS authentication and accounting logs for improved visibility and auditing.
* **Wired Device Support:** Allows devices connected via switch ports to be authorized using MAC authentication. Since PAN cannot be implemented via WPN (which is incompatible with switches), Cusna can be configured to use VLANs for PAN deployment.
* **Granular Network Policies:** Enforces advanced policies through RADIUS AAA, beyond dynamic group policies. This includes the ability to limit the maximum number of devices per user and restrict the number of concurrent device  per user.

## Meraki Setup

Each **Location** in Cusna is associated to a **Network** in the Meraki dashboard.&#x20;

1. Create a Network in Meraki as described in the official [Meraki documentation](https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Creating_and_Deleting_Dashboard_Networks).
2. Next, you need to create an SSID configured to support Easy PSK. Navigate to **Wireless** > **Configure** > **SSIDs**, enable an SSID from the list and rename it with your desired network name, e.g. "*Residents WiFi*". Click **Save Changes** at the bottom of the page.
3. On the desired SSID, click "**edit settings**" link to navigate to the **Access Control** page for this SSID.
4. On the Access control Page, Select **Identity PSK with RADIUS** under **Security** and in the dropdown select **Easy PSK**\
   \
   ![](/files/ST1HpW5LlIatA5D6x74O)<br>
5. Set **Wi-Fi Personal Network (WPN)** to **Enabled**
6. Click **Save changes** on the bottom of the page.

{% hint style="info" %}
You'll have to come back to this page once you have integrated Cusna with your Meraki account to configure the RADIUS Servers.
{% endhint %}

<details>

<summary>IoT SSID - optional</summary>

If you need to support [IoT Devices Authentication](/service-management/wifi-portal-and-onboarding/iot-devices-authentication) via MAC authentication, you need to add an additional dedicated SSID in each of the Networks configured for the service.

1. Navigate to **Wireless** > **Configure** > **SSIDs**, enable an SSID from the list and rename it with your desired network name, e.g. "*IoT Devices*". Click **Save Changes** at the bottom of the page.
2. On the above SSID, click "**edit settings**" link to navigate to the **Access Control** page for this SSID.
3. On the Access Control page, select **Identity PSK without RADIUS** under **Security** \
   ![](/files/GWbunrfpy5FafzbQDSKN)
4. Select "None (direct Access)" in the Splash Page section\
   ![](/files/UsloW154G2cQ9NHFSB9R)
5. Finally, expand the **RADIUS** section and add Primary and Secondary RADIUS data for both the **RADIUS servers** and **RADIUS Accounting servers** sections.\
   The RADIUS data (IP addresses, Ports and Secrets are delivered as part of your onboarding email).<br>

   <figure><img src="/files/WZkNhbJkopAtqPp7ryPU" alt=""><figcaption></figcaption></figure>

</details>

## Cusna setup

To connect Cusna to your Meraki account, you need to generate an API Key in your Meraki account:

1. Navigate to **Organizations** > **Settings**.
2. Ensure the option **Enable access to the Cisco Meraki Dashboard API** is **enabled**.
3. Navigate to your profile by clicking your account email address in the upper-right > **My profile** to generate the API key.
4. Save this key in a secure location as it represents your admin credentials.

Once the key is generated from the Cisco Meraki dashboard:

* Log in to your Cusna account and click **Setting**.&#x20;
* Expand the **WiFi setup** card, select **Meraki**&#x20;
* Enable the toggle **Easy PSK via RADIUS**
* Enter your **API Key.**&#x20;
* The Organization menu will load the list of Meraki Organizations enabled on your API Kay; select the Organization that you want to link to your Cusna account.&#x20;
* Click **Save**.

<figure><img src="/files/lPddaJmJCF64pMpq8KlP" alt=""><figcaption></figcaption></figure>

Once saved, you will see a link that open a popup showing the RADIUS parameters to configure in the Meraki dashboard.

<div align="left"><figure><img src="/files/CaismnEcY7T9AmJCruW8" alt="" width="375"><figcaption></figcaption></figure></div>

Configure RADIUS server in the Meraki dashboard.

1. Go back to the Meraki dashboard and open the **Access Control** page for the SSID you had configured before
2. Find the RADIUS section and expand it.
3. Add

Next, you need to setup at least one **Network Policy**.  Once you have set up the Meraki integration, the **Network Policy** section appears.

{% content-ref url="/pages/Xwf29ezjdhAgu9OvXO59" %}
[Network Policies](/service-management/network-policies)
{% endcontent-ref %}

## Scenarios: multi-network deployments

Imagine a large campus divided into multiple **Meraki Networks** for easier management, with separate networks for areas such as dormitories, public spaces, parks, and faculty buildings.

In the dormitories, each room has its own access point (AP) along with Ethernet outlets connected to floor-level switches. In this scenario, the best technology for managing **Personal Area Networks (PANs)** is VLANs, since switches do not support WPN.

* **Wireless Devices:** Students connect their wireless devices using **PPSK (Easy PSK)**, allowing seamless connectivity across all campus networks.
* **Wired Devices:** Devices connected via the Ethernet outlet in a student’s room are authenticated using **MAC authentication**, and require an onboarding process.

When a student connects devices (wired or wireless) from the **dorm network**, the RADIUS server assigns a unique VLAN to ensure all of that student’s devices are on the same network, creating an isolated PAN.

However, when the student connects their wireless devices to other networks on campus (outside the dorms), the devices are still authorized but without any specific VLAN enforcement. Instead, they inherit the VLAN defined by their **Group Policy** or the default VLAN assigned to the SSID.

<figure><img src="/files/iMNBDc3uXvGi3WxJWHU1" alt=""><figcaption></figcaption></figure>

### Wired Devices Onboarding

Wired devices can be onboarded in two different ways.

Headless devices must be manually provisioned by the user on their [WiFi portal](/service-management/wifi-portal-and-onboarding/iot-devices-authentication), adding their MAC address and reference friendly name.

Non-headless devices, once connected to the ETH port, can be blocked and prompted to a captive portal to enroll the device.

1. The user enters his email address
2. Form another device, open the email and click the link
3. Give a name to the device and approve it.
4. Disconnect and reconnect the cable device to the ETH port

<figure><img src="/files/jhsmok6I9XgPsHW98tXe" alt=""><figcaption></figcaption></figure>


# Aruba - Unbound MPSK

{% hint style="info" %}
Requires AP with Firmware **AOS 10.4.x** or above
{% endhint %}

Traditional RADIUS-based iPSK relies on MAC authentication, requiring each device to be pre-onboarded individually to collect its MAC address. While onboarding through a captive portal can simplify the process for non-headless devices, it still requires manually collecting and adding the MAC addresses of headless devices (such as smart TVs, printers, smartwatches, etc.), which can be challenging. Additionally, the MAC addresses of many personal devices may change over time due to the aggressive MAC randomization and rotation policies in modern operating systems.

**Aruba Central Unbound MPSK** is a new solution that leverages RADIUS authentication while overcoming the limitations of traditional MAC-based authentication. The RADIUS platform performs a user lookup by analyzing the EAPOL parameters included in the RADIUS request to identify potential user matches.

## Aruba Central Setup

To get Start with Cusna, you need to initially configure properly a **WLAN** on your Aruba Central dashboard. You can create multiple WLANs and associated them to different **Networks** in Cusna.<br>

1. Setup a **Group** for your project, configuring it with **ArubaOS 10** architecture\
   ![](/files/dYSHpohK2b3fySKGGJSW)<br>
2. Select the **Config** wheel to start configuring the Group\ <img src="/files/vokyJzkrT8rHsCYawiHl" alt="" data-size="original"><br>
3. Under **Security Tab** add the Radius Authentication Server:\
   Enter a **Name**, such as *CusnaRADIUS*\
   IP Address: \<can be retrieved in the Cusna Dashboard>\
   Secret: \<can be retrieved in the Cusna Dashboard>\
   Auth Por: 1812\
   Accounting Port: 1813\
   ![](/files/Tpg6lSf7tycGOOEO8g92)<br>
4. Next, select the **WLAN** tab and then the Plus sign next to add SSID\
   ![](/files/pLH58ww6u0NR9gorwrc0)<br>
5. There are many parameters that can be customized at your discretion.  For now, we will create a simple WLAN network. Type in a **SSID** name (ESSID) and click Next
6. On the next screen, select **Static** on **Client VLAN Assignment**, enter a **VLAN**  - based on your specific deployment setup - and click **Next**
7. In the **Security** tab, under **Key Management**, select **MPSK-AES** and then pull down on the **Primary Server** setting to select the Radius Server you configured above <br>

   <figure><img src="/files/9IWmbtW0ODn5Z6oJdutM" alt=""><figcaption></figcaption></figure>
8. Expand the **Advanced Settings** and go down and disable **802.11r**\
   ![](/files/WdCozSvX0u65dHlOgXcy)<br>
9. Click **Next** two more times and your WLAN SSID with MPSK AES should be complete.<br>

   <figure><img src="/files/BmhIdQ3yLyynffNJipVK" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
The Aruba Central dashboard currently does not permit manual enabling of WLAN for Unbound MPSK. However, Cusna will automatically update the WLAN configuration once you link your Cusna and Aruba Central accounts using the steps below.
{% endhint %}

## Cusna setup

To connect Cusna to your Aruba Central account, you need to generate an API Key in your Aruba Central account:

1. At the **Global** level, select **Organization** and then **Platform Integration**
2. Chose [**REST API**](https://app-uswest5.central.arubanetworks.com/frontend/#/APIGATEWAY)\
   ![](/files/WKVHy9jc7SC0diQEJdit)![](/files/FsY2CPp60JylSwrJW78z)
3. In the first tab, make sure to take note of the **API hostname** for  your account, such as "[apigw-uswest5.central.arubanetworks.com](https://apigw-uswest5.central.arubanetworks.com)" (take only the hostname, without "https\://")<br>

   <div align="left"><figure><img src="/files/RERCU39idhKIGJDhCoIv" alt="" width="375"><figcaption></figcaption></figure></div>
4. Choose **My Apps and Tokens** tab. Create a Token.
5. Copy the **Client ID** and **Client Secret**. <br>

   <figure><img src="/files/MUSSUClJvozl5xPPJghx" alt=""><figcaption></figcaption></figure>
6. Then, in the Token List table, click **Download Token** and Copy the **Access token** and **Refresh Token** (It is good for 2 hours)<br>

   <figure><img src="/files/I6yaqAM1cxNKVkrHpkPn" alt=""><figcaption></figcaption></figure>

Once the key is generated, complete the integration in the Cusna dashboard:

* Log in to your Cusna account and click **Setting**.&#x20;
* Expand the **WiFi setup** card, select **Aruba Central**&#x20;
* Enable the toggle **Easy PSK via RADIUS**
* Enter :
  * your API GW URL
  * client ID
  * client Secret

    <figure><img src="/files/B14GmIfL0GzGxpXohNd9" alt=""><figcaption></figcaption></figure>
* Click **Authorize**. The **Authorize integration** dialog appears. \
  Enter your **Access Token** and **Refresh Token** and click **Authorize**.\
  \
  ![](/files/gQvTf9Ta87nxfLiozjd6)\
  \ <br>

{% hint style="warning" %}
Unbound MPSK mode cannot be enabled manually on Aruba Cen**tral**.

When you connect a Cusna Network with a WLAN and SSID, Cusna programmatically enables the Unbound MPSK mode on the SSID via APIs.

**If you make a change to the SSID  on the Central dashboard, it will lose the Unbound MPSK support.**

To re-enable it, go to Cusna dashboard, **Setup** > **Integration** and click **Edit** on the Aruba integration card. Click **Enable Unbound MPSK on SS**ID.

![](/files/qlPtLlYZh0cf9JvKWmAX)<br>

On the next dialog select your **Group** and **SSID** and click Setup. \
![](/files/NGDRI0v0d2OW9iwlH3U9)
{% endhint %}


# Fortinet (FortiGate Secure Wireless Controller)

## FortiGate Secure Wireless Controller setup

You need to manually create the WLAN/s you want to use to run Cusna on.

1. Go to **WiFi and Switch Controller** (or simply **WiFi Controller**, depending on your licenses) > **SSIDs** and edit an existing SSID you want to use or create a new one.&#x20;
2. In **Security Mode**, select **WPA2 Personal**.&#x20;
3. In **Pre-shared Key**, select **Multiple** as the **PSK mode**
4. Next, you need to select at least one **MPSK Profile** (otherwise the SSID will switch back automatically to Single PSK mode once you save the configuration).\
   You can select any existing MPSK Profile if you have one, Cusna will create a new one automatically once integrated with your Fortigate and assign it to this SSID. \
   If you don't have any existing MPSK Profile, create a new one:
   1. In the MPSK Profile dropdown, select **+ Create** . The **New MPSK Profile** dialog appears.\
      ![](/files/PVXPSmkPC4eu3BenjI29)
   2. Enter any value in the **Name** file, such as "Default"
   3. In the **MPSK Group list** section, click **+Add** and select Create Group. The **New MPSK Group** dialog appears.\
      ![](/files/JBAoU4zqWRKWV364rJd1)
   4. Enter any value in the **Name** file, such as "Default"
   5. In the **MPSK Key list** section, click **Create  Key** and select Create Group. The **New MPSK Key** dialog appears.\
      ![](/files/9j6fUjK6m57WKRNrdzX3)
   6. Enter any value for **Name** and a 10 character string for **Pre-shared key**.
   7. Save all the configurations until you go back to the list of SSIDs.

{% hint style="danger" %}
After the initial setup, the MPSK Profile assigned to the SSID will be managed automatically by Cusna. Do Not change the MPSK Profile manually on this SSID.
{% endhint %}

{% hint style="warning" %}
You Fortigate controller need to have a valid SSL certificate and be reachable over the internet at a specific hostname or static IP address.

If you encounter any certificate related error during setup, please contact our support.
{% endhint %}

## Cusna setup&#x20;

Log in your Fortinet system with admin access. Click **System** > **Administrator**. Click the button **+ Create New** and select **REST API Admin**.

![](/files/mVQbsCgM8SWVlQZln225)

In the **New Rest API Admin** page, enter a **Username**.

Then select or create a new **Administrator Profile** with the **Read/Write** permissions for **WiFi & Switch** Access Control category.

Disable **PKI Group**.

Enable **CORS Allow Origin** and enter **<https://cusna.io>**

Click **OK** and copy the **API Key** shown in the right panel. The API Key will be shown only once, so make sure to copy it on a note.

![](/files/QBXnW0Jeum9ulyBKQ09d)

Open your Cusna dashboard and go to Setting, expand the WiFi setup card, select **Fortinet** and in the setup panel enter your:

* **hostname** (eg. 207.45.23.34 or fortigate.example.com)
* **port** (e.g. 45)
* **API** Key

<figure><img src="/files/swVE1lQY1OV1FDZXF1Gw" alt=""><figcaption></figcaption></figure>

Click **Setup**.

If any of the provided integration attributes are wrong, you'll get an error.


# Extreme Networks

## Account preparation

To get started, you need to create a **Network Policy**.

{% hint style="info" %}
To lear more about restrictions and guidelines on how to use PCGs, please refer to the [ExtremeCloudIQ documentation](https://extremeportal.force.com/ExtrArticleDetail?an=000099731) and watch this [short video about PCGs](https://www.youtube.com/watch?v=1JiacjAIyt8).
{% endhint %}

Go to **Configure**, **Network Policies** and click **Add Network Policy**. Give the Policy a name, for example one that recalls the name of the Network.

![](/files/3ZqAv80a4FQi1gtqYPJL)

Then, go to the Wireless Networks tab and create a new **Wireless Network** clicking on the icon "**+**". Give the network an **SSID** name, such as *Residents*.

As **SSID Authentication**, select **Private Pre-Shared Key**. Leave all the other fields as per the default settings.

You can optionally set a maximum number of devices per resident by enabling **Set the maximum number of clients per private PSK**.

Select the option **Private Client Group Option** and select **Key-based** as a sub-type.

![](/files/DS1iqweusHCmq4qZZOoa)

## Account integration

To connect Cusna to your Extreme Cloud IQ account, you need to generate an API Access Token.

**Option 1.** Connect it directly from Cusna.

Go to **Setting**, **Integration** and select **Extreme form the vendor selection menu**. Click the **Generate an access token now** button.&#x20;

<figure><img src="/files/msuHuntTwBEe9JGU4z4S" alt=""><figcaption></figcaption></figure>

A dialog opens and asks for your ExtremeCloudIQ username and password. Make sure to use an account with admin permissions.

<figure><img src="/files/omGh8gTqdkuUxls90waL" alt="" width="375"><figcaption></figcaption></figure>

Click **Login**. If the credentials are correct, an Access Token will be generated. If your accoutn has access to multple Organizations, a dropdown will appear to let you select the the Organization.

Click **Save** to finalize the setup.

**Option 2**: manually generate a Token in ExtremeCloudIQ (requires an Extreme Networks Developer Portal account)&#x20;

In your ExtremeIQ dashboard, click on your avatar on the top bar and select **Global Settings**. Go to **API Token Management** and click the icon "**+**" to create a new token.

The **Client ID** is the Credentials value from **My Profile** > **Your API Developer Application** in the Extreme Networks Developer Portal.

<figure><img src="/files/YoD4lIoiCFVFirrnFmNy" alt="" width="375"><figcaption></figcaption></figure>

Open your Cusna dashboard and go to **Setting**, expand the WiFi setup card, select Extreme, enter your API **Access Token** and click **Save**.

![](/files/Dd8VbjV61PcN9bbAVfqc)

## Operating Cusna

Once you have configured your Network Policy and Wireless Network, you can start operating your Cusna account.

### Creating Networkd

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the **Network Policy** and **SSID** related to the Network.

![](/files/6aqxD9bRTa8KgYaWLLWJ)

{% hint style="warning" %}
This operation will create a dedicate Use Group in Extreme CloudIQ and enable it to the selected Network Policy.
{% endhint %}

#### Roaming configuration

If you want users to be able to connect with the same PPSK across multiple Network you simply need to assign the same Network policy to the Network you want to federate.

### Creating Accounts

When you create a new Account, a new PSK user will be created in your ExtremeCloud IQ Pilot account with a predefined WiFi Passphrase. The Account of type Tenant and Visitors receives an activation email with the default passphrase and QR code, and a link to the WiFi Portal where can change the passphrase.

{% hint style="danger" %}
To avoid synchronization problems, do not manage manually the PPSKs in the ExtremeCloud IQ Pilot interface
{% endhint %}

***

<details>

<summary>Under the hood</summary>

Cusna automates many configuration and processes on the Extreme dashboard.

1. When setting up the integration, Cusna initializes a **User Gro**up with a default name (Cusna-Default-PCG). All users will be created in the same user group
2. When initializing a Location in Cusna, the default **User Group** is automatically enabled on the **Network Policy** associated to the Location
3. When enabling an Account in Cusna, it creates a **User** in the default User Group&#x20;

</details>


# Ruckus SmartZone

Ruckus SmartZone integration is based on the DPSK  and relies on VLANs to differentiate resident Personal Area Networks.

## SmartZone setup

Each **Network** in Cusna is associated to a **Zone** and a specific **WLAN** in the SmartZone dashboard.&#x20;

1. Click the Wireless **LANS** tab.&#x20;
2. On the Wireless LANs screen, click the **+ Create** button. The Create WLAN Configuration appears.
3. Complete the **General Options** section of the screen
4. In the **Authentication Options** section of the screen, be sure that the default selection of **Open** is selected.

   1. In the **Encryptions Options** section of the screen, you must select "**WPA2**," which expands the section as follows:<br>

      <figure><img src="/files/vi3xkeu7TOeOCT5lhy6l" alt=""><figcaption></figcaption></figure>
   2. The Algorithm field must be **AES**, which is the default.
   3. In the Passphrase field, enter a **passphrase** for the DPSK WLAN that you are creating, and make note of this passphrase. The minimum length is eight characters.
   4. In the Dynamic PSK field, select **Internal**. Once you make this selection, DPSK is enabled, and the screen expands again, allowing you to complete the configuration of this section of the screen:

   <figure><img src="/files/k2SmcJHSwsPThMFcl7sN" alt=""><figcaption></figcaption></figure>

   * In the DPSK Length field, enter a value that complies with the security policy of your company. The default is 62.
   * For DPSK Type, choose the option that complies with the security policy of your company. The default is Secure DPSK.
   * For DPSK Expiration, use the drop-down menu to select a value that complies with the security policy of your company. The default value is Unlimited.

<br>

## Cusna setup

{% hint style="warning" %}
Your SmartZone instance must have a valid SSK certificate in order to work with Cusna. Self signed SSL certificate might cause problems.
{% endhint %}

* Log in to your Cusna account and click **Setting**.&#x20;
* Expand the **WiFi setup** card, select **Rucksu SmartZone**
* Enter the **URL** fo your SmartZone instance. \
  If the URL of your smartzone look slike this:\
  [https://vsz71.ruckusdemos.net:8443/wsg](https://vsz71.ruckusdemos.net:8443/wsg/#m/externalServices|t/generalSettingsSms)\
  The URL is: *vsz71.ruckusdemos.net*
* Click the button **Connect**. A login dialog appear. Enter your Ruckus SmartZone credentials.
* Click **Authorize**. The dialog closes.
* Click **Setup** to finalize the integration


# Cambium cnMaestro

## cnMaestro setup

First step, you need to create a WLAN configured to support  ePSKs.&#x20;

Form the **Configuration** menu, select **WiFi Profiles**. Open the **WLANs** tab.

Add a new WLAN. Set the **Name** and the **SSID** (e.g. "Residents WiFi"). Set the Security to WPA2 Pre-Shared Key and change the default Passphrase with a complex value (no one will use this passphrase).

Set **Client** **Isolation** to **Disable** (each resident will have its own VLAN and all the devices will be able to communicate regardless of the AP they are connected to)

![](/files/dHyarqcp1TB6SxFxuhVG)

{% hint style="warning" %}
Cusna implements an automatic VLAN management to segregate each resident traffic. Cusna uses by default the slot of VLANs 2000-4000 so you should avoid using these VLANs for any other purposes.
{% endhint %}

Once you have a **WLAN** you can assign it to one or multiple **AP Groups**.&#x20;

ePSK are managed at the WLAN level by cnMaestro, so if you assign the same WLAN to multiple AP groups (for example on different Network), a user will be able to connect to WiFi with the same ePSK on all the APs where such WLAN is deployed.

**Distributed communities scenario**

If you want users to be able to connect with the same ePSK in multiple Networks (or AP groups), you should create one WLAN and assigned to multiple AP groups.&#x20;

In Cusna you can still create a dedicated Network for each physical site, even if multiple Networks are assigned to the same WLAN profile. In the alternative, you can create a single "virtual" Network matching all the AP groups where the WLAN is deployed.

In Cusna, an Account is always associated with one Network. If the Account visits a different Network where the same WLAN is deployed, he would be able to connect with the same ePSK.&#x20;

If you are assigning VLANs to the Account, the same VLAN should be enable on all the sites.

In Cusna, an email address can be associated to ONLY one Account in the same Organization.

**Isolated communities scenario**

If you want to create isolated communities, where a user is able to connect only in one specific Network, you need to create a dedicated WLAN for each AP Group (assuming you are using a dedicated AP Group per each Network).

Note that a user, with the same email, cannot exists with different Accounts on different Networks.

## Cusna setup

To connect Cusna to your Cambium account you need to get the **hostname** of your cnMaestro account. You can easily identify the hostname form the URL base of your browser once you are logged in in your cnMaestro account.

![](/files/X1CUtWzM8SJCd41M4LUV)

Then you need to generate an API Client and retrieve a client ID and Client Secret. Go to **Network Services** and open **API Client**

![](/files/56WC8AnlOknefDxhrLs4)

Click Add API Client and fill the Basic Information form as follow:

* **Name**: any name, such as *Cusna*
* **Description**: any text such as *Cusna*
* **Expiration Time**: Cusna will refresh the API access automatically, but we recommend enter a greater value than the default one, such as 10000
* **Token Renewal** Time: enter the same value as entered above

Click **Save**.

Copy the Client ID and Client Secret that appear on the screen after saving

![](/files/3oaNIuuJBSUc4psWUDy1)

Go to Settings in your Cusna account and select Cambium (cnMaestro).

Enter the requested value;

* hostname
* Client ID
* Client Secret

Click **Setup**.

<figure><img src="/files/qeQk4PwM4nDbVE1lQO2y" alt=""><figcaption></figcaption></figure>

After clicking **Setup**, you'll see the Cambium integration in the list.

<figure><img src="/files/wuDVJt8J2sVVMjHr90pz" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
You can change the Client ID and Client Secret in future, but you can't change the account hostname
{% endhint %}

## Operating Cusna

### Creating Networks

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the **WLAN** that you have enabled on the Access Point of the related to property.

![](/files/5Y00YqP6h6p5NBTTzDWP)

###

### Creating Accounts

When you create a new Account, a new PSK user will be created in your cnMaestro account with a predefined WiFi Passphrase. The Account of type Tenant and Visitors, receive an activation email with the default passphrase and QR code, and a link to the **WiFi Portal** where can change the passphrase.

{% hint style="danger" %}
To avoid synchronization problems, do not manage manually the ePSKs in the cnMaestro interface
{% endhint %}


# Juniper (Mist)

## Account preparation

For each property you need to create a new **Site**.

Go to **Organization**, **Site Configuration** and click **Create Site**. Give the site a name, for example one that recalls the name of the property, and click **Save**.

![](/files/mJdceleibhPWLEyDFJ4G)

Go to **Sites** and select **WLANs**. Click **Add WLAN**.

Give the **SSID** a name, such as "Residents WiFi".

On the Security card, select **WPA-2/PSK with multiple passphrases**.&#x20;

Select **Local** or **Cloud** as a source.

Enable the checkbox next to **Configure as a personal WLAN**.

![](/files/68zNcibjUpMcBQHSsf5u)

## Account integration

To connect Cusna to your Mist account, you need to generate an API Access Token and to retrieve your Organization ID.

Go to **Organization** and select **Settings**.

In the top left card, you can find the Organization ID. Copy it because you'll need to enter it later in the Cusna dashboard.

![](/files/TtZQkIcVYk22lufjLArW)

Scroll down to the end of the page until you find the card **API Token**. Click **Create Token**.

Give the token a name, such as "Cusna" and select **Network Admin** as **Access Level**.&#x20;

In the **Site Access** setting, select **All Sites**. Click **Generate**.

![](/files/GATO9Qp5ZEAwmMflbuwU)

Copy the value that appears in the Key input and save it. You'll need to enter it in the Cusna dashboard.

Open your Cusna dashboard and go to Setting, expand the WiFi setup card, select **Juniper (Mist)** and enter your **API Token** and your **Organization ID**

<figure><img src="/files/FikEo47MRsewTWnVIwQg" alt=""><figcaption></figcaption></figure>

On PSK Mode, you can select among the following options:

1. **Org Level**: with this option, PSKs will be created at the Organization level, meaning that users could use them to connect to any Site.
2. **Site Level**: with this option, each PSK will be valid only on the Site for which it is initialized.

{% hint style="warning" %}
When you select Org Level PSKs, Cusna Accounts are still associated with an initial Network. However, their WiFi passphrase will be working across all Networks/Sites.
{% endhint %}

## Operating Cusna

### Creating Networks

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the **Site** and SSID related to the property.

![](/files/prAY0Ph1h7CcWzo595Sy)

### Creating Accounts

When you create a new Account, a new PSK user will be created in your Mist account with a predefined WiFi Passphrase. The Account of type Tenant and Visitor receive an activation email with the default passphrase and QR code, and a link to the Tenant Portal where can change the passphrase.

{% hint style="danger" %}
To avoid synchronization problems, do not manage manually the multi PSKs in the Mist interface
{% endhint %}


# TP-Link Omada

## Omada setup

For each Network you need to setup a Site in your Omada account.

Once you have the Site, create a WLAN network and an SSID.

Go to **Settings** > **Wireless Networks** and click **+ Create New Wireless Network**. And the **Network Name (SSID)**, for example "Residents WiFi".

Select **PPSK without RADIUS** in the **Security** dropdown.

On the PPSK Profile, you need to add create and assign at least one PPSK user in order to create the SSID. Click on the menu and select the last item, **Create new PPSK Profile**.

The **Create New PPSK Profile** dialog opens. Enter a **Name**, such as "*Default*". in the **PPSK1** section, enter as **Name** something like "*Default PPSK*" and in the **Passphrase** input enter a long, difficult to guess Passphrase.

![](/files/qyoK7EXsY0F0fozj9Ubw)

Once you have create your default PPSK Profile, you'' return to the main screen, and select the profile just created in the dropdown **PPSK Profile**.

![](/files/z5Cceq0ifkzmzn5Js247)

Click **Apply** to save.

{% hint style="info" %}
Cusna implements an automatic VLAN management to segregate each resident traffic. Cusna uses the slot of VLANs 2000-4000 so you should avoid using these VLANs for any other purposes.
{% endhint %}

## Cusna setup (Controller mode)

#### Get the account hostname

To connect Cusna to your Omada instance account you need to get the **hostname** of your instance. You can easily identify the hostname form the URL base of your browser once you are logged in in your Omada account.

![](/files/ZRvOYHJ2rod44GLDlk2E)

In the screenshot above the hostname would be: ***omada.cusna.io:8043***. Do not enter https. Make sure to enter the port if you see it in your URL.

{% hint style="warning" %}
If your controller has a self-signed SSL certificate, APIs return an error, so the integration won't work.
{% endhint %}

{% hint style="info" %}
Oamda uses the user credentials to generate the tokens required to authenticate the APIS. We suggest creating a dedicated API User to connect to Cusna.

Go to Admin and click +**Add New Admin Account**. Select **Cloud User** as **Administrator** **Type** and **All** as **Site Privileges**.
{% endhint %}

#### Link Omada to Cusna

Log in your Cusna account and go to Settings. In the WiFi integration section, select TP-Link.

Enter the requested inputs:

* **Omada tenant hostname**: the hostname of your Omada instance
* **Username**: username of the Omada admin user
* **Password**: username of the Omada admin user

<figure><img src="/files/U8hqMcjchmWexBnudeGX" alt=""><figcaption></figcaption></figure>

## Cusna setup (Cloud mode)

#### Get the account hostname

To connect Cusna to your Omada instance account you need to get the **hostname** of your instance. You can easily identify the hostname form the URL base of your browser once you are logged in in your Omada account.

<figure><img src="/files/aqCEZgMxhggmU1ETwkrW" alt=""><figcaption></figcaption></figure>

With reference to the screenshot above&#x20;

1. take the hostname part: "**use1-omada-controller.tplinkcloud.com**"
2. transform it as follow adding the "api" string: "*use1-**api**-omada-controller.tplinkcloud.com*"
3. Copy the **OmandacId** value, which is the string right after the first "/": "*5492cc657ffb80e24e8afe386f8ed4bb*"

{% hint style="info" %}
Oamda uses the user credentials to generate the tokens required to authenticate the APIS. We suggest creating a dedicated API User to connect to Cusna.

Go to Admin and click +**Add New Admin Account**. Select **Local User** as **Administrator** **Type** and **All** as **Site Privileges**.
{% endhint %}

#### Link Omada to Cusna

Log in your Cusna account and go to Settings. In the WiFi integration section, select TP-Link.

Enter the requested inputs:

* **Omada tenant hostname**: the hostname of your Omada account as indicated above
* **OmandacId**: the id of your account as indicated above
* **Username**: username of the Omada admin user
* **Password**: username of the Omada admin user

<figure><img src="/files/sE9uxBnOrnZTcBbphMcq" alt=""><figcaption></figcaption></figure>

## Cusna setup (Open APIs mode)

#### Setup an API Client

In Global View or MSP View, go to **Settings** > **Platform Integration** > **Open API**. 2. Click  **+ Add New App**. The Open API dialog appears.

<figure><img src="/files/I7cMZXoEIdaZniCKIz1y" alt=""><figcaption></figcaption></figure>

Enter a name in the **App Name**, select the following options:&#x20;

* **Mode: Client**&#x20;
* **Role**: **Administrator**
* **Site Privileges**: **All**

Click **Apply**.

<figure><img src="/files/hrw708DF6hWWw65b8y5Y" alt=""><figcaption></figcaption></figure>

From the main page, copy the **Client ID** and **Client Secret**.

Click on the eye icon, to open the **View Open API** Attributes and copy the **Interface Access Address** and the **Omada ID**.

<figure><img src="/files/MeJT1qsm3Fhkt9dHPJab" alt="" width="375"><figcaption></figcaption></figure>

#### Link Omada to Cusna

Log in your Cusna account and go to Settings. In the WiFi integration section, select TP-Link and select Open API in the Controller Mode.

Enter the requested inputs:

* Interface Access Address:
* Omada ID:
* Client ID:
* Client Secret:

<figure><img src="/files/EsgWv8ZE026VHGiHAqQC" alt=""><figcaption></figcaption></figure>

## Operating Cusna

### Creating Networks

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the Site, WLAN and SSID to associate to the property.

![](/files/yan1KwMGKifpv5Z1WFC5)

### Creating Accounts

When you create a new Account, a new PSK user will be created in your Omada account with a predefined WiFi Passphrase. The user receives an activation email with the default passphrase and QR code, and a link to the WiFi Portal where he can change the passphrase.

{% hint style="danger" %}
To avoid synchronization problems, do not manage manually the PPSKs in the Omada interface
{% endhint %}


# Huawei - iMaster NCE-Campus

## iMaster NCE setup

First step, you need to create a Site and add your Device ([follow this guide](https://support.huawei.com/enterprise/en/doc/EDOC1100141254/c0c36c2b/creating-a-site)). In general, you would have a Site for each property.

**Enable PPSK on the site.**

1. Choose **Provision > Device Configuration > Site Configuration** from the main menu.\ <br>

   <figure><img src="/files/xH5a56L55awtbqseaD1i" alt=""><figcaption></figcaption></figure>
2. In the displayed window, select a site from the **Site** drop-down list in the upper left corner.
3. Choose the **Site Configuration** tab.\
   ![](/files/IkTEwps9EK3kPUWZOgM0)
4. Configure authentication points based on the device type **AP**
   1. Choose **AP** > **SSID** from the navigation pane, click **Create**, and configure basic information about an SSID.<br>

      <figure><img src="/files/tiWF4kwkUicSS6JsmA4G" alt=""><figcaption></figcaption></figure>
   2. On the Basic Settings step, enter an name for the SSID. Switch on the **Global DHCP address pool** option.
   3. On the **Security Authentication** tab, set **Authentication mode** to **Semi-open network**, select **PSK/PPSK/SAE/SAE-PSK**, and set **Key type** to **PPSK**. \
      Then, set **Encryption mode**, **Encryption algorithm** and **Escape policy**. \
      Leave the option **Automatic MAC address binding** disabled.\ <br>

      <figure><img src="/files/f1RyGucqzF5j85aom1p7" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
Cusna implements an automatic VLAN management to segregate each resident traffic. Cusna uses the slot of VLANs 2000-4000 so you should avoid using these VLANs for any other purposes.
{% endhint %}

## Cusna setup

#### Get the account hostname

To connect Cusna to your Huawei Cloud Campus account you need to get the **hostname** of your Cloud Campus account. You can easily identify the hostname form the URL base of your browser once you are logged in in your Cloud Campus account.

#### Create User with API access

You need to create a **User** with API access. To do so, go to **System**, **User Management**.

Click **Create New User**, the Create User wizard appears.

On the first step, Set Information, select **Third Party** as **Type**.

![](/files/gaLcpM1vRzoavkh9ad2s)

In the **Select Roles** step, make sure the add the role **Open API Operator** and **Tenant Administrator**

![](/files/e6YQulno7zj8KJ3oogRC)

#### Connect Cusna to Huawei Cloud Campus

Go to Settings in your Cusna account and select Huawei (Cloud Campus).

Enter the requested value;

* **hostname**\
  E.g. if your Cloud Campus URL is <https://weu.naas.huawei.com/>, enter "*weu.naas.huawei.com*"
* **username**
* **password**

![](/files/rH4CKzZ43YT97QNbnYY6)

Click **Setup**.

{% hint style="info" %}
You can change the Client ID and Client Secret in future, but you can't change the account hostname
{% endhint %}

## Operating Cusna

### Creating Networks

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the **Site** and the **SSID** that you have enabled on the Access Point of the related to property.

### Creating Accounts

When you create a new Account, a new PSK user will be created in your Cloud Campus account with a predefined WiFi Passphrase. The Resident receives an activation email with the default passphrase and QR code, and a link to the Resident Portal where he can change the passphrase.


# Dashboard

The main dashboard provides a comprehensive overview of the status of the WiFi service, and provide access to:

* Activity Logs
* Notifications and Alerts
* Network Health (for supported WiFi vendors only)

<figure><img src="/files/tJtOAucbwzrBpulpdp51" alt=""><figcaption></figcaption></figure>


# Managing Accounts

{% hint style="info" %}
The Accounts page is available for **MSP Managers**, **Organization Managers** and **Network Managers**.
{% endhint %}

The **Accounts** section allows to:

* [Manually create and provision new Accounts](#create-new-accounts)
* [Edit Account details](#edit-account-details)
* [Terminate Account WiFi service](#terminate-account-wifi-service)
* [Delete Accounts](#delete-accounts)
* [Change service auto-termination date and mode](#edit-service-termination)
* [Import accounts form CSV](#import-accounts-form-csv)
* [Managing Account devices](#managing-resident-devices)

{% embed url="<https://youtu.be/inWEQ6IUUF8>" %}

## Creating new accounts

Click **Add New Account** button on top of the screen.

Pick a **Network** form the Network dropdown.&#x20;

{% hint style="info" %}
Note: the Network cannot be changed later
{% endhint %}

Select the **Type** of account:

* **Tenants**: designed for long-term accounts, for example the tenants of an MDU or the teams/companies in a multi-tenant office building&#x20;
* **Visitors**: designed for temporary account, such individuals booking a room in a flex space for the day. By default, Visitors WiFi access is valid only until the end of the same day of the account provisioning.&#x20;
* **IoT devices**: designed to generate a PPSK to be used by a group of permanent devices that needs to communicate with each others, for example printers or security camera
* **Spaces**: designed to deliver PPSK aimed to br used in specific spaces, such as meeting rooms, where multiple devices and users must be able to collaborate on the same PAN
* **Group Members**: individuals who are part of a Group (for example a Team). Group members inherit certain configurations form the Group they belong to. For example, if VLAN assignment is enabled all Group members by default share the same VLAN. For certain vendors where VLAN management is not supported (e.g. Extreme) all Group Members share the same PSK.

If you are creating an account for a Space or IoT group, you have the option to either **automatically** generate a **passphrase** or enter it **manually**.

<figure><img src="/files/STrc0Fc8BG31hkaIZXhk" alt=""><figcaption></figcaption></figure>

Spaces and IoT group account are not associated with a WiFi Portal account so the Admin might want to manually pick a specific keyword.

Whenever you set a passphrase manually, before being able to create the Account you need to click the button **Check** next to the entered passphrase to verify that the passphrase is not already in use in the same Network.

Assign a **VLAN**. If you selected the option to manually assign VLANs in the [General settings](/service-management/general-options), you'll see a dropdown where you can pick a VLAN that has not been assigned to other accounts yet.

![](/files/RoY7jCg5I9ZH2GMSYJcM)

Enter the **Account Details.** The list depends on the Type of account your are creating and might include:

* Unit (optional)
* Port (optional - if Unit has been assigned the the [Port Management option](/service-management/general-options/service-options#units) is enabled)
* Building (optional)
* First name (or Reference name in case of Spaces and IoT devices)
* Last name
* Email address (note: email address must me unique in the account. If a matching email is found, the service will prompt an error)
* Phone number
* Internal account number (for internal reference)

For some vendors, you might have the option to manually assign a [Network Policy](/service-management/network-policies) to the Account. You can either chose to assign the Default network policy assigned to this Network or select one manually among those that have been already provisioned.

<figure><img src="/files/zD58KQd1XrH1DQR7BIdZ" alt="" width="375"><figcaption></figcaption></figure>

In the **Status** section, you can decide when activate and terminate the service.

<figure><img src="/files/qwgUMsORwuO3jBlBo8H7" alt="" width="375"><figcaption></figcaption></figure>

Select **Service active now** to immediately activate the service for the resident and send the activation email. If you want to activate the service on a future date, select **Schedule activation in the future** and enter the activation date.

In the Service deactivation mode select **Terminate manually**, to manually terminate the service for the account in the future. Otherwise, pick **Schedule stop date** and enter a date when the service will be terminated automatically.

## Edit Account details

Click on the name of account in the main Accounts list to open the Account edit screen.

{% hint style="warning" %}
You cannot change the Network assigned to the account.
{% endhint %}

Edit any of the fields in the Account Details section and click **Update** button to save the edits.

{% hint style="info" %}
If you edit the email address, a new activation email will sent to the account.  You can change the email only with another email that is not already assigned to other residents
{% endhint %}

## Terminate Account WiFi service

You can manually terminate the WiFi service of an active Account at any time.

Find the Account in the main table (using the search box). Click on the Action button to open the action dropdown and select **Suspend Service**. In the following pop-up confirm you want to terminate the service by clicking **Yes**.

<figure><img src="/files/dM4M5wHkdgc0CpK8EK1K" alt=""><figcaption></figcaption></figure>

## Delete Accounts

To delete one Account, click on the option menu on the table raw of the related account and select **Delete**. You can also find the same options in the Account details screen.

![](/files/LllS0pxrCO1fobSOAWje)

To delete one or more Accounts, find them in the main table, click the checkbox next to the reference name of the account. A new button Delete will appear above the table.

Click **Delete** to permanently delete the  account and terminate his service.

![](/files/jngJw87op5vfOm8MCSTc)

## Edit service termination mode and date

You can change at any time the way you will terminate the resident WiFi service.

Find the Account on the main table and click on this name. On the Accounts edit page go to the **Service** section and click **Edit**.

![](/files/jxe6Vtu4zDgrm6OlosG1)

### Import Accounts form CSV

You can import your existing residents in bulk from a CSV file.

Duplicate accounts (with the same email address) will be discarded.

The CSV file must contain the following columns:

* **firstName**: First Name (optional)
* **lastName**: Last Name (optional)
* **email** : Email Address (mandatory)
* **stopDate**: Account termination date (optional) - if empty, the account will be set to be terminated manually. Format: DD/MM/YYYY
* **passphrase**: WiFi Passphrase (optional) - if empty, the passphrase will be generated automatically
* **VLAN**: VLAN (optional) - if empty, the default VLAN mode configured in the general options applies
* **emailValidated**: indicate that the email is Valid. This filed MUSt be set to **True**.

[Download the CSV Template](https://e530a3a8f700b78738cfb414b7013de6.cdn.bubble.io/f1741948712403x824012272319282400/Cusna_import_template.csv?_gl=1*13plzbq*_gcl_au*MTUwNTgzMDgzNi4xNzQxMjQ5NTAz*_ga*NTI2ODQxNzc0LjE3NDEyNDk0ODE.*_ga_BFPVR2DEE2*MTc0MTk0MDc2MS42LjEuMTc0MTk0ODcxNS4yOS4wLjA.) to prepare your data for import.

<figure><img src="/files/h7GyUBrba8olvPcPk5hE" alt=""><figcaption></figcaption></figure>

### Managing resident devices

For certain WiFi vendors (e.g. Meraki) Cusna is able to track all the devices used by each resident and list them in the resident profile page as well as in the Resident Portal.

<figure><img src="/files/lCwJGerKScSWCDtol7eB" alt=""><figcaption></figcaption></figure>

Depending on the WiFi vendor capabilities, you can also Block and Allow each individual device.


# Groups

Cusna Groups allows to simplify operations and unlock additional capabilities when the service is delivered to different user personals (for examples companies operating in a multi-tenant office building, or students and teachers in a Campus).

<figure><img src="/files/WJI678AcD1AQIyIzYXTQ" alt=""><figcaption></figcaption></figure>

If you account doesn't have Groups enabled, go to **Setup**, **General** and enable **Groups**.

<figure><img src="/files/khnqcwoZeIa5mTQ63qob" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Once enabled, you can disable Groups only if you don't have any Groups in your account.
{% endhint %}

### Network segmentation

In order to simplify collaboration among team members, Cusna can assign all Group Members to the same **virtual network**, making sure their devices can exchange traffic securely but virtually separated form the traffic of other groups or individuals. To achieve traffic isolation for Groups, Cusna relies on VLANs or other techniques offered by the specific WiFi vendor.

### Shared vs Individual PSKs

Whenever supported by the WiFi network vendor, Cusna aims to provide each Group member a **personal PSK**. The advantage of this approach is that you can remove one individual group member without affecting the service of remaining members. Imagine the case of a Company in a multi-tenant office building. If all employees share the same PPSK, when an employee leaves the company you would need to change the PPSK for everybody if you want to block access to ex employees.

For some WiFi vendors (see [compatibility table](/wifi-integration/summary-of-supported-wifi-vendors)), instead, Cusna assign to each group member the same PSK defined on the belonging group. However, each member has still an individual account on Cusna to simplify SSO integration with Cloud Identity Providers.&#x20;

You can check if your account is set to use **Shared PSKs** or **Individual PSKs** for Groups in the Group setup section, in the General settings page. This setting might not be editable depending on the WiFi vendor you are using.

<figure><img src="/files/HGqkwzbzoAx6ecIJSFoD" alt=""><figcaption></figcaption></figure>

### Bulk operations

Moreover, by using Groups, you can simplify **bulk operations** on group members:

* **deleting** a Group automatically deletes all accounts that belong to that group
* when using VLANs, **updating the Group VLAN** automatically updates the VLAN of each single member
* if you set up **Group Start Date**, all members accounts will be activate automatically only on that date
* if you se up a **Group End Date**, all accounts member of the group will be automatically terminated on that date

## Automatically created Group

Some integrations create Group automatically by default. For example, when a user authenticating via an external SSO belongs to a team/company, Cusna creates automatically a matching Group.

Each IdP integration has an option to decide if enable or not auto-VLAN management for users and Groups created via the integration.

See an example below:

<figure><img src="/files/iY3e0MjRjdsvWgOfU5Cx" alt=""><figcaption></figcaption></figure>

## Global Groups

In some cases, Groups are created without being associated to a specific Network. This happens when Groups are created automatically as part of a self-onboarding integrated with an external Identity Providers and [Roaming](broken://pages/G4PYJJRGHErTtwYYagmi) is also enabled. The Group, for example, may relate to a team whose members needs to be able to access the network in different Networks. In this case, the Group is not assigned to a specific Network.

## Managing Groups manually

### Creating Groups

When you create a group you have to enter the following inputs:

* **Network**: Groups are valid at the Network level. This setting is optional, if you leave empty the group becomes a [Global Group](#global-groups)
* **Reference name**
* **VLAN** (optional): if you chose to set the VLAN manually, a dropdown menu shows the list of VLANs not already in use by other accounts in the same Network (or in the entire Organization if you are working with [Roaming](broken://pages/G4PYJJRGHErTtwYYagmi) mode active). If you select **Auto**, the VLAN will be assigned automatically to the group.

If your account is configured to use [Shared PSK](#shared-vs-individual-psks) for all Group Members, in the setup screen you can set the **Group Passphrase**, choosing among

* **auto**: the passphrase is generated automatically and will be visible in the Group settings once the group is created
* **manually**: you can manually enter a passphrase and verify its validity before creating the group

The **Automatic Account Suspension** dropdown allows you to choose options for automatically suspending accounts in the Group based on predefined rules.

<div align="left"><figure><img src="/files/X44hgakSuklOlC0ykpX7" alt="" width="375"><figcaption></figcaption></figure></div>

* **Suspend on a Specific Date**: Allows you to suspend all accounts in the group on a set date you specify when choosing this option.
* **Suspend Yearly on a Selected Date**: Suspends all accounts in the group on a specified date each year. When selected, you can choose the specific day of the year for suspension.
* **None**: Leave this option unselected to apply no suspension policy.

{% hint style="info" %}
In cases where suspension policies are set at both the Group and the global levels ([Service Options](/service-management/general-options/service-options)), the policies configured at the Group level override and
{% endhint %}

### Editing Groups

If you edit a Group **VLAN**, all accounts will be updated accordingly.

If you edit a Group **Termination Date**, all accounts member of the group will be updated accordingly.

### Deleting Groups

If you delete a Group, all accounts members of the group will be deleted automatically.


# Managing Networks

## Networks overview

In the Networks page you have the list of all the Organization networks.

You can click on a network to edit it, or click the button "New Network" to start the creation of a new Network.

<figure><img src="/files/r8dZ7dnFaqP31JXs9W3i" alt=""><figcaption></figcaption></figure>

## Creating a Network

On the main Networks list page, click **New Network** button.

### Network details

In the **Network details** section add:

* **Name**: reference name for the Network
* **Address** 9optional): address of the Network, in case it corresponds to a physical location

### Network Managers

In the **Network Manager** section, you have the option to invite a Network Manager to Cusna to manage independently the accounts of the Network.

Click **Add New** button and enter the Manager detail to create a new Manager account.

Select **Select existing** for inviting an existing manager to manage also this Network.&#x20;

### WiFi configuration

In this section you need to configure some technical parameters that depends on the WiFi vendor you linked your Cusna account with.

The settings of this section are specific to each vendor.

#### VLAN Pools

For vendors that support VLANs as a method to creating Personal Area Network, this section offers the ability to define the VLAN pool form where the VLANs are selected.

<figure><img src="/files/qaHt4Ewcmu6srXsNDGdC" alt="" width="375"><figcaption></figcaption></figure>

### WiFi Portal branding

In this section you have the option to personalize the branding of the WiFi Portal

* **WiFi Portal header**: text that appears on top fo the WiFi Portal page..
* **Intro message**: message that appears right below the header in the portal.
* **Help text**: text that appears on the bottom of the WiFi Portal page. Can be used to inform residents on how to get help

<figure><img src="/files/imcwBcC0yqT23YIkmz4C" alt=""><figcaption></figcaption></figure>

## Editing a Network

Form the main table, you can select a network to edit some of its cofnigurations.

{% hint style="danger" %}
Changing the WiFi settings is not advisable as it might leave existing Accounts out of sync. However, we understand mistakes happens, especially durign the initial setup phase, so these options are editable. Use it with caution.
{% endhint %}


# Network Managers

Network Managers can be invited by Organization Managers while creating a new Network or later while editing a Network.

One Network Manager can be assigned as manager of multiple Networks.

Once invited, new Network managers receives an invite email and they are prompted to create their own password. Existing Network managers that are added as managers to existing Network and notified via email.

Once logged in, Network managers can see only some of the menu and features that Organization manager see and in general they only see data and settings related to the Networks they are managed of.

In particular they see:

* **Home** (without the widget reporting data about Networks )
* **Accounts**: Networks Manager can only see Account related to Networks they manage and they can create and edit only accounts of those Networks.


# Units

{% hint style="info" %}
At this time, Unit are supported only on Meraki, Extreme and Ruckus networks.
{% endhint %}

A **Unit** represents a living space of a **Network -** such as an apartment or a room in a multi-dwell environment - associated to a Tenant. You can associate to the Unit one Access Point.

When creating an Account, you can then assign the Account to a specific Unit, and the Access Point Ethernet port will be configured to be in the same Personal Area Network as the clients connecting using the PSK associated to the resident.

### How to configure and use Units

If supported in your account, you can enable **Unit** management in your **General** options page.

<figure><img src="/files/F0ZlWN94IktmO3gD9YPq" alt=""><figcaption></figcaption></figure>

By enabling Unit management, you'll find a new sub-menu in the Network menu group.

<figure><img src="/files/5l3Ma1vBg0enF4iJic4w" alt=""><figcaption></figcaption></figure>

In the main Units page you see the list of all Units, which can be filtered by Network. By click the button Add, you can create a new Unit specifying:

* the **Network**
* a reference **Name**
* an optional **Floor** number,  just for inventory purposes
* an Access Point

By **deleting a Unit**, all the ETH ports of the Access Point associated to the Unit will be disabled. &#x20;

### Managing Account

If Units management is enabled, when crating an Account of type "Tenant" you have the option to associate the Resident to one of the Units of the Network the Account belongs to.

<div align="left"><figure><img src="/files/4S9CgSWEr3xiGzvI76RN" alt="" width="375"><figcaption></figcaption></figure></div>

You can also associate a Unit to existing Account that do not have a Unit assigned yet.

When the service of an Account is terminated or the Account is deleted, all the ETH Ports of the Access Point associated to the Unit the Account was associated with will be disabled.

Changing the Passphrase associated to the Account does not affect the reachability of the devices connected via the ETH ports of the AP. &#x20;

#### Enabled Ports

When the Port Management feature is enabled, for supported hardware only (at this time Meraki only), you can set which ethernet ports of the Access Point are enabled or disabled.

<figure><img src="/files/s3VzZDYetbTGpLQ6Pc14" alt="" width="375"><figcaption></figcaption></figure>

## Under the hood

Learn the details of how ti works for the different WiFi vendors

<details>

<summary>Meraki</summary>

Currently, only MR36H access points are supported.

Whenever you link a Location to a Meraki Network, Cusna automatically initializes a default Port Profile with all ports disabled used as a&#x20;

Whenever you create a Unit, Cusna creates a related Port Profile in the Network corresponding to the Location the unit belongs to. By default, this Port Profile has no WPN ID assigned to the ports.

As soon as a Unit is associated to an Account, the Port Profile associated to the Unit is updated assigning to ports the same WPN ID as the one associated to the Account.

</details>

<details>

<summary>Extreme Networks</summary>

Currently, only AP302W access points are supported.

Whenever you initialize an Account and associate it to a Unit, Cusna automatically assign the ETH ports of the AP to the Private Client Group associated to the Account

</details>

<details>

<summary>Ruckus SmartZone (beta)</summary>

Whenever you initialize an Account and associate it to a Unit, Cusna automatically configure  the ETH ports of the AP with the same VLAN associated to the Account. If the Account is a Group Member of a Group with a VLAN, the VLAN of the Unit takes priority.

</details>


# General options

Open the **Setup** menu group and select **General**. This page contains configuration options related to:

* General [WiFi Service Options](/service-management/general-options/service-options)
  * VLAN management
  * Enabling Groups option
  * Enabling Units option
  * Enabling Roaming option
  * Enabling Secure WiFi options<br>
* [Organization details](/service-management/general-options/organization-details)
  * Company data
  * General branding
  * Email sender


# Personal Area Networks (PAN)

{% hint style="info" %}
This option might not available for some vendors. For example, when using Meraki cloud iPSK, PAN is achieved relying on the native WPN artifact and there is no need for any configuration in this section.
{% endhint %}

In the **Setup** **> General** page, the card Personal Area Networks (PAN) provide the configuration options to enable the use of Personal Area Networks..

Personal Area Networks allows to create virtual network segment where all clients of the same Account are in network among each other but isolated from other users.

### Dynamic PAN orchestration

Under the **Dynamic PAN orchestration** section you can configure the default strategy and to assign and manage Personal Area Networks fo Accounts. &#x20;

PAN can be achieved either via **L2 VLANs** or, when supported, leveraging proprietary **L3 segmentation techniques** (such as WPN in Meraki, UDN in Cisco or PCG in Extreme Networks). &#x20;

<figure><img src="/files/8lLU1T5Nqr3PTjrDLd8Q" alt=""><figcaption></figcaption></figure>

The first option allows to enable or disable the **Dynamic PAN** orchestration. Form the dropdown you can select between:

* **Yes** - Automatically assign PAN to new Accounts
* **No** - Do not assign PAN to new Accounts

If the WiFi vendor connected to your Cusna account supports multiple **PAN technologies** (VLANs or L3 proprietary solutions), a dedicated dropdown allows to select what PAN technology to use:

* L2 (VLANs)
* L3 (the name displayed changes based on the WiFI vendor)&#x20;

Next, the **PAN Assignment Policy** allows to set a rule to define which PAN assign to the Account, selecting among the following options:

* **Unique per Account**: the default option assign a unique PAN to each Account
* **Inherit form Group**: with the option, if the Account is assigned to a Group, and the group has a VLAN or L3 segmentation attribute assigned, the Account inherits the PAN form the Group.\
  *If the Group has not VLAN or L3 tag, the Account get assigned with a unique PAN.*
* **Inherit form Unit**: If the "[Unit](#units)" option is enabled, you can assign a PAN to an Account based on the PAN cofnigure on the Unit assigned to the Account.\
  *If the Account is not assigned to any Unit or the Unit does not have a PAN configured, a unique PAN is assigned to the Account.*&#x20;

### **Free up VLANs upon service termination**

This option removes the VLAN assigned to an Account upon service termination, making it available again in the associated VLAN pool.

<figure><img src="/files/bPsejZf8kQvRdPpKL5Cc" alt=""><figcaption></figcaption></figure>

### Roaming

In some cases, you might want your users to be able to connect with the same WiFi passphrase in all your Networks.

{% hint style="info" %}
Some WiFi vendors allows to setup the PPSK configuration in such way that the PSKs works on multiple sites. For example, Juniper Mist has an option that allows to select if PSKs have a Site or Org level scope. In Cambium cnMAestro you can create one WLAN profile and assign it to multiple networks (AP groups).&#x20;

Refer to the section related to the configuration of the WiFi vendor to get more details on how to configure the network to support this use case.
{% endhint %}

In the **Setup**, **General** page, find the option **Roaming**.

<figure><img src="/files/pdZrD7iLMVhqzO9lE2Nl" alt=""><figcaption></figcaption></figure>

When enabled, Cusna dynamically assigns a unique VLAN to each account in the organization. This means that there cannot be two account with the same VLAN in the same organization. When the user connect with its PSK to the WiFi of any Network, the same VLAN will be used to tag his traffic.

When Roaming community option is disabled, the automatic VLAN assignment works on per Network scope. When a new account is created, either manually or automatically via the integrations, Cusna assign a VLAN that is not used already in the Network where the account is initialized.

{% hint style="danger" %}
Once enabled, the Roaming  option cannot be disabled. Switching on and off this option could cause duplicate assignment of VLAN to accounts.
{% endhint %}


# Service Options

In the **Setup** **> General** page, the card **WiFi Service Options** provide additional optional configuration and options that can be enabled on the account.

### Groups

This options allows to enable or disable [Groups](/service-management/groups) management on the account. This option is available only for WiFi vendors that support Groups

<figure><img src="/files/QBEDBZxY8kiBBAtMB31T" alt=""><figcaption></figcaption></figure>

### Units

This options allows to enable or disable [Unit](/service-management/units) management on the account. This option is available only for WiFi vendors that support Unit based assignment of Access Points

<figure><img src="/files/wSxNtahaCsVBN9Z11UFU" alt=""><figcaption></figcaption></figure>

For supported vendors only, you may also have the option to enable the ability to asign different ports of the same Access Point in the Unit to different Accounts. To enable this capability you need to turn on the option **Assign individual ETH Ports to Accounts**.

<figure><img src="/files/W71Icpi8I1LjRGl2OlC1" alt=""><figcaption></figcaption></figure>

### Passphrase Options

This option allow to define options related to the WiFi passphrase automatically generated by the system

<figure><img src="/files/DQY9KDYBxXPyK50Z1TVg" alt=""><figcaption></figcaption></figure>

* the length of the WiFi passphrase&#x20;
* the set of characters used to generate the passphrase

{% hint style="info" %}
The default character set is optimized to exclude easily confusable characters:\
23456789ABCDEFGHJKLMNPRSTUVWXYZabcdefghijkmnopqrstuvwxyz
{% endhint %}

### Automatic service termination

This feature enables the configuration of options to automatically suspend All accounts.&#x20;

{% hint style="info" %}
You can defined Group based automatic suspension policies on specific [Groups](/service-management/groups). Suspension policies set on the Group level override ant takes priority over the global setting configured in this section for Accounts belonging to those Groups.
{% endhint %}

The option **Suspend after set number of days form activation** allows administrators to specify the number of days after activation when an account will be automatically suspended.

<figure><img src="/files/PJtiLylYGsrfoVCQ4Bb5" alt=""><figcaption></figcaption></figure>

The option **Suspend yearly on selected date** allows to suspend all Accounts automatically every year of a specific date.

<figure><img src="/files/pmnWXd8h3gbQHdIVXyqO" alt=""><figcaption></figcaption></figure>

### Service termination notice

This option allows to send residents an email a configurable number of days before their service is scheduled for automatic termination.

<figure><img src="/files/txEBmNgPXibP13gaigjb" alt=""><figcaption></figcaption></figure>


# Organization details

In the **Setup** **> General** page, the card **Organization details** provide additional optional configuration regarding the company’s  data, look and feel and communication channels.

<figure><img src="/files/5oKj13u4YZEyMaNjL4CO" alt=""><figcaption></figcaption></figure>

In this section, you can change the name of your organization (**Organization name**) and retrieve the **Organization ID**, that you may need to setup some integrations and use the APIs.

In the compliance section, you must enter the URLS of your **Privacy Policy** and **Terms of Use**. Accounts will be prompted to acknowledge them on their first access to the WiFi Portal

{% hint style="info" %}
If you do not have your policies published online, contact us to enable the upload of the agreement texts directly in the Cusna dashboard.&#x20;
{% endhint %}

You can upload you organization **Logo**, and it will be used to&#x20;

* personalized the Cusna dashboard
* as default logo in the WiFi Portal if no other logo has been uploaded on the specific Network the portal refers to

The **Accent color** will be used as default value to personalized the WiFi Portal in case there it is not configured at the Network level.<br>

***

The **Custom email sender** option, allow to customize the email address used to send transactional service communication to the end users.

{% hint style="info" %}
This option is disabled by default. Contact our support team for more info.
{% endhint %}


# Network Policies

For some WiFi vendors, you need to setup Network Policies before creating Tenants. The section Network Policies in the Integration page appears automatically based on the WiFi vendor you set up.

## Meraki

While creating an iPSKs, Meraki require to set a Group Policy. By creating Network Policies, Cusna automatically creates and keeps in sync the Group Policies in the Meraki account for all the network involved (one network per each Network)

<figure><img src="/files/juNt2TXUzwK8tAdF7HzM" alt=""><figcaption></figcaption></figure>

Click **Add a new Policy**.

The New Network Policy dialog appears. Fill the form

* name: reference name for the policy (e.g. "Default")
* bandwidth downlink: max downlink spee in Kbps
* bandwidth uplink: max downlink spee in Kbps
* VLAN

<figure><img src="/files/K5adpnjb3ADP1KOhbapT" alt="" width="375"><figcaption></figcaption></figure>

Click **Save**.

The Network Policies create appears in the list.

<figure><img src="/files/fZpqRoGTtJNsgbfNsCni" alt=""><figcaption></figcaption></figure>

### Using Network Policies

Once you have created network policies, you can use them in different ways.

First of all, whenever you create a Network, you'll be required to assign a "default" network policy. This is the policy that will be assigned by default to Accounts associated to that Network whenever the network policy is not specified on the Account during initialization.

<figure><img src="/files/oj6xctuecXqxLeKXxzkJ" alt=""><figcaption></figcaption></figure>

When creating a new account manually, you can opt to use the Network default network policy, or you can manually pick one of those you have already initialized in setup.

<figure><img src="/files/ypvp7O3U8cbGwZFkDwRc" alt="" width="375"><figcaption></figcaption></figure>

You can also assign a Network Policy to a group. This will be assigned to all Accounts of type "*group member*" assigned to this group.

<figure><img src="/files/icl4PYc5GBZahd58yJkr" alt="" width="375"><figcaption></figcaption></figure>

Finally, you can also assign Network Policies individually to each Accoutn when creating or managing them form the dashboard.

### Troubleshooting Network Policies

Network Policies sync with equivalent entities in the network management system. For example, each Network Policy is deployed as a Group Policy in each Meraki Network connected to a Cusna Network.

In order to check the matching Group Policies in the Meraki network, you can click the info icon <img src="/files/dXE7ZaFotOc0KvnQk7lI" alt="" data-size="line"> on the Network Policy card. A dialog will show the list of the matching Group Policies in each Meraki Network.

<figure><img src="/files/zQhHioLuDjUQebZN4SaT" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
In case a Group Policy already exists in the Meraki Network with the same name assigned to the Network Policy in Cusna, Cusna will attempt to create it with a slightly different name, adding a numerical suffix to the name (e.g. \<policyname>\_1)
{% endhint %}

{% hint style="info" %}
All policies initializd on the network are forced with the prefix "**CU-**" in front of the name you select.
{% endhint %}


# WiFi Portal & Onboarding

Residents can self-enroll in the service on the WiFi Portal.

Each Network has a WiFi Portal with a **dedicated URL**, that you can copy either in the Network summary table or in the detail page of each Network.

<figure><img src="/files/9sbjOi1rRtouI2JEHvCZ" alt=""><figcaption></figcaption></figure>

The URL can be distributed to Residents by different channels:

* QR codes
* email
* existing tenant portals
* dedicated SSID with captive portal

When Tenants are initialized manually via the Cusna dashboard, they receive a notification email that confirm they have been activated and it includes the link to the WiFI Portal related to the Network associated with their account.

{% hint style="info" %}
You can optionally publish the WiFi Portal as a dedicated **onboarding SSID** on your WiFi network. [Learn more](/service-management/wifi-portal-and-onboarding/wifi-portal-distribution).
{% endhint %}

{% hint style="info" %}
If you prefer to distribute one single URL, you can enable the **Universal WiFi Portal URL**. [Learn more](/service-management/wifi-portal-and-onboarding/wifi-portal-options).
{% endhint %}

You can also enable a [Universal WiFi Portal URL](/service-management/wifi-portal-and-onboarding/wifi-portal-options#universal-wifi-portal-url), a single URL that can be distributed to all residents. n the first page, they will have to pick the locaiton where they want to login.

## Resident onboarding experience

Residents might receive an Activation Email with the link to the WiFi Portal, similar to the following one, when they are manually provisioned form the Cusna dashboard.

<figure><img src="/files/3CLoaLh2D48JhPlVL6ax" alt="" width="375"><figcaption></figcaption></figure>

When they visit the **WiFi Portal page**, they might have multiple options to identify themselves:

* Passwrodless login (must be [enabled in the Access Control options](/service-management/wifi-portal-and-onboarding/access-control-options#passwordless-login))
* SSO authentication with an Identity Provider (must be [enabled in the Access Control options](/service-management/wifi-portal-and-onboarding/access-control-options#identity-provider-options))

#### Passwrodless login

In this case, the user is prompted to enter their email address.

If the email address exists and it is associated to an valid and active account, they will receive an email containing the **magic link** to access the WiFi portal in one click.

<figure><img src="/files/ljqCulnirwB4OdxlwwVu" alt="" width="375"><figcaption></figcaption></figure>

By clicking the Login button, the user lands directly in the WiFi Portal already authenticated.

#### SSO authentication

In case an integration with a cloud IdP has been enabled in the [Access Control options](/service-management/wifi-portal-and-onboarding/access-control-options#identity-provider-options), the user has the option to select this method. The user is redirected to the external identification page of the IdP and upon successful identification till return to the WiFi Portal to continue the onboarding process.

### First access

On the first access to the portal, users are invited to accept the [T\&C](/service-management/general-options/organization-details) and other personal attributes as configured in the [Access Control](/service-management/wifi-portal-and-onboarding/access-control-options#contact-profile-collection) options (such as first name, last name, company).

<figure><img src="/files/1WQFlpywL5frV2EmyrSt" alt="" width="375"><figcaption></figcaption></figure>

Once accepted the T\&C, the user lands on the WiFi Portal home page.&#x20;

When [Billing](/add-ons/billing) is enabled, the user might be prompted to select a Subscription and provide payment information before being activated and get access to the personal PSK.

### WiFi Portal home screen

The home page contains different panels that might be visible or not depending on the options configured in the Cusna dashboard. In particular:

* **Personal WiFi passphrase**: this section is always visible and provides the user the name of the PSK network and the personal PSK. The user can&#x20;
  * re-generate the passphrase (if enabled as option in the [WiFi Portal settings](/service-management/wifi-portal-and-onboarding/wifi-portal-options#allow-users-to-re-generate-their-wifi-passphrase)),&#x20;
  * view a QR code that can be scanned to connect directly to the network
  * and copy the passphrase to the device clipboard
* [**Passpoint**](/service-management/wifi-portal-and-onboarding/access-control-options#passpoint)**:** if Passpoint is enabled and the portal is opened on an Passpoint compatible device, this panel offer the option to directly download a Passpoint profile that works on the same secure WiFi network
* [**Guest WiFi**](/service-management/wifi-portal-and-onboarding/wifi-portal-options#allow-users-to-create-a-wifi-passphrase-for-guests): if enabled in the general options, the user can enable a dedicated passphrase that can be provided to guests
* [**Your Devices**](/service-management/wifi-portal-and-onboarding/access-control-options#allow-users-to-register-legacy-devices): if enabled, allows users to manually provision devices via their MAC address

### Demo

<figure><img src="/files/68m0ccsNphZwnBSyRQTw" alt=""><figcaption></figcaption></figure>


# Access Control options

Open the **Setup** menu group and select **Onboarding**. In the **Access Control** section, you can find all the options to control the way users can signup and login into the service via [WiFi Portal](/service-management/wifi-portal-and-onboarding).

***

### **Passwordless Login**

**Passwordless Login** allows to enable the option to identify existing users by means of their email address. If the email address is associated to an existing Account, the user will receive a magic link via email that allows to access the WiFi Portal in one click. This option is automatically enabled when the Email Domain Whitelist option is enabled.

<figure><img src="/files/Y2dexZvdybUYW3sMnVYH" alt=""><figcaption></figcaption></figure>

### **Email domain whitelist**

The **Email domain whitelist**, allows all users whose email address contains any of the domain listed in this configuration, to sign-up directly in the WiFi portal by simply entering their email address and clicking the magic link sent to their email. If they click the link within 5 minutes, they'll enter in the WiFI Portal onboarding wizard, including the opt-in to privacy policy, fill in of minimum set of attributes required and, if enabled, going trough subscription plan selection and payment setup.

If the integration with an IdP that supports multiple group has been configured in the Setup page, this card includes also the IdP configuration options. These options might include:

* Label of the button that appears in the WiFi portal (e.g. "Login with your university account")
* Group Mapping rules: they allow to automatically map Groups configured in the IdP with Groups previously created in Cusna.

<figure><img src="/files/OujW58ucj6aQ0NxqYEtW" alt=""><figcaption></figcaption></figure>

### **Account registration**&#x20;

The **Accounts registration** option allows to define the minimum set of account attributes that are requested to the users when they enroll into the service via the WiFI Portal the first time.  Attributes that are available already trough the IdP integration are not asked again to the end users if they are already available.

<figure><img src="/files/wyshZRpyyNFFhqhmLpIE" alt=""><figcaption></figcaption></figure>

Among the available options, you can require users to select a **Unit**. The Unit dropdown displays a list of all Units within the Location the user is registering for, excluding those already assigned to other residents (regardless of their service status).

If the Phone Number is included among the profile attributes, you can require users to verify it via an OTP sent through SMS to their phone number. This option is available only if the Twilio integration is properly configured on the Integration page.

<figure><img src="/files/iQ8RxhR4z2NQmXkkPMCD" alt="" width="375"><figcaption></figcaption></figure>

### **Identity Provider options**

If you have integrated an external **identity provider**, this section also show its configuration options. First of all, you have the option to **enable or disable**  the SSO option on the WiFi Portal.&#x20;

You can also customize the label fo the button that appears to users in the WiFi portal, editing the **Login button Label** input.

Depending on the specific IdP, you might have additional other options, such as:

* [Group mapping](/cloud-identity-platforms-integrations/enterprise-cloud-idps/group-mapping)

<figure><img src="/files/bwXl1kvz1pVzMh4750nJ" alt=""><figcaption></figcaption></figure>

### Allow users to register legacy devices

This option enabled users to add their own personal devices MAC addresses in the WiFi portal. Such devices are authenticated via MAC Authentication on a dedicated SSID properly configured.

{% hint style="info" %}
If you do not see this option in your account, contact us to enable it.
{% endhint %}

<figure><img src="/files/kZE3vcXZblDyC1OXapJj" alt=""><figcaption></figcaption></figure>

### Passpoint

This option allow users to download a Passpoint profile on their compatible devices form the WiFi Portal. The Passpoint profile will autonomically connect provisioned devices to a dedicated SSID that must be properly configured.

{% hint style="info" %}
If you do not see this option in your account, contact us to enable it.
{% endhint %}

<figure><img src="/files/fLIBd5W70dYmnBWDPOQm" alt=""><figcaption></figcaption></figure>

### Automatic service suspension

This option allows you to define criteria for automatically suspending an account's service. Multiple options may be available, including:

* **Max active period**: In this case, you specify the maximum duration (in days) that an account remains active after activation.

<figure><img src="/files/XmJ37DA46w6ilh4rNMcg" alt=""><figcaption></figcaption></figure>


# WiFi Portal options

Open the **Setup** menu group and select **Onboarding**. In the **WiFi Portal** section, you can find some options regarding the default behavior of the WiFi Portal across all your Networks.<br>

***

### **Universal WiFi Portal URL**

The **Universal WiFi Portal URL** is an option that allows to generate a single onboarding portal URL to simplify its distribution. Users are prompted to select their Network on the first screen

<figure><img src="/files/Qx398E13P9nlXiKzinGC" alt=""><figcaption></figcaption></figure>

### **Allow users to re-generate their WiFi Passphrase**

The **Allow users to re-generate their WiFi Passphrase** option will enable the possibility for tenants to changer their passphrase on the Tenant Portal.

<figure><img src="/files/NxTruqZBjm7YZ1NVLj5O" alt=""><figcaption></figcaption></figure>

### **Allow users to create a WiFi Passphrase for guests**&#x20;

The  **Allow users to create a WiFi Passphrase for guests** option will enable an option it the WiFi portal where the user can enable/disabile a dedicated passphrase that can be provided to guests.

<figure><img src="/files/FLZfx2cat4Rc5ndVo8qn" alt=""><figcaption></figcaption></figure>

### **WiFi Portal Taxonomy and contents**

The **Taxonomy and contents** section allows to personalize some terminology and contents presented in the WiFi portal, including:

* The name used to refer to the WiFi Portal in the email communications
* The title presented in the initial Login page of the WiFi Portal
* The instructions prompted under the passwrodless login option

<figure><img src="/files/EZXGz86xHyhQKzyWnQ8D" alt=""><figcaption></figcaption></figure>

### **WiFi Portal Custom Advanced Styling**

The **WiFi Portal Custom Advanced Styling** is an option that allows to further customize the look and feed of the porta with custom CSS. This option is disabled by default, reach out support team for more info.

<figure><img src="/files/3qoYmFUGzAdejlSaNzlU" alt=""><figcaption></figcaption></figure>


# IoT Devices Authentication

{% hint style="danger" %}
This functionality is in beta access only. Contact our team to learn more.
{% endhint %}

In some cases, legacy headless devices cannot be easily connected to the WiFi by mean of a PSK, either because it is not supported by the device or because it might be too difficult to configure.

In such cases, devices can be manually provisioned for MAC Authentication.

### Device Onboarding

Users can find a dedicated card in their WiFi Portal called **Your Devices** where they can add and manage their personal IoT devices

<figure><img src="/files/gUkNKrY5Hu9VreEUl3we" alt=""><figcaption></figcaption></figure>

Clicking on the link "**How to find your device MAC address**" opens a screen with step by step instructions for the major streaming, gaming and assistant devices.

<figure><img src="/files/CFoBc11RB249mzpkBbgC" alt="" width="375"><figcaption></figcaption></figure>

Adding a devices only requires to specify

* a reference **Name**
* the **MAC address**

<figure><img src="/files/T7hH7zJsrXo8L17ApLAA" alt="" width="375"><figcaption></figcaption></figure>

### Setup

You can enable manual IoT device provisioning form the [WiFi Portal options](/service-management/wifi-portal-and-onboarding/access-control-options#allow-users-to-register-legacy-devices) , enabling the toggle for the option "**Allow users register headless devices**"

In order to allow devices to authenticate via MAC authentication, you need to create a dedicated SSID (for example named "*IoT devices*") and configure it to support MAC authentication. RADIUS server parameters and vendor-specifc instruction are provided on demand by our support team.

When this option is enabled, the admin is prompted to specify which is the SSID dedicated for this service when setting up Networks, in the **IoT Network SSID** field (this field can be a dropdown or a simple input depending the WiFi vendor connected in the account)

<figure><img src="/files/JA0sxkrnkbqYlsGDZl6B" alt=""><figcaption></figcaption></figure>


# WiFi Portal distribution

You can share you **WiFi Portal URL** to residents in different ways, such as email or QR codes.

An effective way to make the portal self-discoverable with minimum effort is to publish the portal on a dedicated onboarding WiFi network. For example, you can name it "Resident WiFi onboarding".

When connecting to the network, users are redirected to the authentication page.

<figure><img src="/files/8764VKcMGtMuV1cr4NtN" alt="" width="375"><figcaption></figcaption></figure>

Once provided their email, the land on the confirmation screen as usual. With some WiFi vendors, the user is also authenticated on that WiFi network with an allowance of 5 minutes, in order to provide the connectivity while checking the email.

<figure><img src="/files/RemAxbkffdGZ04cLeUJu" alt="" width="375"><figcaption></figcaption></figure>

### Configuring the captive portal

To configure the onboarding portal as a captive portal, you simply need to publish the URL of your Network WiFi Portal that you can copy form the dashboard,.

Make sure to add in the walled gardens the domain: \*.cusna.io

#### Special utility for Meraki

If you are using Cusna with Meraki, you can automatically setup your SSID in a few clicks without even using the Meraki dashboard.&#x20;

At the bottom of a Network page, you can find the following card:

<figure><img src="/files/4zbsJXyz1RQSrimUPzbX" alt=""><figcaption></figcaption></figure>

Click **Setup** and a popup appears.

<figure><img src="/files/e6GqxJivOOMTrqYyfKsj" alt="" width="375"><figcaption></figcaption></figure>

Select the **SSID** you want configure, edit the **SSID** **name** and click **Configure**.&#x20;

Cusna will automatically configure the SSID with the proper parameters and publish it.


# Visitors (beta)

{% hint style="info" %}
This is a beta feature. Contact us if you are interested.
{% endhint %}

## Use Case

Daily Visitors or external visitors than than need an extended temporary access have now the option to self-onboard via the WiFi Portal.

Daily Visitors gets temporary access until the end of the day and then get automatically disabled.

You can also provide visitor the option to request an access extension, specifying a reason and a desired date. Admins will be notified and can handle the request by denying or grating the extension.&#x20;

## Setup

Go the **Setup** > **Onboarding** page and enable the option **Allow Visitors to Self-Onboard**.

<figure><img src="/files/PV4ZvHXx2hSutIZ6oA2p" alt=""><figcaption></figcaption></figure>

In the **Visitors Registration Attributes**, you can specify the list of perosnal information that you want to collect form the visitor in the onboarding form.

You can optionally enable the capability to let visitors request an access extension, but enabling the option **Allow visitors to ask for access extension**. In this case you need to specify one or more Admins that will be notified of the request in the field **Admins to be notified for the extension request**.

## Visitors experience

When a visitors lands on the WiFI Portal, a new button "I am a visitor" appears in case the option is enabled.

<figure><img src="/files/lIZx0rB93GwuXRHPNyN4" alt="" width="375"><figcaption></figcaption></figure>

After clicking "**I am a Visito**r", the user see a registration page.

Email is always mandatory. The rest of the form attributes depends on the attributes defined in the Setup section.&#x20;

The use can tick the option "**I need Wifi access beyond today**" to request an extension. In this case a desired termination date and a reason need to be specified.

<figure><img src="/files/X7wiBP6HR5bZG7aA2WLh" alt="" width="375"><figcaption></figcaption></figure>

The user then receives a verification email with a magic link to access the WifI portal and retrieve his personal WiFi Passphrase. Visitors only the the section of the WiFI Portal related to the Personal Passphrase, while all other sections, such as device management, are not available.

## Approval process

All configured admin receive a notification email with the summary fo the extension request and they can click a link to manage the request directly.

In case of pending requests, the dashboard also shows on the top a card with all the pending requests to be handled. The Admin can simply click on **Accept** or **Decline** buttons to quickly handle the request or click on the name of the Requester to open the Visitor page and change the termination date manually to any desired date.

<figure><img src="/files/r5AdWeKeAUL15CtJ9DEB" alt=""><figcaption></figcaption></figure>

All the handled request actions are logged in the Audit logs.

<figure><img src="/files/2JJQ7Xzn2XFzTgoxAxKK" alt=""><figcaption></figcaption></figure>


# Admins

When logged in as Organization admin, under **General** > **Admins**, you can manage all the account users, including other **Organization admins** and **Network managers**.

Organization admins can have two **permissions** scopes:

* **Admins**: can configure the account, including Settings, Network and Accounts
* **Account managers**: can only manage Accounts

<figure><img src="/files/CiXYRBIb8URBnFcuZ1lM" alt=""><figcaption></figcaption></figure>

When you edit or create an Org Manager, you can elect it to become the **Account Owner**. Account Owner is the admin account that has the permission to manage other Admins.&#x20;

Toggle the option "Invite as Owner" to elect the Admin as owner.

![](/files/ZkcZti3MM636jZVj6g1P)

{% hint style="info" %}
Switching account owner might be useful when a partner tokk initial control of an account during a negotiation phase. Once the end customer gets onboarded, the partner can create a new Admin and elect it to become the owner and Data Controller of the Cusna account
{% endhint %}


# Multi Organizations

Sometimes, large companies might need to use multiple Cusna accounts. In this cases, one Org Admin can be enabled to manage multiple Organizations. This can happen when the company has multiple independent sub-brands with different management teams.

When a admin is assigned to an Organization, the user can simply pick to organization to manage form the **organization picker** menu.

![](/files/IFYJLp4NtX2THJvMbCh9)


# Account settings

In the bottom left corner, on the left side bar, click on the name of the account and then click on **Account Settings.**

In this page you can:

* Visualize License details (only available to direct Cusna customers)
* Visualize the details of the Managed Service Provider (if the account is managed by an MSP)
* Reset the account data

### Service Provider

If the Oganization acoutn is actively managed by an MSP, the Service Provider card shows the details of the MSP.

<figure><img src="/files/dNXh0pN2pStOSf0huafc" alt=""><figcaption></figcaption></figure>

### License

On the **License** card, you can see your current Subscription and check the status of your allowances in terms of **max Properties** and **max Residents**

<figure><img src="/files/SzOhG1lwXidoF6QUpKJQ" alt=""><figcaption></figcaption></figure>

Moreover you can see the activation status of the add-ons, including:

* [**Units**](/service-management/units): the Units add-on allows you to manage the [Units](/service-management/units) of your Network and assign an Access Point to each unit. This option is disabled by default because not all hardwares support this capability.
* [**Billing**](/add-ons/billing): the billing module allows to create subscription plans that you can assign to tenants. Tenants will have to setup their payment method on their first login to the Tenant Portal before seeing their WiFi passphrase

### Account Management

The **Reset Your Workspace** option allows to delete all data in the account.

<figure><img src="/files/tAf68Krq9dOe3N6n1gqq" alt=""><figcaption></figcaption></figure>

When clicking the button **Reset account**, the user has to confirm the action by typing "*reset*" in an input box.

<figure><img src="/files/hayJGX5i7jF8dDM1L5R3" alt="" width="375"><figcaption></figcaption></figure>

The **Delete your account** option allows to permanently delete the Organization account and all its related configuration and PII.

<figure><img src="/files/mpJrzqTJeDrQTQrFaGhI" alt=""><figcaption></figcaption></figure>

When clicking the button **Delete account**, the user has to confirm the action by typing "*delete*" in an input box.

<figure><img src="/files/c9U4J9rcmdN8sjkKgjys" alt="" width="375"><figcaption></figcaption></figure>

{% hint style="info" %}
The only metadata retained after Organization delete, is the reference name of the account, used in the MSP dashboard to consult the history subscriptions and MAA consumption.
{% endhint %}

The **Data Retention option**, allows to automatically delete accounts (a related PII) after a certain number of days since the service was suspended.

<figure><img src="/files/Rzub3n13wUTxBOjbbnIp" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
A daily routine checks for all Accounts that match the data retention settings and deletes them. If you set the number of days to 0, only Accounts that have been terminated before the daily data retention routine runs are deleted, otherwise they are deleted the following day.
{% endhint %}


# My Profile

In the bottom left corner, on the left side bar, click on the name of the account and then click on **My Profile** to open the My Profile page.

<div align="left"><figure><img src="/files/tpTTa7ErYFwePQX76lon" alt="" width="136"><figcaption></figcaption></figure></div>

### My Profile

In the **My Profile** card is possible to change First Name, Last Name, email, phone number, and language. When a field is modified the Update profile button will be enabled to allow saving the data.

<figure><img src="/files/DH6EuIuZ8nr4KCDKnvFs" alt=""><figcaption></figcaption></figure>

#### Password update

Is also possible to reset the password using the **Update Password** button in the top right corner. Clicking the button open a dialog that requires the user to provide:

* current password
* new password
* confirmation of the new password

Users are not logged out upon successful password change.

<figure><img src="/files/J1tgGoOUGuoisINejyJz" alt="" width="375"><figcaption></figcaption></figure>

### Two Factor Authentication

<figure><img src="/files/9fIa5VsVIPV0DTgNX7ch" alt=""><figcaption></figcaption></figure>

In the security section, Admins have the option to enable 2FA on their account. The user needs to go trough 4 steps to enable the 2FA.

<figure><img src="/files/KTo5VFVGXdDEGcJ6dj5D" alt=""><figcaption></figcaption></figure>

Once enabled, at every login the Admin is prompted to enter a Token generated with an Authetnicator app.&#x20;

2FA can be disabled form this same section.

### Notifications

In the **Notifications** card is possible to opt to receive emails in real time whenever an Anomaly is identified.

<figure><img src="/files/I15kfmwU2ssK6yZoNUQn" alt=""><figcaption></figcaption></figure>


# Support platforms integrations

Cusna allows you to integrate your existing end customer support systems directly into the WiFi Portal, to provide end user a direct access to your support channels.

<figure><img src="/files/GCdvPJ0A37McZqpvEJpq" alt="" width="195"><figcaption></figcaption></figure>

## Setup

You first need to setup the integration with your support platform in the **Setup**, **Integration page**.

Once you have setup the integration, you can enable or disable the support button by configuring the option in **Setup** > **Onboarding**  page in the WiFi Portal card.

<figure><img src="/files/oU3gXTmeLPj0lINhZEIz" alt=""><figcaption></figcaption></figure>

### FreshWorks

In order to integrate your FreshDesk widget inside the WiFi Portal, you need to create a Widget and retrieve its ID.

Go to **Admin** and select **Widgets**. Create and configure a new Widget. You can change all the settings of the widget, including labels and theme directly in the FresWorks dashboard.

Click on the button **Embed**. A dialog with the widget code will appear.

<figure><img src="/files/UyT68y6l6cyBu78Z2HBJ" alt="" width="375"><figcaption></figcaption></figure>

Find the part of the code 'widget\_id': and copy the value next to it, such as 204000000218 in the example above.

In Cusna, select New integration and select FreshWorks. In the Widget ID filed, enter the value you just copied.

<figure><img src="/files/qMrtadlR6rXKBaYWYTM9" alt="" width="375"><figcaption></figcaption></figure>


# Service Monitoring and Assurance

Cusna orchestrates the lifecycle of WiFi services by managing multiple resources across various systems, with heavy reliance on APIs. While robust, API errors can occasionally occur for a variety of reasons. Cusna automatically addresses most of these issues using native retry mechanisms and automated correction workflows.

However, certain errors may still arise, particularly in scenarios where external systems are manually managed. For example, if a user modifies or deletes entities created by Cusna—entities that Cusna expects to find—this can lead to inconsistencies or operational disruptions.

## Main assurance tools

Cusna offers a range of tools for Org Admins and MSP Admins to monitor and troubleshoot issues and anomalies:

* [**Anomalies**](/service-management/service-monitoring-and-assurance/anomalies): both Org Admins and MSP Admins can access an Anomalies page that lists all detected, unresolved issues and anomalies.
  * [**Anomalies notification**](/service-management/my-profile#notifications): Admins can opt to receive real-time notifications via email whenever an high priority or blocking issues occur
* [**Network Health**](/service-management/service-monitoring-and-assurance/network-health): for certain vendors, a dedicated dashboard widget and a detail page provide insights about the status of the network
* [**Activity Logs**](/service-management/service-monitoring-and-assurance/activity-logs): provides additional insights about the history of operations that occurrent in the system, including Accounts activation and termination&#x20;

You can access the above tools directly form the sidebar form **Monitor** menu.

## Other troubleshooting utilities

Cusna offers also additional utilities to help during troubleshooting.

### Integrations

On the **Integration** page, within the **WiFi Network** card, you can click the **Check** button for each configured integration to verify if the connection with the network management system is functioning correctly.

<figure><img src="/files/yXfLtmfFU4Ip7GxxjZx0" alt=""><figcaption></figcaption></figure>

In case an error is detected, an alert icon <img src="/files/D5LwXHlhaFlUk3s06fem" alt="" data-size="line"> appears to notify an issue. You also get a permanent error notification in the main sidebar reporting that the integration is not working properly.

{% hint style="info" %}
Note that this check is performed automatically each time you open the dashboard, but no more than once every 5 minutes.
{% endhint %}

When such a problem occurs, an anomaly is reported, and you will receive an email notification if this option is enabled in your [Profile](/service-management/my-profile).

<figure><img src="/files/JePTHoDwkOE11lM4B45k" alt="" width="375"><figcaption></figcaption></figure>

### Accounts

In case you experience an issue with a specific Account, you can search the account and open its detail page. A button Status Check is available for more WiFi vendors. Once click, the system performs multiple checks and its result is presented in a card just below the header section.

<figure><img src="/files/juOYcYZEKE8WHHaB3ddJ" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
If everything is functioning correctly, you will receive a positive confirmation. This indicates that the account is properly provisioned in the network and within Cusna. Conversely, if the account is inactive in Cusna, it will be correctly de-provisioned from the network.

If any issues persist with this account, we recommend investigating the network configuration, including connectivity, SSID status, DHCP settings, VLANs, routing, and other related parameters.
{% endhint %}

In the event of errors, the detected anomalies are reported on this card and in the main Anomalies list. If the system determines that the anomalies no longer occur, they are automatically marked as resolved and removed from the list.

<figure><img src="/files/UbUAipY28ZPRyY3CqSuJ" alt=""><figcaption></figcaption></figure>

### Networks

If any anomaly impacts a network, an alert icon will appear in the main **Networks** list on the row corresponding to the location affected by the issue. Clicking the icon redirects you to the **Anomalies** section, where the table is pre-filtered to display all anomalies related to that network.

<figure><img src="/files/9nbywUEgpR73lZcpzLv5" alt=""><figcaption></figcaption></figure>


# Anomalies

### Organizations Dashboard

In the main dashboard, the widget Anomalies lists the last issues, anomalies and important notifications related to the service.

<figure><img src="/files/FRTIHEiCtrifqpFpBkb4" alt="" width="375"><figcaption></figcaption></figure>

By clicking the arrow icon in the  the widget <img src="/files/HM0xSR8PEXhr8Tzue522" alt="" data-size="line">, you can access to the page with the entire list of Anomalies.&#x20;

You can access the **Anomalies** page form the sidebar under the **Monitor** menu.

<figure><img src="/files/bf7il9roAM66TgTu7vZ8" alt=""><figcaption></figcaption></figure>

### MSP Dashboard

MSPs Admins can access the **Anomalies** page directly form the main menu. On the MSP level, Admins can filter Anomalies by Organization.

When MSPs mark an anomaly as Solved, it will disappear also from the Organization Dashboard of the Organization the Anomaly refers to.

<figure><img src="/files/eGybeawBdeknX7M4PJk0" alt=""><figcaption></figcaption></figure>

### Error Codes

Errors and Anomalies are classified in different Types and each Type has multiple Error codes.

<table><thead><tr><th width="143">Type</th><th width="213">Error Code</th><th>Description</th></tr></thead><tbody><tr><td>Accounts</td><td>ACC_CUSNAONLY</td><td>The Account is active in Cusna but does not exists in the Network</td></tr><tr><td>Accounts</td><td>ACC_NETONLY</td><td>The Acc is active in the Network but is not found or it is not active in Cusna </td></tr><tr><td>Accounts</td><td>ACC_NETDISABLED</td><td>The Account exist and it is active in Cusna but it is not enabled in the Network</td></tr><tr><td>Accounts</td><td>ACC_ADDFAILED</td><td>The provisioning of the Account in the Network failed</td></tr><tr><td>Accounts</td><td>ACC_DELETEFAILED</td><td>The removal or termination of the Account in the Network failed</td></tr><tr><td>APIs</td><td>API_UNDEFINED</td><td>Generic API error with the Network or IdPs</td></tr><tr><td>APIs</td><td>API_AUTH</td><td>API authentication errors</td></tr><tr><td>License</td><td>LIC_0.9MAA</td><td>The Organization reached 90% of the configured Max Monthly Active Accounts limit</td></tr><tr><td>Locations</td><td>LOC_CONF</td><td>Errore with the Location cofniguration</td></tr><tr><td>Locations</td><td>LOC_UNMAPPED</td><td>The Location is not properly mapped with an equivalent entity in the Network or with external IdPs</td></tr></tbody></table>

### Managing Anomalies

Some Anomalies are automatically resolved when the system detects that the issues has been fixed, and they disappear form the list.

In any case, for all the anomalies currently listed in the table, you can click click "**Mark as Solved**" to remove the anomaly form the list.

As a reminder, Admins can receive real time email notifying issues by enabling this function in the [Profile](/service-management/my-profile) page.


# Activity Logs

You can access the **Activity Logs** page form the sidebar under the **Monitor** menu.

The **Activity Logs** track the history of relevant service-related or platform-related events for auditing and troubleshooting purposes.\
A dedicated page displaying the history of all events can be accessed from the **Activity Logs** widget in the dashboard.

<figure><img src="/files/skgkam6y878FQlBXTpQz" alt=""><figcaption></figcaption></figure>

All activities and events related to Accounts can also be viewed directly on the Account details page for convenience, simplifying the process of reconstructing the Account's history.

<figure><img src="/files/ERBcekhkevACqRl91gg7" alt=""><figcaption></figcaption></figure>

The main dashboard also provides an overview of the most recent Activities in a dedicate Widget. Clicking the red arrow <img src="/files/HM0xSR8PEXhr8Tzue522" alt="" data-size="line">, brings the user in the main Activity Logs page.&#x20;

<figure><img src="/files/USLUfzmmAHFlQY8GbeKU" alt="" width="244"><figcaption></figcaption></figure>


# Network Health

Network Health is an utility available only for certain WiFi vendor.&#x20;

A widget in the main Organization dashboard summarized the health status of the network, in terms of availability of the network nodes. The Network Health detail page can be reached form the widget to get more in depth details, by clicking the red arrow <img src="/files/HM0xSR8PEXhr8Tzue522" alt="" data-size="line">.

You can access the **Network Health** page form the sidebar under the **Monitor** menu.

### Cisco Meraki

For Cisco Meraki initiative, the dashboard includes a widget that summarizes the status of the Access point involved with the service.

The Active clients widget include a chart that plots the number of active clients seen in the last 30 days, per each selected Network. You can select the Network in the right top dropdown menu.

<figure><img src="/files/Gl82GOe4iexxmvuGdNoM" alt=""><figcaption></figcaption></figure>

The status is refreshed whenever you load the dashboard page, but you can check the timestamp of the latest update in the widget and click the "refresh" icon to trigger an immediate update

By clicking the red arrow in the widget <img src="/files/D6f8CiZKc5qgGTadc4Vc" alt="" data-size="line">, you can access to an inner section that contains the full list of access points in the deployment with their related operational status.

<figure><img src="/files/lulqYWSecOlYu7E3Z7oX" alt=""><figcaption></figcaption></figure>

You can seatch Access Points by name and filter the list by Network or Status,


# Coworking management platforms


# Optix

Optix integration allow co-working customers managed in the Optix platform ("users") to self provision their WiFi access. There are two ways a user can be provisioned on the WiFi network:

* **via the WiFi Portal**\
  Customers can visit the Tenants Portal - which URL is different per Location - and enter the email address that match a User in Optix.  If the email matches an existing User in Optix, Cusna sends a magic link to login into the Tenant portal to that email. At this point the customer will be able to see and change their own private WiFi passphrase.
* [**via the mobile app**](#mobile-app-integration)\
  In the alternative they can open the WiFi app inside the Optix App and they will be provisioned automatically.

Note that a User can be associated only to one Account in Cusna. By default, the Account is associated to the Location used for the onboarding. In case of the WiFi Portal, is the Location related to the portal itself (each Location has a dedicated portal). In case of mobile app onboarding, the Location assigned is the Location in Cusna matching the location selected and active in the mobile app when the user open the WiFi app the first time.

Cusna provision automatically access for:

* **Users** who are **Active** and with a valid **Plan**
* Users who have a **Booking** for a resource in the Location they request WiFi access for. The personal PSK by default is valid only until the end of the same day.

#### Team members

If a user belongs to a Team, a matching Group on Cusna will be created for each Team with an assigned VLAN. All users member of the same Team (Group in Cusna) will be provisioned with the same VLAN.

**Accounts termination**

By default all Accounts are created with the service already active and with no termination date, except for Accounts related to bookings that expire the same day.

When a Team Member is **removed** from Optix, it is  also deleted from Cusna automatically and its WiFi access suspended.

When a **Plan is removed** form a Member, Cusna suspends the WiFi service for the user but the account remains in the Cusna account.

### Guidelines in multi-location scenario

If you have multiple active Locations in Optix, users might be able to explore the Content of each one of them and book resources and visit different Locations. When using the mobile app, they can switch Location from the main menu and potentially open the WiFi app form the context of different Locations.

Since a User can be associated to one single Account, the user will only have one WiFi passphrase at a time (with an associated VLAN eventually). In the context of the mobile app, no matter which Location is currenlty active, they will always see the same WiFi passphrase. The account is associated in Cusna to the Location used for the first time onboarding.

If you want users to be able to roam cross locations, you need to use a WiFi network that support multi-site PSKs and perform the correct configuration.&#x20;

For example, in Cambium you might want to use the same WLAN profile for all the AP Groups (Locations). In Mist, you should use Org-level PSKS. In Extreme, deploy the same profile on multiple group of access points. Check the doc related to each vendor for recommendations on how to setup a cross-location community scenario.

## Optix account setup

1. Form your Optix account go to **Apps and Integrations** and click on the tab **DEVELOP**.
2. Click **Create App** and enter a name for your app, such as "*Cusna*". The Edit your app dialog appears. Fill in the optional missing data such as category logo and description.
3. In the **API Keys** section copy the **Client ID** and the **Organization Token**\ <br>

   <figure><img src="/files/ttYoxMgi6XBfGleQahi7" alt=""><figcaption></figcaption></figure>
4. In the **Advanced settings** section, enter the following code

```json
{
"webhooks": [
      {
        "event": "member_deleted", 
        "url": "https://www.cusna.io/api/1.1/wf/optix-memebr-deleted"
     },
     {
        "event": "organization_token_updated", 
        "url": "https://www.cusna.io/api/1.1/wf/optix-tokenupdate"
     }
   ]
}
```

Click **Save** at the bottom of the page.

Take note of of your Optix account **subdomain**. The subdomain is the string just before the "*.optixapp.com*" that you can find in the URL of your browser. In the example below, the subdomain is "*cusna*".

![](/files/o8yzFGarptqvyIO0kHIg)

### Cusna account setup

1. In your Cusna account, go to **Setting** and scroll to the **Integrations** section. Click **New Integration**. Select **Optix**.
2. Enter your Optix **Client ID**, **Organization Token** and **Subdomain**  and finally click **Setup**.\ <br>

   <figure><img src="/files/T3MHzwEhlHHhsWvJluzT" alt=""><figcaption></figcaption></figure>

Once the Optix integration setup is complete, you can link exisitng Locations to Optix location, wither new or exisitn gones.

When you create or edit a Location in Cusna, a new dropdown menu allows to select the matching location in Optix.

![](/files/fyaia3PwJKgsT8Ci9wG8)

## Mobile App integration

Cusna integrates into the Optix app to deliver a full self-serve and simplified experience to users.

Users can find the WiFi tool in the top toolbar and get access immediately to their personal passphrase without any further action.

{% embed url="<https://youtube.com/shorts/gJ5eQXWx-xs>" %}

In order to enable the mobile app integration, you need to edit the Setting section indicated in the step 3 of Optix Setup above as follow:

<pre class="language-json"><code class="lang-json">{
"canvases": [
      {
        "type":"MOBILE_HOME_PRIMARY",
        "url": "https://www.cusna.io/optix/<a data-footnote-ref href="#user-content-fn-1">&#x3C;organization_id></a>",
        "title":"WiFi",
        "icon":"wifi"
      }
    ],
"webhooks": [
      {
        "event": "member_deleted", 
        "url": "https://www.cusna.io/api/1.1/wf/optix-memebr-deleted"
     },
{
        "event": "organization_token_updated", 
        "url": "https://www.cusna.io/api/1.1/wf/optix-tokenupdate"
     }
   ]
}
</code></pre>

{% hint style="info" %}
In the code above, you need to replace `<organization_id>` with your Cusna accoutn Organization ID.
{% endhint %}

#### Unmapped Locations

{% hint style="warning" %}
Apps are published on all Optix Locations visible in the mobile app.&#x20;
{% endhint %}

In case you forgot to map the related Location in Cusna, when users click the WiFi app in the home page, they will get the followign error message.

![](/files/6VgO0qBdlKtBAcqcMihA)

You can keep track of these events in the Notification box in the Cusna dashboard. An alert will inform you when a user click the WiFi app form an unmapped Location with the related Optix Location ID.

<figure><img src="/files/SQhmRap2A0w9g8M25rS4" alt=""><figcaption></figcaption></figure>

## Workflow Video

The following video shows a sample workflow where a user existing in Optix self onboard via the Tenant Portal and his account and the related group get created in Cusna.

{% embed url="<https://youtu.be/LW_vi2akHqg>" %}

[^1]: Replace this value with your Cusna account Organization ID


# Office RnD

Office RnD integration allow co-working members to self-provision their secure WiFi access.

Members can visit the WiFi Portal - which URL is different per Location - login with their credentials to access and/or change their personal WiFi passphrase.

If the user belongs to a Team, Cusna creates a matching Group and assign a static VLAN that will be assigned to all members of the same team, so their traffic is segregated from other teams and users.

When users are removed from office RnD, they are also autaotmically removed from Cusna and their WiFi access is disabled.

## Office RnD setup

in Office RnD, go to **Settings**, **Developer Tools**. Click **Add application**. \
The **Add Application** dialog appears.

![](/files/rDiMvNsXsnWvEHIhHHZW)

Enter a **Name** and select **Read** and **Write** in the Permission section. Click Add to save the application.

In the main page, you'll the app you've just created in the table. Click **View**. The **View Application** dialog appears.

<figure><img src="/files/g4SykwJEedFYEbsubT6S" alt=""><figcaption></figcaption></figure>

Copy the **Client ID** and **Client secret** values.

Go to Setting, Account and open the tab General.&#x20;

&#x20;

<figure><img src="/files/nBQvx51a1DSLqYXKvkm0" alt=""><figcaption></figcaption></figure>

Take note of the value you see in the input **Admin Site**.

<figure><img src="/files/wwpCLdSUzRLbNSvITkIp" alt=""><figcaption></figcaption></figure>

## Setting up the integration in Cusna

Go to **Setting** and scroll to the **Integrations** section. Click **New Integration**. Select **Office RnD**.

Enter the following values:

* Client ID
* Client Secret
* Slug

Click **Setup**.

<figure><img src="/files/0qLo3Qgxs1J8mACYkgV1" alt=""><figcaption></figcaption></figure>


# Nexudus

Nexudus integration allow co-working customers to self provision their WiFi access.

Customers can visit the WiFi Portal - which URL is different per Location - and enter the email address associated with their account in Nexudus.

If the email matches with the email associated to a CoWorker in Nexudus, Cusna sends a magic link to the provided email to login into the WiFi portal. At this point the user will be able to see and change its own private WiFi passphrase.

When coworkers are removed from Nexudus, they are also deleted form Cusna automatically and their WiFi access suspended.

#### Teams

If the CoWorker belongs to a Team, Cusna creates automatically a Group matching the Team (if not existing already), and assign to the team member the same VLAN as the one of the other team members.

Go to Setup, General and select None in the VLAN settings to turn off automatic VLAN assignment.

#### Global Communities

Each Coworker can be associated only to one account in Cusna. If you want users to roam across your locations with the same WiFi passphrase, you need to enable the Global Communities option and configure your network accordingly.

{% hint style="info" %}
**Coming soon**

* Create an account for Visitors
  {% endhint %}

## Setup

Nexudus integration relies on an access token that is generated one time using your account email and password.&#x20;

{% hint style="success" %}
Cusna does not store your credentials, they are used at runtime the first time only to generate the first access token.
{% endhint %}

In your Cusna account, go to **Setting** and scroll to the **Integrations** section. Click **New Integration**. Select **Nexudus**.

Enter your Nexudus account email and password and click **Setup**.

<figure><img src="/files/Xss5nrfYnyuMpF4ifZRH" alt=""><figcaption></figcaption></figure>


# Andcards

Andcards integration allow co-working customers to self-provision their secure WiFi access.

Customers can visit the WiFi Portal - which URL is different per each Location - and enter the email address associated with their account in Andcards.

If the email matches with the email associated to a CoWorker in Andcards, Cusna sends a magic link to the provided email to login into the WiFi portal. At this point the user will be able to see and change its own private WiFi passphrase.

At this time, Cusna can automatically provisions access for:

* **members** with an active plan\
  WiFi access for individual members is scheduled for automatic termination on the end-date associated to the user account&#x20;
* user with a **desk booking** in the same day; WiFi access is granted only for the day of the booking until the midnight
* users with a **room booking** in the same day; WiFi access is granted only for the day of the booking until the midnight

{% hint style="info" %}
WiFi access for users with **bookings** is granted via the WiFi portal only for the day of the booking and it is valid until the midnight of the same day. Accounts are not deleted in Cusna, but simply disabled; if the same user attempts to retrieve access on another day for a new booking, it will be reactivated.
{% endhint %}

#### Supported features:

* **Traffic separation**: when enabling VLAN management for Andcards, Cusna automatically creates Groups for each Company. Members of the same company are assigned to the same VLAN so their traffic is secured and their devices can reach each others.
* **Roaming**: when enabling Roaming, users can connect to all Locations using the same passphrase

## Andcards setup

Login in your Andcards account as an admin, go to **Product** **Settings**, and select **API Credentials**<br>

<figure><img src="/files/CJmK6qgEv0Bv30rNg9VY" alt=""><figcaption></figcaption></figure>

Copy the **Client ID** and the **Client Secret**.&#x20;

## Setting up the integration in Cusna

Go to **Setting** and scroll to the **Integrations** section. Click **New Integration**. Select Andcards.

Enter the following values:

* Client ID
* Client Secret

<figure><img src="/files/ulAP9XCG3iCUqwpRJkvT" alt=""><figcaption></figcaption></figure>

Click **Setup**.&#x20;

Once your integration is active, only for some WiFi vendors, you have the option to enable or disable the automatic management of VLANs for users provisioned via this integration.

<figure><img src="/files/mve3um7hNfXloEI1p7lc" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
You can easily share the link to the Location WiFi Portal is to create a dedicate information box in the Information section of each location:\
\
![](/files/o9ZVk5xRvU99LhmUP3UR)

{% endhint %}


# Property Management Systems


# Oracle Opera Cloud

{% hint style="info" %}
This is a Beta feature only for partners and customer with access to the Beta Program
{% endhint %}

**Oracle Opera Cloud** integration enables guests to self-onboard by identifying themselves via **Last Name** and **Room Number** from the WiFi portal. If they have a valid reservation, they receive a personal WiFi Passphrase, which is automatically deactivated at the end of their room stay.

### Cusna setup

Go to Integrations and click **New** in the Integration card, then select **Opera Cloud**.

Enter the following data:

* **Hostname**: full hostname of your instance, including https\://
* **Client ID**
* **Secret**
* **Enterprise ID**

<figure><img src="/files/o7PY3ICR5Mp0bR7pBKQg" alt=""><figcaption></figcaption></figure>

Click **Setup**.

<figure><img src="/files/wrloKoIe2FsEmln5CuUy" alt=""><figcaption></figcaption></figure>

### Settign up networks for each Hotel

When you create a Network, you need to enter your **Hotel ID** in the Hotel ID field.

<figure><img src="/files/byVjWjHk1I9DIYPISa0H" alt=""><figcaption></figcaption></figure>

### Enabling SSO via Oracle Opera Cloud

Go to **Setup**, **Onboarding** and enable the toggle next to Oracle Opera Cloud

<figure><img src="/files/M4RqUz46yVK6pjdQUO2C" alt=""><figcaption></figcaption></figure>

## User experience

The WiFI portal can be distributed via in-room QR codes or published on a dedicated SSID as a captive portal.

Guests can sign in using their Last Name and Room number and get immediate access to the portal where they’ll can find their personal WiFi passphrase. If PAN is enabled, all devices connected with the same PSK will be in the same network segment (e.g. mobile phones, laptops and personal headless device such as gaming consoles, medical devices, etc..)

<figure><img src="/files/cEjmEJSoOs4ePa1GQmpq" alt=""><figcaption></figcaption></figure>


# Mews

{% hint style="info" %}
This is a Beta feature only for partners and customer with access to the Beta Program
{% endhint %}

**Mews PMS** integration enables guests to self-onboard by identifying themselves via **Last Name** and **Room Number** from the WiFi portal. If they have a valid reservation, they receive a personal WiFi Passphrase, which is automatically deactivated at the end of their room stay.

### Cusna setup

Go to Integrations and click **New** in the Integration card, then select **Mews**.

Enter the following data:

* **Hostname**: full hostname of your instance, including https\://
* **Client Token**
* **Access Token**

<figure><img src="/files/mfopnqbfWqPA3su0K0jm" alt=""><figcaption></figcaption></figure>

Click **Setup**.

<figure><img src="/files/iR6Ktk0nWXG4HrKUZsGj" alt=""><figcaption></figcaption></figure>

### Setting up networks for each Hotel

If your Mews account has access to a Portfolio of property and you integrated it with Cusna using a [Portfolio Access Tokens](https://mews-systems.gitbook.io/connector-api/concepts/multi-property), when you create a Network, you need to select the  **Enterprise ID** associated to the property in the Enterprise ID dropdown.

### Enabling SSO via Mews

Go to **Setup**, **Onboarding** and enable the toggle next to Mews

<figure><img src="/files/aiNHvjZmnTk77uZ5uQNr" alt=""><figcaption></figcaption></figure>

## User experience

The WiFI portal can be distributed via in-room QR codes or published on a dedicated SSID as a captive portal.

Guests can sign in using their Last Name and Room number and get immediate access to the portal where they’ll can find their personal WiFi passphrase. If PAN is enabled, all devices connected with the same PSK will be in the same network segment (e.g. mobile phones, laptops and personal headless device such as gaming consoles, medical devices, etc..)

<figure><img src="/files/cEjmEJSoOs4ePa1GQmpq" alt=""><figcaption></figcaption></figure>


# Cloudbeds

{% hint style="info" %}
This is a Beta feature only for partners and customer with access to the Beta Program
{% endhint %}

**Cloudbeds PMS** integration enables guests to self-onboard by identifying themselves via **Last Name** and **Room Number** from the WiFi portal. If they have a valid reservation, they receive a personal WiFi Passphrase, which is automatically deactivated at the end of their room stay.

### Cusna setup

Go to Integrations and click **New** in the Integration card, then select **Cloudbeds**.

Enter the following data:

* **Client Token**
* **Access Token**

<figure><img src="/files/QOAiJBZBTsYruw9SmIhj" alt=""><figcaption></figcaption></figure>

Click **Setup**.&#x20;

A new windows will open and prompt you to login with your **Cloudbeds** account and then authorize the integration by clicking **Allow Access**.

<figure><img src="/files/N01eXhilZqrAsUPoRk6n" alt="" width="375"><figcaption></figcaption></figure>

If successful, a message informs you that you can close the window.

<figure><img src="/files/XaZQLS5vIbX3verUFO07" alt=""><figcaption></figcaption></figure>

Going back to the dashboard you'll that the integration is complete.

<figure><img src="/files/sTOahGNSTp9Jy4eHNIaK" alt=""><figcaption></figcaption></figure>

### Setting up networks for each Hotel

When you create a Network, you need to select the Hotel form a dropdown menu.

<figure><img src="/files/8ZK5Ez2GoS6KtscFqN8W" alt="" width="375"><figcaption></figcaption></figure>

### Enabling SSO via Cloudbeds

Go to **Setup**, **Onboarding** and enable the toggle next to Cloudbeds

<figure><img src="/files/wNpmfenTZYdGRtocvNgw" alt=""><figcaption></figcaption></figure>

## User experience

The WiFi portal can be distributed via in-room QR codes or published on a dedicated SSID as a captive portal.

Guests can sign in using their Last Name and Room number and get immediate access to the portal where they’ll can find their personal WiFi passphrase. If PAN is enabled, all devices connected with the same PSK will be in the same network segment (e.g. mobile phones, laptops and personal headless device such as gaming consoles, medical devices, etc..)

<figure><img src="/files/cEjmEJSoOs4ePa1GQmpq" alt=""><figcaption></figcaption></figure>


# Apaleo

{% hint style="info" %}
This is a Beta feature only for partners and customer with access to the Beta Program
{% endhint %}

**Apaleo PMS** integration enables guests to self-onboard by identifying themselves via **Last Name** and **Room Number** from the WiFi portal. If they have a valid reservation, they receive a personal WiFi Passphrase, which is automatically deactivated at the end of their room stay.

### Cusna setup

Go to Integrations and click **New** in the Integration card, then select **Apaleo**.

Enter the following data:

* **Client Token**
* **Access Token**

<figure><img src="/files/M2KViPEVXk2xdP7THnzp" alt="" width="375"><figcaption></figcaption></figure>

Click **Setup**.&#x20;

A new windows will open and prompt you to login with your **Apaleo** account.

If successful, a message informs you that you can close the window.

<figure><img src="/files/XaZQLS5vIbX3verUFO07" alt=""><figcaption></figcaption></figure>

Going back to the dashboard you'll that the integration is complete.

<figure><img src="/files/R02jdrdG3kcoT2gFnm6i" alt=""><figcaption></figcaption></figure>

### Setting up networks for each Hotel

When you create a Network, you need to select the Hotel form a dropdown menu.

<figure><img src="/files/CxAIbXkTPdXaqOHnENk0" alt="" width="375"><figcaption></figcaption></figure>

### Enabling SSO via **Apaleo**

Go to **Setup**, **Onboarding** and enable the toggle next to **Apaleo**

<figure><img src="/files/ZfaMQhzOHXpB0qGyWgBC" alt=""><figcaption></figcaption></figure>

## User experience

The WiFi portal can be distributed via in-room QR codes or published on a dedicated SSID as a captive portal.

Guests can sign in using their Last Name and Room number and get immediate access to the portal where they’ll can find their personal WiFi passphrase. If PAN is enabled, all devices connected with the same PSK will be in the same network segment (e.g. mobile phones, laptops and personal headless device such as gaming consoles, medical devices, etc..)

<figure><img src="/files/cEjmEJSoOs4ePa1GQmpq" alt=""><figcaption></figcaption></figure>


# StarRez

{% hint style="info" %}
This is a Beta feature only for partners and customer with access to the Beta Program
{% endhint %}

**StarRez** integration allows guests to self-onboard simply using their email address via the WiFi portal. If the email is linked to an active resident in StarRez, they receive a magic link granting access to the WiFi Portal where they can retrieve WiFi access details.

### Get started with your connector <a href="#get-started-with-your-connector" id="get-started-with-your-connector"></a>

Get your REST API Connection Settings:

1. Log in to StarRez and click on **Account** in the top left > Account

2. **Web Service** **Tokens** > **Create New**\
   \
   ![](/files/3ImYAoymDOKXq6ClTMGd)<br>

3. Enter a Name/description for the Token and set the **Expiry Date**. Make sure you copy the token from this screen. It cannot be viewed after you close this window and is not recoverable. \
   \
   ![](/files/BSCzxP9W1k2LwNV7XzKD)<br>

4. Refer to the API documentation to find your **Rest API URL** (<https://support.starrez.com/hc/en-us/articles/360056850292-StarRez-REST-2-0-Web-Services-API-Guide>)\
   Your StarRez system is usually hosted on a URL such as  format `https://yourinstitution.starrezhousing.com` or similar.\
   The REST API services typically reside under a `/StarRezREST` path, so the Rest API URL could be something like:

   `https://yourinstitution.starrezhousing.com/StarRezREST`

5. Keep a record of these credentials and the RestAPI URL

### Setting up Cusna

Go to Integrations and click **New** in the Integration card, then select **StarRez**.

Enter the following data:

* **RestAPI URL**
* **Access token**
* **CheckOut Report Name** (optional):

  This is a custom report name that allows Cusna to retrieve daily the list of users who have checked out, in order to suspend their WiFi service.

<figure><img src="/files/udlofD0OWNzs3cd0Z5S3" alt=""><figcaption></figcaption></figure>

Click **Setup**.

{% hint style="info" %}
If the data provided is not correct, either the URL or the Access Token, you'll receive an error notification
{% endhint %}

### Enabling StarRez

In order to enable StarRez to let user register on the WiFi Portal, go to **Setup**, **Onboarding** and  enable on StarRez on the **Access Control** section.

<figure><img src="/files/rvJlgwMe8QgnYKyIqfgU" alt=""><figcaption></figcaption></figure>


# Enterprise cloud IdPs


# Microsoft Entra ID (SAML)

### Cusna SAML setup

Go to Integrations and click **New** in the Integration card, then select **SAML**.

<figure><img src="/files/gcURdiSS5NHWlFdTJowP" alt="" width="563"><figcaption></figcaption></figure>

Select the type of SSO system from the dropdown list. Based on the SSO system type chosen, the setup steps can slightly differ.

Available SSO systems:

* [Shibboleth](/cloud-identity-platforms-integrations/enterprise-cloud-idps/shibboleth)

{% hint style="info" %}
The Setup process requires to operate simultaneously on Cusna and on the Azure Portal. We suggest to keep them open in two different tabs of your browser.
{% endhint %}

### Step 1: Initialize the connector in Cusna

1. Form your Cusna dashboard, go to **Setup**, **Integration** on the sidebar, then  click **New Integration** button on the card.

<figure><img src="/files/dQhLqUGcBcGerhQWjzTi" alt=""><figcaption></figcaption></figure>

2. Form the **System** dropdown, select **SAML**.
3. On the **Type** dropdown, select **Microsoft Entra**.

At this point you'll see two variables getting populated: Reply URL and Entity ID. Copy these two variables as you'll need them in the next step in the Azure Portal.

### Step 2: Setup Azure

{% hint style="info" %}
Keep your Cusna portal open. **DO NOT CLOSE** the Cusna page while setting up the application in Azure console.
{% endhint %}

1. Log in to Microsoft Azure in a new browser tab, click **Enterprise applications** > **New application**.
2. Click **Create your own application**, enter a name for the application, select **Integrate any other application you don't find in the gallery (Non-gallery)** and click **Create**.<br>

   <div align="left"><figure><img src="/files/wTHqtmqylN5vYQolGJaL" alt="" width="375"><figcaption></figcaption></figure></div>
3. Click **Assign users and group** to define which Users or User groups can login with this application. You can assign individual users or groups of users.<br>

   <figure><img src="/files/d2C79gqcwy8yEskCYvCn" alt=""><figcaption></figcaption></figure>

   Once done with the assignment, go back to the main page of the app.<br>
4. Click **Single sign on** on the sidebar, select **SAML.**\
   The page **Set up Single Sign-On with SAML** appears.\
   \
   Click **Edit** in the "**Basic SAML Configuration**" card.  Enter the **Identifier (Entity ID)** and the **Reply URL** value provided in the Cloud4Wi Dashboard (see top of the page). Click Save.\
   \
   The value will be reflected in the related card.\ <br>

   <figure><img src="/files/r34lfAVFQvlfWdj3C2F6" alt=""><figcaption></figcaption></figure>
5. Click **Edit** on the "**Attributes & Claims**" card. Default values are usually the correct ones, but make sure that :&#x20;
   1. claim name **Unique User Identifier** matches source attribute **user.userpincipalname**
   2. claim name **groups** matches source attribute **user.groups \[All]**\
      if you don't have this entry, click on the button "**+ Add a group claim**" and select **All groups** in the Group Claims dialog.
   3. claim name **emailaddress** matches source attribute **user.mail**
   4. claim name **givenname** matches source attribute **user.givenname**
   5. claim name **name** matches source attribute **user.name**
   6. claim name **surname** matches source attribute **user.surname**\ <br>

      <figure><img src="/files/lv1n47stJRAyUJTI35ev" alt=""><figcaption></figcaption></figure>
6. Go back to the main screen **Set up Single Sign-On with SAML**. Find in the page the section SAML **Certificates**.  Find the attribute **App Federation Metadata Url** and copy its value in the Cusna setup panel in the filed **Metadata URI** \ <br>

   <figure><img src="/files/esQGEGJBvGYJ5vT1H0YO" alt=""><figcaption></figcaption></figure>

   In Cusna, click **Save**.<br>
7. Ensure all users can sign on without the need to set up separate permissions in Entra ID. \
   Form the main page of the application,  go to the **Properties** page and select **No** for **Assignment required** and **Yes** to **Visible to users**.<br>

   <figure><img src="/files/O6u51kabW90iW2TUOWA6" alt=""><figcaption></figcaption></figure>


# Microsoft Entra ID (oAuth)

(previously called Active directory)

Microsoft integration allows to connect Cusna with your Microsoft account.

Microsoft users in your enterprise account can directly enter their email in the WiFi Portal without any previous manual provisioning, or login with their Microsoft credentials.

If their email matches with a member in your Microsoft account, the user will receiver a magic link via email to access directly to the Portal and retrieve the personal WiFi PPSK.

### Microsoft account setup

1. Log in to Microsoft Azure click **Enterprise applications** > **New application**.

2. Click **Create your own application**, enter a name for the application, select **Integrate any other application you don't find in the gallery (Non-gallery)** and click **Create**.\
   \
   ![](/files/wTHqtmqylN5vYQolGJaL)

3. In your newly created Enterprise Application, go to Properties on the left menu, locate "**Assignment required**?", switch it to **No**, and click **Save**.&#x20;

   \
   If you instead want to explicitly restrict application login capabilities to a predefined list of authorized personnel or departments, switch to the **Users and groups** blade in the left-hand navigation menu. Click **+ Add user/group** from the top toolbar. Search for and select the specific users or security groups that require access to the application, then click **Assign**.

4. From **Active Directory** (now Microsoft **Entra ID)** in the Azure Portal, and select **App Registration**. Click on the app you just created

5. From the **Overview** page, copy the **Application** (**Client) ID** and the **Tenant ID**

6. Click Authorization and select **+ Add a platform** and select **Web**.\
   Enter the following **Redirect URI**:\
   `https://www.cusna.io/oauth`\ <br>

   <figure><img src="/files/Ye7PwfJxt4XVOScJb1Ys" alt=""><figcaption></figcaption></figure>

7. Click **API Permissions** and select **+ Add Permission**

8. **Select Microsoft Graph** and click on **Application Permissions**\ <br>

   <figure><img src="/files/HLpG2ijkwYWu1YmOB37M" alt=""><figcaption></figcaption></figure>

9. Select the permissions
   1. *Group.Read.All*
   2. *User.Read.All*

10. Click **Grant admin consent for .... \<yourComapnyName>**

11. If not already enabled, also enable the User.Read Delegated permission. Click **+ Add a permission** again, select Delegated Permission and serach and enable *User.Read*

12. You final Configured permissions should look like the following screenshot

    <figure><img src="/files/7wVFxzg77ymR5Pq5SOaZ" alt=""><figcaption></figcaption></figure>

13. Click on **Certificates and Secrets**, click on  + **New Client Secret**. Enter a name, select an expiration period (e.g. 24 months) and click Add.

14. Copy the value "***Value***" of the secret (not the Secret ID). This value will be shown only once.\
    Note that the secret will expire at the selected time, and you'll need to go back to this cofniguration, generate a new Secret and update it in the Cusna integration<br>

### Cusna Setup

Go to **Integrations** and click **New** in the Integration card. Select **Microsoft**.

Enter the **Client ID**, **Secret** and **Tenant** ID of your Microsoft App. Pick the default **VLAN** that will be assigned to all authorized members.

<figure><img src="/files/a3oMhtrw6R6ThGSUx4K5" alt=""><figcaption></figcaption></figure>

Click **Setup**.

<figure><img src="/files/YNRMt2yK5HSuz3eWaUe9" alt=""><figcaption></figcaption></figure>

You can click **Edit** to change the parameters of the integration at any time.

### Next steps

Once you setup the integration, you need to enable it as an onboarding method. Go to Setup > Onboarding. You'll find on top of the page a card to configure the option of the IdP you've just created.

<figure><img src="/files/mQpRa5k8ztklQItIT2C7" alt=""><figcaption></figcaption></figure>

Enable the toggle on the Microsoft Entra ID title to enable the integration.

* **Display SSO button**: publish the button on the WiFi portal that redirects the user to the Microsoft login page. You can customize the label of the button
* **Passwordless sign up**: enable the option for users to sign up simply using their email address. Upon entering their email address, Cusna verifies if the email exists on the Entra ID directly. If it does, the user receives a link via email to verify the ownership of the email and logs the user directly into his portal.
* **Group mapping**: check the dedicated [group mapping articles](/cloud-identity-platforms-integrations/coworking-management-platforms) to learn how you can assign different network policies to different groups of users


# Google Workspace (oAuth)

Google integration allows to connect Cusna with your Google Workspace account to let user self-onboard via the WiFi Portal. When relyon og Google as IdP, Cusna support two main onboardign workflows:

* **Google SSO**:  users are redirected to your organization Google authenticaiton screen
* **Passwordless** **identification**: users enters their email address and if it is present in your Google directory and authroized, the user receives a magic link on his email to access the WiFi Portal

## Google Cloud Setup

You need a Google Cloud account and a Project.

### 1. Create a Project

If you do not have an existing project suitable for this purpose, start by creating a new project. \
Form the main dashboard, click the menu next to the Google Cloud logo and select "**+ New Project**".

<div align="left"><figure><img src="/files/ciBmUWnj4j2WmfWdDqup" alt="" width="375"><figcaption></figcaption></figure></div>

Once you have a Project, make sure it is selected in the main dropdown next to the Google Cloud logo.

<div align="left"><figure><img src="/files/JDFiUElmwnQYaCO27cCH" alt="" width="375"><figcaption></figcaption></figure></div>

### 2. App Setup

Next, go to **API & Services** and open **OAuth consent screen** to configure the consent screen.

<div align="left"><figure><img src="/files/mp8t8gns3wv83gz56bYJ" alt="" width="188"><figcaption></figcaption></figure></div>

Click **Get Started** to launch the setup wizard.

<div align="left"><figure><img src="/files/LiBuz8hK5E9kwqfoT6YV" alt="" width="375"><figcaption></figcaption></figure></div>

1. In the first screen **App Information**, enter a **Name** for your App (e.g. "Cusna") and select a support email.
2. In the second step, **Audience**, select **Internal** and click Next.\
   \
   ![](/files/y46Rpc41d9tqQMhAClc4)<br>
3. In the second step, **Contact Information**, enter an email address.
4. Go to the last step to access the terms and **Create** the App,

### 2. Branding

On the left sidebar, select **Branding**.&#x20;

<div align="left"><figure><img src="/files/Hn1urFJeeRVbG8YMCFH2" alt="" width="132"><figcaption></figcaption></figure></div>

Fill in the required data about privacy policy and terms, app logo. Scroll the page until you find the  **Authorized domains** section and enter your company domain ("company.com")

<div align="left"><figure><img src="/files/bV1GYNcnrFCMElNw2cCM" alt="" width="375"><figcaption></figcaption></figure></div>

Click **Save** at the bottom of the page to save settings.

### 3. Scopes

On the left sidebar, select **Data Access**. Add the following scopes by clicking "**Add or Remove Steps**":

* `/auth/userinfo.email`
* `/auth/userinfo.profile`

Usually, you'll find these Scopes at the beginning of the list of scopes that appears on the right panel.

<div align="left"><figure><img src="/files/3Utd0LWy7NFv6I1VXwqD" alt="" width="375"><figcaption></figcaption></figure></div>

Once selected, click **Update** and they will be listed in the main screen in the table "**Your non-sensitive scopes**".\
\
![](/files/g5H2OYhh0OZypCjzSV7P)

### 4. Setup Credentials

On the left sidebar, select **Clients**.&#x20;

Select "**+ Create Credentials**" and pick "**OAuth client ID**".&#x20;

<div align="left"><figure><img src="/files/IgIwKpwvToTXxEyqj81R" alt="" width="375"><figcaption></figcaption></figure></div>

The **Create OAuth client ID** page appears. For **Application type** select **Web application**. \
Define a **Name** that users will see in the authentication screen.

<div align="left"><figure><img src="/files/HaOei0v0iyRPt5yNNmJE" alt="" width="375"><figcaption></figcaption></figure></div>

In **Authorized JavaScript origins** enter the following list of values:

* <https://cusna.io>

In **Authorized redirect URIs**, enter the following list of values:

* [https://www.cusna.io/oauth?target=user](https://www.cusna.io/oauth2?target=user)
* <https://www.cusna.io/oauth2?target=admin>

At the end of the process, a dialog will show you the credentials you've just created. Copy the Client ID and Client Secret, as you'll need them in the next steps to finalize the setup in the Cusna dashboard.

<div align="left"><figure><img src="/files/lUZtOe1HQyXkS76a6Pey" alt="" width="375"><figcaption></figcaption></figure></div>

### 5. Enable APIs & Services

Finally make sure to have enabled the proper API services. Go to **Enabled APIs & Services** form the main sidebar menu.

<div align="left"><figure><img src="/files/zWaSDxRUHdhPb9D2Iz5I" alt="" width="188"><figcaption></figcaption></figure></div>

Make sure to have in the list:

* **Admin SDK APIs**

If this API is not in your list, click **+ Enable APIs & Services** and in the new page find and enable Admin SDK APIs.

## Setup Cusna

### Enable Google integration

Go to **Setup** > **Integrations** and click **New Integrations** in the **Identity Providers** card.  Select **Google Account**.

<figure><img src="/files/xLv9vXHJuPNu8x7Y4G78" alt=""><figcaption></figcaption></figure>

Enter your Google Cloud domain in the **Domain** filed.

Fill the **Client ID** and **Client secret** inputs with the values created in the step above.

A User with Google Admin permissions needs to click on the **Setup** button to authorize the app.&#x20;

On click, a new widows opens up int he browser, where the user is redirected to login with Google and then  to accept the required permissions and scopes on behalf of the organization.

{% hint style="info" %}
The app requires permissions that not all Google users in your organizations might have. We advise that the same user who initialized the app in the Google Cloud console also to complete this step.
{% endhint %}

### Advanced configurations

Once the Google integration is complete, go to **Setup**, **General** in the **Access Control & Onboarding** card.

Here you can configure advances options such as:

* Label for the button that appears in the WiFi Portal
* Configure [Group Mapping](/cloud-identity-platforms-integrations/enterprise-cloud-idps/group-mapping) rules
* Enable access only for users that belong to one of the mapped groups


# Shibboleth

This integration guide has been tested on Shibboleth version 4 and version 5. &#x20;

### Note

> Throughout this guide, `%{idp.home}` is the directory where you installed your Shibboleth Identity Provider. When configuring Shibboleth, make sure to replace `%{idp.home}` with your specific path (e.g. `/opt/shibboleth`)

### Preliminary steps

#### 1. Ensure Compatibility with SAML2 Endpoints

To ensure that your Shibboleth IdP is compatible with SAML2 endpoints, you need to locate and inspect the IdP metadata file.

This file is typically stored at the location `%{idp.home}/metadata/idp-metadata.xml`.

Check the `<SingleSignOnService>` entries in the metadata file to verify whether the existing endpoints are compatible with **SAML2**.

Typically, the base URL is already configured in your IdP settings and corresponds to something like `https://idp.example.org/idp/profile`, where `idp.example.org` is the IdP’s domain in this example.

Here are the required SAML2 bindings:

```xml
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                     Location="https://idp.example.org/idp/profile/SAML2/Redirect/SSO"/>

<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                     Location="https://idp.example.org/idp/profile/SAML2/POST/SSO"/>

<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
                     Location="https://idp.example.org/idp/profile/SAML2/POST-SimpleSign/SSO"/>

<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
                     Location="https://idp.example.org/idp/profile/SAML2/SOAP/ECP"/>
```

{% hint style="info" %}
**Note:** The URLs above are provided as examples. **Replace** `https://idp.example.org/idp` with the actual domain and base path used by your IdP.
{% endhint %}

These bindings should already be present in your metadata file. If you do not see them, you will need to **add** these entries manually to ensure your IdP supports the required SAML2 endpoints. Do not replace any existing entries; simply append these lines to your metadata file as necessary.

#### 2. Download IdP metadata file

Download and store the metadata XML file from your Shibboleth IDP, usually at the following location `%{idp.home}/metadata/idp-metadata.xml` .

<details>

<summary>Example of  <code>idp-metadata.xml</code> with SAML2 endpoint compatibility</summary>

```xml
<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
                     xmlns:shibmd="urn:mace:shibboleth:metadata:1.0"
                     entityID="https://idp.example.org/idp/shibboleth">
    <!-- Signing -->
    <KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <!-- Encryption -->
    <KeyDescriptor use="encryption">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
                 
    <!-- General IdP Information -->
    <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

        <!-- 
            Already configured endpoints
            ...
        -->        
        
        <!-- SAML2 Endpoints -->
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                                Location="https://idp.example.org/idp/profile/SAML2/Redirect/SSO"/>
        
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                                Location="https://idp.example.org/idp/profile/SAML2/POST/SSO"/>
        
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign"
                                Location="https://idp.example.org/idp/profile/SAML2/POST-SimpleSign/SSO"/>
        
        <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"
                                Location="https://idp.example.org/idp/profile/SAML2/SOAP/ECP"/>
        
        <!-- Other endpoints already configured, e.g. Shibboleth -->
        <!--
        <md:SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"
                                    Location="https://idp.example.org/idp/profile/Shibboleth/SSO"/>
        -->

    </md:IDPSSODescriptor>
</EntityDescriptor>
```

</details>

### Cusna setup

1. Go to **Setup** and find the **IdP Integration** card.&#x20;
2. Select **SAML** as **System** and  **Shibboleth** as **Type**.

<figure><img src="/files/ANCLlJi62IcWKLUNaGil" alt="" width="563"><figcaption></figcaption></figure>

2. After selecting Shibboleth as SSO system, fill in a name to identify the integration. \
   Then upload the IdP metadata XML file (downloaded in the preliminary step).

<figure><img src="/files/iKxHDDO9sCWZhyfJmhmq" alt="" width="563"><figcaption></figcaption></figure>

3. Once the name is filled and the file is uploaded, click the **Save** button. This action will save the integration data in the Cusna system.

<figure><img src="/files/ZwkZUHZJqcGJbATPT0QC" alt="" width="563"><figcaption></figcaption></figure>

4. Download the **Cusna metadata XML file** from the download section that will appear. Rename the metadata file to `cusna-metadata.xml` .

<details>

<summary>Example of <code>cusna-metadata.xml</code></summary>

```xml
<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86">
    <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
        <md:KeyDescriptor use="signing">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:KeyDescriptor use="encryption">
            <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>...</ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </md:KeyDescriptor>
        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://public-eu-lb.cloud4wi.com/cusna/lynx/login/saml2/sso/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86" index="1"/>
    </md:SPSSODescriptor>
</md:EntityDescriptor>

```

</details>

5. Take note of the parameter `entityID` inside the `cusna-metadata.xml` file. This value will be usued in the IdP configuration to identify the Cusna SP .

<details>

<summary>Example of <code>entityID</code> </summary>

```
https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86
```

</details>

### Shibboleth server setup

#### Link  Shibboleth IdP and Cusna SP

There are multiple ways to configure the IdP to correctly communicate with the Cusna SP.

The following one is one general option:

#### 1. Provide SP metadata with static file system metada provider

* **Upload the Metadata File**\
  First, upload the `cusna-metadata.xml` file (which you downloaded in the previous step) to a folder on the Shibboleth server. For example, place it in the following directory:\
  `%{idp.home}/metadata/`
* **Edit the Metadata Provider Configuration**\
  Next, open the Shibboleth metadata provider configuration file `metadata-providers.xml`. This file can be found at the following location:\
  `%{idp.home}/conf/metadata-providers.xml`
* **Add the Metadata Provider Entry**\
  In `metadata-providers.xml`, add the following entry to include the Cusna metadata file as a static file system metadata provider:

```xml
<MetadataProvider id="CusnaMetadata" xsi:type="FilesystemMetadataProvider" metadataFile="%{idp.home}/metadata/cusna-metadata.xml"/>
```

<details>

<summary>Example of edited <code>metadata-providers.xml</code></summary>

{% code fullWidth="true" %}

```xml
<?xml version="1.0" encoding="UTF-8"?>
<MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider"
    xmlns="urn:mace:shibboleth:2.0:metadata"
    xmlns:security="urn:mace:shibboleth:2.0:security"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    xmlns:alg="urn:oasis:names:tc:SAML:metadata:algsupport"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:ds11="http://www.w3.org/2009/xmldsig11#"
    xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:enc11="http://www.w3.org/2009/xmlenc11#"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="urn:mace:shibboleth:2.0:metadata http://shibboleth.net/schema/idp/shibboleth-metadata.xsd
                        urn:mace:shibboleth:2.0:security http://shibboleth.net/schema/idp/shibboleth-security.xsd
                        urn:oasis:names:tc:SAML:2.0:assertion http://docs.oasis-open.org/security/saml/v2.0/saml-schema-assertion-2.0.xsd
                        urn:oasis:names:tc:SAML:2.0:metadata http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd
                        urn:oasis:names:tc:SAML:metadata:algsupport http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-algsupport-v1.0.xsd
                        http://www.w3.org/2000/09/xmldsig# http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd
                        http://www.w3.org/2009/xmldsig11# http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/xmldsig11-schema.xsd
                        http://www.w3.org/2001/04/xmlenc# http://www.w3.org/TR/xmlenc-core/xenc-schema.xsd
                        http://www.w3.org/2009/xmlenc11# http://www.w3.org/TR/2013/REC-xmlenc-core1-20130411/xenc-schema-11.xsd">

    <!-- 
        Already existent metadata providers
        ...
    -->
    
    <!-- Static Filesystem Metadata Provider for Cusna SP -->
    <MetadataProvider id="CusnaMetadata" xsi:type="FilesystemMetadataProvider" metadataFile="%{idp.home}/metadata/cusna-metadata.xml"/>
    <!-- End Of Static Filesystem Metadata Provider for Cusna SP -->

    <MetadataProvider id="incommon" xsi:type="DynamicHTTPMetadataProvider"
                  maxCacheDuration="PT24H" minCacheDuration="PT10M">
      <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
                  certificateFile="%{idp.home}/credentials/inc-md-cert-mdq.pem" />
      <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P14D" />
      <MetadataQueryProtocol>https://mdq.incommon.org/</MetadataQueryProtocol>
    </MetadataProvider>
</MetadataProvider>

```

{% endcode %}

</details>

#### 2. Ensure Shibboleth IdP Trusts the SP

To establish a trust relationship between Shibboleth and Cusna, you need to define a new **RelyingParty** element in the Shibboleth configuration file located at:\
`%{idp.home}/conf/relying-party.xml`

* **Edit the Relying Party Configuration**\
  Open the `relying-party.xml` file and add the following XML snippet to define the Cusna service provider (SP):

  ```xml
  <bean parent="RelyingPartyByName" c:relyingPartyIds="%{entityID}">
      <property name="profileConfigurations">
          <list>
              <bean parent="Shibboleth.SSO" p:postAuthenticationFlows="attribute-release" />
              <bean parent="SAML2.SSO" 
                  p:encryptAssertions="false" 
                  p:encryptNameIDs="false" 
                  p:signResponses="false" 
                  p:signAssertions="true" 
                  p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
          </list>
      </property>
  </bean>
  ```

{% hint style="info" %}
Make sure the `c:relyingPartyIds` (line 1) matches the **entityID** value specified in Cusna metadata XML file **cusna-metadata.xml**.&#x20;

In our example this would be

`c:relyingPartyIds="https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86"`
{% endhint %}

<details>

<summary>Example of edited <code>relying-party.xml</code></summary>

```xml
<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans.xsd">
           
    <!-- 
        Already existent relying parties
        ...
    -->

    <!-- Relying Party Configuration for Cusna -->
    <bean parent="RelyingPartyByName" c:relyingPartyIds="https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86">
        <property name="profileConfigurations">
            <list>
                <!-- Shibboleth SSO Configuration -->
                <bean parent="Shibboleth.SSO" p:postAuthenticationFlows="attribute-release" />
                
                <!-- SAML2 SSO Configuration -->
                <bean parent="SAML2.SSO" 
                      p:encryptAssertions="false" 
                      p:encryptNameIDs="false" 
                      p:signResponses="false" 
                      p:signAssertions="true" 
                      p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" />
            </list>
        </property>
    </bean>

    <!-- You can add more Relying Party configurations below if needed -->

</beans>
```

</details>

#### 3. SAML attribute mapping

To ensure proper communication between your Shibboleth Identity Provider (IdP) and the Cusna Service Provider (SP), you must map the attributes in a way that Cusna can understand. The attribute names must comply with the SAML2 standard and be correctly mapped to the expected values.

Please note that the attribute naming matches with the SAML2 standard.

<table><thead><tr><th width="220.03558349609375">Internal Attribute</th><th width="377.41510009765625">SAML Attribute Name</th><th>Required</th></tr></thead><tbody><tr><td><code>mail</code></td><td><code>urn:oid:0.9.2342.19200300.100.1.3</code></td><td>yes</td></tr><tr><td><code>givenName</code></td><td><code>urn:oid:2.5.4.42</code></td><td>no</td></tr><tr><td><code>sn</code></td><td><code>urn:oid:2.5.4.4</code></td><td>no</td></tr><tr><td><code>eduPersonAffiliation</code></td><td><code>urn:oid:1.3.6.1.4.1.5923.1.1.1.1</code></td><td>no</td></tr></tbody></table>

The following steps guide you through configuring your Shibboleth IdP to send the required attributes in a format that Cusna can process.&#x20;

This procedure will ensure that the configuration for Cusna does not interfere with other Service Providers (SPs) that may also be configured on your IdP.

* Define new Cusna specific **Attribute Mappings** in **`attribute-resolver.xml`**\
  \
  To start, you need to define the necessary attribute mappings in the `attribute-resolver.xml` file, which is located in:\
  \
  `%{idp.home}/conf/attribute-resolver.xml`

* Add the following definitions to this file to map the required attributes:<br>

  ```xml
  <!-- EMAIL -->
  <AttributeDefinition id="cusnaEmail" xsi:type="ScriptedAttribute">
      <Dependency ref="mail"/>
      <Script><![CDATA[ cusnaEmail = mail.getValues(); ]]></Script>
      <AttributeEncoder xsi:type="SAML2String"
          name="urn:oid:0.9.2342.19200300.100.1.3"
          nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          friendlyName="email"/>
  </AttributeDefinition>

  <!-- FIRST NAME -->
  <AttributeDefinition id="cusnaGivenName" xsi:type="ScriptedAttribute">
      <Dependency ref="givenName"/>
      <Script><![CDATA[ cusnaGivenName = givenName.getValues(); ]]></Script>
      <AttributeEncoder xsi:type="SAML2String"
          name="urn:oid:2.5.4.42"
          nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          friendlyName="firstName"/>
  </AttributeDefinition>

  <!-- LAST NAME -->
  <AttributeDefinition id="cusnaSn" xsi:type="ScriptedAttribute">
      <Dependency ref="sn"/>
      <Script><![CDATA[ cusnaSn = sn.getValues(); ]]></Script>
      <AttributeEncoder xsi:type="SAML2String"
          name="urn:oid:2.5.4.4"
          nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          friendlyName="lastName"/>
  </AttributeDefinition>

  <!-- GROUP IDS -->
  <AttributeDefinition id="cusnaGroups" xsi:type="ScriptedAttribute">
      <Dependency ref="eduPersonAffiliation"/>
      <Script><![CDATA[ cusnaGroups = eduPersonAffiliation.getValues(); ]]></Script>
      <AttributeEncoder xsi:type="SAML2String"
          name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
          nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          friendlyName="groupIds"/>
  </AttributeDefinition>
  ```

<details>

<summary>Example of edited <code>attribute-resolver.xml</code></summary>

```xml
<?xml version="1.0" encoding="UTF-8"?>
<AttributeResolver xmlns="urn:mace:shibboleth:2.0:resolver"
                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                   xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver resolver.xsd">

    <!-- 
        Already existent definitions
        ...
    -->

    <!-- EMAIL -->
    <AttributeDefinition id="cusnaEmail" xsi:type="ScriptedAttribute">
        <Dependency ref="mail"/>
        <Script><![CDATA[ cusnaEmail = mail.getValues(); ]]></Script>
        <AttributeEncoder xsi:type="SAML2String"
            name="urn:oid:0.9.2342.19200300.100.1.3"
            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            friendlyName="email"/>
    </AttributeDefinition>

    <!-- FIRST NAME -->
    <AttributeDefinition id="cusnaGivenName" xsi:type="ScriptedAttribute">
        <Dependency ref="givenName"/>
        <Script><![CDATA[ cusnaGivenName = givenName.getValues(); ]]></Script>
        <AttributeEncoder xsi:type="SAML2String"
            name="urn:oid:2.5.4.42"
            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            friendlyName="firstName"/>
    </AttributeDefinition>

    <!-- LAST NAME -->
    <AttributeDefinition id="cusnaSn" xsi:type="ScriptedAttribute">
        <Dependency ref="sn"/>
        <Script><![CDATA[ cusnaSn = sn.getValues(); ]]></Script>
        <AttributeEncoder xsi:type="SAML2String"
            name="urn:oid:2.5.4.4"
            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            friendlyName="lastName"/>
    </AttributeDefinition>

    <!-- GROUP IDS -->
    <AttributeDefinition id="cusnaGroups" xsi:type="ScriptedAttribute">
        <Dependency ref="eduPersonAffiliation"/>
        <Script><![CDATA[ cusnaGroups = eduPersonAffiliation.getValues(); ]]></Script>
        <AttributeEncoder xsi:type="SAML2String"
            name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
            nameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
            friendlyName="groupIds"/>
    </AttributeDefinition>

</AttributeResolver>

```

</details>

* Define **Attribute Release Policy** in `attribute-filter.xml` <br>

  Next, configure the `attribute-filter.xml` file to ensure that only the attributes necessary for Cusna are released. This file is located in:\
  \
  `%{idp.home}/conf/attribute-filter.xml`&#x20;

  \
  Add the following filter policy to the file:<br>

  ```xml
  <?xml version="1.0" encoding="UTF-8"?>
  <AttributeFilterPolicyGroup xmlns="urn:mace:shibboleth:2.0:afp"
                              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                              xsi:schemaLocation="urn:mace:shibboleth:2.0:afp afp.xsd">

      <!-- Release attributes for Cusna -->
      <AttributeFilterPolicy id="ReleaseCusnaMappedAttributes">
          <PolicyRequirementRule xsi:type="Requester" value="%{entityID}"/>

          <!-- Email -->
          <AttributeRule attributeID="cusnaEmail">
              <PermitValueRule xsi:type="ANY"/>
          </AttributeRule>

          <!-- First Name -->
          <AttributeRule attributeID="cusnaGivenName">
              <PermitValueRule xsi:type="ANY"/>
          </AttributeRule>

          <!-- Last Name -->
          <AttributeRule attributeID="cusnaSn">
              <PermitValueRule xsi:type="ANY"/>
          </AttributeRule>

          <!-- Group IDs -->
          <AttributeRule attributeID="cusnaGroups">
              <PermitValueRule xsi:type="ANY"/>
          </AttributeRule>
      </AttributeFilterPolicy>

  </AttributeFilterPolicyGroup>
  ```

  \
  **PolicyRequirementRule**: Ensures that these attributes are only released to the Cusna SP by checking the `entityID` of the requesting SP. The `value="%{entityID}"` should match the `entityID` in the Cusna metadata XML file.\
  \
  **AttributeRules**: Each attribute (`cusnaEmail`, `cusnaGivenName`, `cusnaSn`, `cusnaGroups`) is released to the requesting SP with a `PermitValueRule` that allows all values for each attribute.

{% hint style="info" %}
Make sure the `Requester` matches the **entityID** value specified in Cusna metadata XML file **cusna-metadata.xml**.&#x20;

In our example this would be

\<PolicyRequirementRule xsi:type="Requester" value="[https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86"/>](https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86"/>)
{% endhint %}

<details>

<summary>Example of edited <code>attribute-filter.xml</code></summary>

```xml
<?xml version="1.0" encoding="UTF-8"?>
<AttributeFilterPolicyGroup xmlns="urn:mace:shibboleth:2.0:afp"
                            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                            xsi:schemaLocation="urn:mace:shibboleth:2.0:afp afp.xsd">

    <!-- 
        Already existent filter policies
        ...
    -->

    <!-- Filter Policy for Cusna SP -->
    <AttributeFilterPolicy id="ReleaseCusnaMappedAttributes">
        <!-- Restrict this policy to the Cusna entity ID -->
        <PolicyRequirementRule xsi:type="Requester" value="https://cusnaio.cloud4wi.com/saml2/lynx/v1/289e7f7522caec89e43537c78b997bbb145f783b8bcb367fe74e681f71847b86"/>

        <!-- Release email attribute -->
        <AttributeRule attributeID="cusnaEmail">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>

        <!-- Release given name attribute -->
        <AttributeRule attributeID="cusnaGivenName">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>

        <!-- Release surname (last name) attribute -->
        <AttributeRule attributeID="cusnaSn">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>

        <!-- Release group IDs attribute -->
        <AttributeRule attributeID="cusnaGroups">
            <PermitValueRule xsi:type="ANY"/>
        </AttributeRule>
    </AttributeFilterPolicy>

</AttributeFilterPolicyGroup>

```

</details>

This configuration ensures that **only Cusna SP** receives the required attributes with the specified names, without affecting other SPs configured on your IdP.

At this point the integration is correctly configured and users can login using their own credentials.


# Group mapping

With some type of external connectors, Cusna allows to define static rules to assign external users to a destination Group in Cusna, based on some criteria.

In general, the feature allows to statically define the mapping form a source group id (which definition depends on the IdP used) and the destination Cusna [Group](/service-management/groups).

{% hint style="info" %}
For most IdPs, you also have the option to make sure that only users that are mapped to a group are granted access to the service, by enabling the option **Authorize only members of mapped Groups**
{% endhint %}

### **Microsoft Entra (oAtuh)**

In case of Microsoft, it possible to crete rules that map the Azure Group ID into a Cusna Group. You can select the Microsoft Entra ID Group form a dropdown menu

<figure><img src="/files/1yGGilIyKv17gpNo2Giz" alt=""><figcaption></figcaption></figure>

### **Google (oAtuh)**

In case of Google, it possible to crete rules that map the Google Group  into a Cusna Group. You can select the Google Group form a dropdown menu.

<figure><img src="/files/xDMzlAOYEDvsQgcbHc1p" alt=""><figcaption></figcaption></figure>

### **SAML**

In case of SAML integration, for most systems, it possible to crete rules that map the source Group  into a Cusna Group. You need to enter the SAML Group identifier manually in the Source Group ID input.

<figure><img src="/files/k8AnjQaIx681KZ33Zwnr" alt=""><figcaption></figcaption></figure>

#### Microsoft Entra&#x20;

For Microsoft Entra ID, you need to enter the value of the Object ID of the Group that you can find the in the Azure Portal.&#x20;

<figure><img src="/files/bJKnRTO3yxPG1T0nGCST" alt=""><figcaption></figcaption></figure>


# Passwordless SSO

At Cusna, we are big believers that password are complicated and we do smooth user experience avoiding to use them.

A simpler yet effective and secure method to enable self-serve onboarding while preserving security is to:

1. Let a user enter its email in the WiFi Portal
2. Cusna checks via APIs in external systems (IdPs, CIAMs, any platform) if the email exists and is associated to an individual with the right permissions.
3. If the user exists and is authorized, Cusna creates the Account and send a secure magic link to the user email - which proves the user owns the email
4. The user clicks the magic link and get access to the Tenant Portal where gets access to the WiFi passphrase

### Passwordless SSO workflow

<figure><img src="/files/PRY2oolrhLMJW3C5JaUN" alt=""><figcaption></figcaption></figure>

When [**Groups**](/service-management/groups) is enabled, if the external identity system reports the user belongs to a group, Cusna automatically associates the user to an equivalent group (which is also created automatically if it doesn't exists already).

{% hint style="info" %}
Cusna can integrate with literally everything. Contact our team to learn more.&#x20;
{% endhint %}


# Custom HTTP Request

You can easily integrate any external user directory by using the **Custom HTTP** identity verification method.

In the External Identity Provider section of the Setup page, create a new Integration and select **Custom HTTP Request**.

In the configuration panel, enter your endpoint URL where the request will be made.

<figure><img src="/files/gmVMTP8vGHRHXrn8rbwB" alt=""><figcaption></figcaption></figure>

Cusna will make an **HTTP GET** request to the configured endpoint with the following parameters:

* **email**: email address the user inserted in the portal
* **locationid**: external id configured in the Network associated to the WiFi Portal

Example:

```
GET https://mycustomendpoint.com/users?email=email@cusna.io&locationid=1234
```

The GET Request also includes by default a custom header parameter tha tyou can use for futher validating the incoming requests and identifying the source Cusna account

* **x-cusna-organization**: \<id of your Cusna organization>

Cusna expects to receive as a response a JSON with the following content

```json
{
  "valid": true,
  "id": "1232423532523",
  "firstName":"Ivan",
  "lastName":"Muccini",
  "groupId":"employees12345",
  "groupName":"employees",
  "terminationDate":"01/08/2024"
}
```

* **valid:**  boolean, indicate if the account is valid or not (mandatory)
* **id**: external id of the record (optional)
* **firstName**: first name of the user (optional)
* **lastName**: last name of the user (optional)
* **groupId**: ID of the group the user belongs to, if any (optional)&#x20;
* **groupName**: name of the group the user belongs to, if any (optional)&#x20;
* **terminationDate**: date the account service will be automatically suspended 9optional)


# MSP Dashboard

MSP accounts allows partners and service providers to manage multiple organizations from the same dashboard.

<figure><img src="/files/cB8Mxret2ElXQ11xH3Qu" alt=""><figcaption></figcaption></figure>

The main dashboard shows summary KPIs related ot the MSP, including:

* total number of managed Organizations / max number of Organizations allowed on the MSP
* total number of Accounts / max number of Accounts allowed on the MSP
* total number of Networks

## Managing Organizations

The Organization table shows the list of the Organizations managed by the MSP. By clicking on the Login button, the MSPo can login into the dashboard of a specific Organization.

## Creating new Organizations

If the Max Organization allowance of the MSP is greater than the current number of managed organizations, the MSP is allows to create a new Org. Creating a new Organization only required to set the **Name** of the Organizations as input and the **MAX MAU** threshold.

If you wish to not block end-users from onboarding into the service, simply enter a big number (e.g. 1 million)

<figure><img src="/files/1djEnl22q6sIGF6RUN6D" alt=""><figcaption></figcaption></figure>

## Managing MSP administrators

Form the Admin menu, the Admin assigned as "Owner" of the MSP, can create additional Admin accounts that will have all permissions except creating other MSP Admins

<figure><img src="/files/3ewJD3yquBYVa5hYdEB3" alt=""><figcaption></figcaption></figure>

When creating a new Admin is possible to:

* elect the new Admin as the Owner of the MSP account
* create a standard MSP Admin and optionally add additional permissions, including
  * create Organizations
  * purchase Licenses
* opt to notify new Admin via email. The welcome email include a link to let the new admin set up their credentials

<figure><img src="/files/10ToBBk4avj8YJVRFcoz" alt=""><figcaption></figcaption></figure>

## License management

On the License page, the MSP Admins can visualize the status of current subscriptions metrics and extend current allowances.

{% hint style="info" %}
**What are MAA (Monthly Active Account)**\
Monthly Active Accounts (MAA) quantifies the number of unique Accounts that have held '*Active*' status at any point during a given month. An '*Active*' account is authorized for network access, while an '*Inactive*' account is not. Accounts can transition between these statuses through automated rules or manual changes via the admin console.

The MAA metric captures all accounts that were active during the month, including those active at the month's start and any that became active during the month. If an account switches between active and inactive multiple times within the same month, it is counted only once in the MAA tally.
{% endhint %}

### Summary

<figure><img src="/files/vlNMMz5eQ6slyqKo9Z87" alt=""><figcaption></figcaption></figure>

The first sections shows the main current relevant metrics:

* **Current Month MAAs:**  number of Active Accounts accounted for the current Month.&#x20;
* Current level of **MAA allowance**: MAA Allowance represent a thresholds of MAAs under which the Organization does not incur in any Overage fees.
* **Overage MAAs**: number of MAAs accounted for the current  month that exceed the current MAA Allowance

### **MAU Allowance History**

The **MAU Allowance History** section, shows the level of MAU Allowance on the past 12 months. It also reports all past orders to extend the MAU allowance

<figure><img src="/files/jK6ZqA8stsuXemYHcdeF" alt=""><figcaption></figcaption></figure>

By click the "**Extend**" button, the MSP Admin can order a MAA Subscription among those available. Fro example, by ordering quantity 2 of the SKU "*1K MAA Allowance*", the organization MAU Allowance increases of 2,000 MAA for the next 12 months

<figure><img src="/files/RCgRODRu1z3CljC4pq43" alt="" width="375"><figcaption></figcaption></figure>

### **Monthly Active Account History**

**The Monthly Active Account History** section shows the level of MAA for the past 12 months for the MSP overall, or for one specific Organization as selected form the dedicated dropdown.

The table provides the detail of the MAAs for each Organization for every month of the past 12 months, or for a specific month as selected form the dedicated dropdown

<figure><img src="/files/IeaUlUy2gnrWpbHkXMxO" alt=""><figcaption></figcaption></figure>

## Anomalies

The **Anomalies** page provide the MSP visibility of all critical service notifications of managed Organizations to help identify issues affecting the service availability.

<figure><img src="/files/101lgA06XBypXAdX2sev" alt=""><figcaption></figcaption></figure>


# MSP Account settings

## Account settings

Form the profile menu, click **Account Settings** to access the configuration page of your MSP. This menu is only available to the Admin user set as Owner of the MSP account.

<figure><img src="/files/M8hdueRatqn48xCGxyCK" alt=""><figcaption></figcaption></figure>

In this page, you can change:

* **MSP Name**
* **MSP Admin Owner**: you can select another MSP Admins (see Admins) to become Owner of this MSP account. if you change owner, you transfer the ownership and you'll lose access to this page immediately
* **Allowed vendors**: this setting limits the list of available WiFi vendors for the managed Organizations &#x20;
* Default **Terms of Use**: all new Organizations will be initialized with this Terms of Use link
* Default **Privacy Policy**: **Use**: all new Organizations will be initialized with this Privacy Policy link
* **Logo**: all new Organizations will be initialized with this logo, but the Organization Admin can change it later
* **Accent color**:  all new Organizations will be initialized with this accent color

## Single Sign On (SSO)

If your MSP is enabled, in this page you can find a card named SSO where you can setup and manage the ability for your corporate users to login into the Cusna MSP account using the corporate account.

{% hint style="info" %}
Only the MSP Admin with [**Owner**](https://www.cusna.io/app?page=alladmins\&tab=list) role can access this option. Go to the Admins page to check who is the Owner of your MSP account.
{% endhint %}

### Initial Setup

1. To setup SSO click **Setup**.
2. From the **Idp Service** dropdown, select an IdP that supports SAML 2.0 authentication, for example Entra ID, or Okta.
3. in the **Domain** input, enter the domain of your corporate emails (e.g. "cuisna.io")

Depending on the IdP service you picked, you might see different fields, but usually you can copy from the interface:

* Reply URL
* Entity ID

You need these values to setup the SAML authentication into your IdP service.

<details>

<summary>Microsoft Entra instructions</summary>

* Log in to Microsoft Azure in a new browser tab, click **Enterprise applications** > **New application**.
* Click **Create your own application**, enter a name for the application, select **Integrate any other application you don't find in the gallery (Non-gallery)** and click **Create**.<br>

  <div align="left"><figure><img src="/files/wTHqtmqylN5vYQolGJaL" alt="" width="375"><figcaption></figcaption></figure></div>
* Click **Assign users and group** to define which Users or User groups can login with this application. You can assign individual users or groups of users.<br>

  <figure><img src="/files/d2C79gqcwy8yEskCYvCn" alt=""><figcaption></figcaption></figure>

  Once done with the assignment, go back to the main page of the app.<br>
* Click **Single sign on** on the sidebar, select **SAML.**\
  The page **Set up Single Sign-On with SAML** appears.\
  \
  Click **Edit** in the "**Basic SAML Configuration**" card.  Enter the **Identifier (Entity ID)** and the **Reply URL** value provided in the Cloud4Wi Dashboard (see top of the page). Click Save.\
  \
  The value will be reflected in the related card.\ <br>

  <figure><img src="/files/r34lfAVFQvlfWdj3C2F6" alt=""><figcaption></figcaption></figure>
* Click **Edit** on the "**Attributes & Claims**" card. Default values are usually the correct ones, but make sure that :&#x20;
  1. claim name **Unique User Identifier** matches source attribute **user.userpincipalname**
  2. claim name **emailaddress** matches source attribute **user.mail**
  3. claim name **givenname** matches source attribute **user.givenname**
  4. claim name **name** matches source attribute **user.userprincipalname**
  5. claim name **surname** matches source attribute **user.surname**
  6. claim name **groups** matches source attribute **user.groups \[All]**\
     if you don't have this entry, click on the button "**+ Add a group claim**" and select **All groups** in the Group Claims dialog and make sure the **Source Attribute** field is set to **Group ID**\ <br>

     <figure><img src="/files/lv1n47stJRAyUJTI35ev" alt=""><figcaption></figcaption></figure>
* Go back to the main screen **Set up Single Sign-On with SAML**. Find in the page the section SAML **Certificates**.  Find the attribute **App Federation Metadata Url** and copy its value in the Cusna setup panel in the filed **Metadata URI** \ <br>

  <figure><img src="/files/esQGEGJBvGYJ5vT1H0YO" alt=""><figcaption></figcaption></figure>

  In Cusna, click **Setup**.
* Ensure all users can sign on without the need to set up separate permissions in Entra ID. \
  Form the main page of the application,  go to the **Properties** page and select **No** for **Assignment required** and **Yes** to **Visible to users**.<br>

  <figure><img src="/files/O6u51kabW90iW2TUOWA6" alt=""><figcaption></figcaption></figure>

</details>

<details>

<summary>Google</summary>

1. Within your Google Workspace admin home page, click **Apps**.

   [![](https://support.purple.ai/hc/article_attachments/7330686191133)](https://support.purple.ai/hc/article_attachments/7330686191133)
2. Click **Web and mobile apps**.

   [![](https://support.purple.ai/hc/article_attachments/7330715109149)](https://support.purple.ai/hc/article_attachments/7330715109149)
3. Click **Add App** > **Add custom SAML app**.

   [![](https://support.purple.ai/hc/article_attachments/7330715136797)](https://support.purple.ai/hc/article_attachments/7330715136797)
4. Add an app name and icon (this displays to users when they sign in to WiFi via the Google Workspace login).
5. On the following page click **Download Metadata** to download the metadata XML file, as you need this information to enter into the Cusna portal. You can return to these details at any time.\
   \
   ![](/files/MZN5qzKHWg0kQMWk21nE)
6. In the following page, complete the Service provider details as follows:

   | ACS URL        | Enter the **Reply Url** value shown in the Cusna dashboard  |
   | -------------- | ----------------------------------------------------------- |
   | ACS entity     | Enter the **Entity ID** value shown in the Cusna dashboard. |
   | Name ID format | EMAIL                                                       |
   | Name ID        | Basic Information > Primary email                           |
7. Click **Continue** and and in the following page add the following attribute mapping:\
   \- First Name > `firstName`\
   \- Last Name > `lastName`\
   \- Primary Email > `primaryEmail`\
   \
   ![](/files/Z5jYG6PxhJS70VJddifb)\
   \
   In the **Group membership** card, select the Groups that you want to pass during the authentication, and in the App Attribute enter "`GROUP_`"\
   ![](/files/vC6hvvD2GJkyysQOSgVX)\
   \
   You can later configure the groups names in the Cunsa porta to filter only the groups that you want to allow.<br>
8. To complete the set up, click **Finish**.

Form the main screen, click **View Details** form the **User Access** card.\
![](/files/STYBl68mCmljLYjTE1QH)\
Make sure to set the **Service Status** to **On for everyone**. In alternative, you can set selective permissions to specific Groups or Organizational Units.

</details>

In the **List of SAML Groups**, you can enter the list of group ids/names (depending on the IdP) that you want to authorize for authenticating in the Cusna account. If you leave this option empty, all users will be authorized to signup. This filtering option is checked at every user login, so you can chance at any time.

Finally, in the **Default Permissions** dropdown you can select the additional permissions you want to assign by default to users signing up via SAML. If you change this configuration later on, it will be reflected on the users on their next login.&#x20;

Click **Setup** to save the settings.

<figure><img src="/files/Tl94vfkVgjqgNrbGofPw" alt=""><figcaption></figcaption></figure>

Make sure to **enable the SSO** by selecting the toggle on the SSO box once you have finalized the setup.

<figure><img src="/files/QSprdwByiuclySjhMVBm" alt=""><figcaption></figcaption></figure>

### Users authentication

User can pick the **Sign in via SSO** in the Login page and enter their email address. If they are allowed, they'll be redirected to login in the IdP service login page.

Upon successful authentication, users are logged in to the Cusna MSP dashboard.

<figure><img src="/files/EjZ2RNqaW7dkRmNgsGuB" alt=""><figcaption></figcaption></figure>


# Billing

The Billing module allows Organizations to collect payments directly from their residents.

## Getting started

Before getting started, you need to setup your billing account. Cusna relies on Stripe integration to onboard Organization payments.

![](/files/uUo8Qx4SWpWmioDqWroD)

In the **Billing** section, click **Setup your billing accoun**t.

You'll b redirect to an external setup wizard. Follow the instruction. At the end of the process you'll be redirected to Cusna.

If you don't finalize your account during the initial setup, for example you have some missing information, you'll see a button **Finalize Setup**, to continue the process.

![](/files/qswZ8w8VSn5jEuzS0SAL)

## Managing subscriptions

Once your account has been successfully set up, you can create one or more subscriptions. For example, you can have one default subscription and some discounted subscriptions.

![](/files/B2pPOT24jh1btZ8xWfra)

## WiFi Portal

When Billing is enabled, on their first login users are prompted to activate their subscription.

![](/files/HEp4Oz7uXo1hZ0Ore2Dc)

By clicking on a button, they are redirected to the Stripe Checkout experience where they confirm the subscription and provide their payment method.

{% hint style="info" %}
Resident are invoiced and charged **immediately** for the service of the current month period.&#x20;
{% endhint %}

Residents can see their current subscription plan, when the next invoice is scheduled for and its amount.

![](/files/KAYDC7gNeZGjSDBN87P6)

{% hint style="info" %}
The next invoice amount due might not be the same as the monthly rate. This happens when administrator change the Resident subscription with a different pricing. &#x20;
{% endhint %}

By clicking on **Past invoices**, Residents can see the entire history of past invoices.


# White label

{% hint style="info" %}
White label options are available on demands for MSPs with large order commitments and comes with additional charges
{% endhint %}

Cusna white label is designed to empower managed service providers to deliver a turn key solution to their customers with a full branded experience.

The white label package includes:

* Custom platform terms of service and privacy policy
* Custom domain
* Custom email sender
* Custom default logo
* Custom accent color

{% hint style="info" %}
White label option is available only for large accounts for a premium fee.
{% endhint %}


# Passpoint

Passpoint option allows resident to download a Passpoint profile directly form the WiFi portal, on their supported devices. Passpoint will work on all the access points part of the customer network.

## Network Setup

To enable Passpoint you need to create and or configure a dedicated Passpoint-enabled SSID on your network.

To find step by step user guides on how to configure your WiFi network, please refer to our Core Paltform user guides:

* [Aruba Central](https://cloud4wi.zendesk.com/hc/en-us/articles/21805428506893-Aruba-Central-Passpoint-configuration)
* [Cisco Catalyst 9800](https://cloud4wi.zendesk.com/hc/en-us/articles/10531050431885-Cisco-Catalyst-9800-Passpoint-configuration)
* [Cisco Meraki](https://cloud4wi.zendesk.com/hc/en-us/articles/4413079885069-Meraki-Passpoint-configuration)
* [Extreme CloudIQ](https://cloud4wi.zendesk.com/knowledge/articles/5945572850189/en-us?brand_id=2977846\&return_to=%2Fhc%2Fen-us%2Farticles%2F5945572850189)
* [Forinet Fortigate](https://cloud4wi.zendesk.com/hc/en-us/signin?return_to=https%3A%2F%2Fcloud4wi.zendesk.com%2Fhc%2Fen-us%2Farticles%2F6031652408077-Fortinet-FortiGate-Passpoint-Configuration)
* [more...](https://cloud4wi.zendesk.com/hc/en-us/articles/18939388439309-Passpoint-Network-Configuration)

To configure the network you need some parameters, including:

* RADIUS IP/Secret/Ports
* Passpoint Realm

You can find these parameters in the **Setup**, **Integration** page of your Cusna dashboard. On the WiFi Network card find **Show RADIUS data**.

<figure><img src="/files/H9Qv95ivKNThAZX7zGPj" alt=""><figcaption></figcaption></figure>

The dialog RADIUS Information provides all the data you need to configure your network.

<figure><img src="/files/wIIKe132m4fFDhu9T01V" alt="" width="282"><figcaption></figcaption></figure>

## Enabling Passpoint onboarding

Go to **Setup**, **Onboarding** and find the **Passpoint** card. Click the toggle to enable Passpoint onboarding.

<figure><img src="/files/w1lcaSRgH9tob9WOREWw" alt=""><figcaption></figcaption></figure>

## User experience

In the WiFi Portal, the Resident will see a Passpoint panel. By Clicking **Enroll**, the user is redirected to the Passpoint Download page, that guides the in the process of downloading and installing the Profile certificate ([learn more](https://cloud4wi.zendesk.com/hc/en-us/articles/4413031728781-WiFi-Profile-Download-Page))

<figure><img src="/files/RKizUN52mk0OfNN4w7Wr" alt=""><figcaption></figcaption></figure>


# SMS Services - via Twilio

In order to enable SMS-based services, such as phone verificaiton via SMS, you need to setup your own Twilio account.

On the Setup > Integration page, find the card **Twilio** and enable the toggle.

<figure><img src="/files/ZI13aHkqzvylcIWsRU38" alt=""><figcaption></figcaption></figure>

**Twilio Account SID**: this is your generic Twilio Account SID that you can find in the [main page of the Twilio Console](https://console.twilio.com/)

**Twilio Auth Token**: this is your generic Twilio Auth Token that you can find in the [main page of the Twilio Console](https://console.twilio.com/)

<figure><img src="/files/AlRhrR1nHiIKKR8Y4IsU" alt=""><figcaption></figcaption></figure>

You need to enable the [**Verify**](https://console.twilio.com/us1/develop/verify/overview) service.

Search for Verify in the sidebar, click Create New and follow instruction. Once completed, copy the value of the **Service SID** reported in the main table.

<figure><img src="/files/TSuTOpOp6MEla9RED68e" alt=""><figcaption></figcaption></figure>

Enter the **Service SID** in the Cusna setup interface and click **Save**.


# Getting Started

The Account Management API allows Cusna partners and customers or third-party systems to programmatically manage Accounts data in Cusna dashboard. Using the Account management API eliminates the need for property staff to manually enter data in the the dashboard.

## Base URL

All API requests must use the following base URL:

```
https://www.cusna.io/api/1.1
```

## Authentication&#x20;

To make API call you need an Access Token.

To get the Access Token make a request to the Auth endpoint

{% openapi src="/files/J5eWYUeTTTiyH03iLmdE" path="/auth" method="post" %}
[cusna-Cusna-1.0-resolved.yaml](https://3426155342-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDvdioCJduzKTpzAv3Sij%2Fuploads%2FqUOTRPUysUWc0FvLs1op%2Fcusna-Cusna-1.0-resolved.yaml?alt=media\&token=6b4b5bbf-0b44-47e3-9777-c4b2a1963cc3)
{% endopenapi %}

Authenticate API requests by adding in the header the parameter

```
Authorization: Barear <token>
```

## Organization ID

For some APIs, you need to provide your organization ID. YoOu can find the Organization ID in the Account page.

![](/files/MyEJk4agP8DNeZG8gjDb)


# Account management

You can List, Create, Edit and Delete Accounts using these endpoints.

## Model

A sample **Account** object is below

```json
{
    "organization":"1654740730258x343197985783152640",
    "building": "T2",
    "email": "cusnaresident2@gmail.com",
    "externalID": "1234456",
    "firstName": "Happy",
    "lastName": "Resident",
    "passphrase": "mypersonalpassphrase3",
    "phone": "4156234444",
    "stopDate": "2023-06-09T02:12:11.858Z",
    "tenantServiceStatus": "Active",
    "terminationMode": "Schedule stop date",
    "unit": "1112"
}
```

## Managing Accounts

List all Accounts

{% openapi src="/files/14CBoV09Nb7TlKGcf9Br" path="/obj/resident" method="get" %}
[cusna-Cusna-1.0-resolved (4).yaml](https://3426155342-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDvdioCJduzKTpzAv3Sij%2Fuploads%2FHnJFiIa0HwCErcoZ9UKh%2Fcusna-Cusna-1.0-resolved%20\(4\).yaml?alt=media\&token=089cbcce-b8f5-429c-bce1-2c4d3d9b8a5b)
{% endopenapi %}

Create and activate new Accounts. The activation email is sent automatically on the service activation date.

{% openapi src="/files/HNtyCDQP9PnfdPqEe4En" path="/obj/resident" method="post" %}
[cusna-Cusna-1.0-resolved (4).yaml](https://3426155342-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDvdioCJduzKTpzAv3Sij%2Fuploads%2FE3I6mzhAnY6oVas6X370%2Fcusna-Cusna-1.0-resolved%20\(4\).yaml?alt=media\&token=26baaa82-e328-4122-86c4-6cac3b9f067d)
{% endopenapi %}

Edit an Account

{% openapi src="/files/HNtyCDQP9PnfdPqEe4En" path="/obj/resident/{id}" method="patch" %}
[cusna-Cusna-1.0-resolved (4).yaml](https://3426155342-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDvdioCJduzKTpzAv3Sij%2Fuploads%2FE3I6mzhAnY6oVas6X370%2Fcusna-Cusna-1.0-resolved%20\(4\).yaml?alt=media\&token=26baaa82-e328-4122-86c4-6cac3b9f067d)
{% endopenapi %}

Delete an Account and terminate automatically its service

{% openapi src="/files/HNtyCDQP9PnfdPqEe4En" path="/obj/resident/{id}" method="delete" %}
[cusna-Cusna-1.0-resolved (4).yaml](https://3426155342-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDvdioCJduzKTpzAv3Sij%2Fuploads%2FE3I6mzhAnY6oVas6X370%2Fcusna-Cusna-1.0-resolved%20\(4\).yaml?alt=media\&token=26baaa82-e328-4122-86c4-6cac3b9f067d)
{% endopenapi %}

## Send activation email

Send again the activation email to an Account

{% openapi src="/files/IO47v5PpNzoZddocab6e" path="/sendactivationemail" method="post" %}
[cusna-Cusna-1.0-resolved.yaml](https://3426155342-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDvdioCJduzKTpzAv3Sij%2Fuploads%2F6KtQmGjzqEo8BJRXqLhR%2Fcusna-Cusna-1.0-resolved.yaml?alt=media\&token=732ed60a-7b6e-47cf-9312-5be283f38f6d)
{% endopenapi %}


# Coming soon...

Additional WiFi vendors has been tested and integrated. Their support is currently in Beta stage. If you are interested to use one of the following WiFi vendors please reach us to get them enabled:

* Ruckus SmartZone
* Fortinite FortiWiFi
* Huawei Cloud Campus
* Engenious Cloud
* Zyxel Nebula (Pro)
* Ubiquiti


# Engenius Cloud

{% hint style="warning" %}
You need an AP Pro license to use Cunsa with Engenius Cloud
{% endhint %}

{% hint style="info" %}
To enable Engenius Cloud on your account [contact support](mailto:support@cloud4wi.com).
{% endhint %}

## Engenius setup&#x20;

Login to your [Engenius Cloud](https://cloud.engenius.ai).

You need to create an SSID properly configured to support multiple PSK.

Go to **Configure** and select **SSID** and set a **Name** (eg. Residents WiFi).

On **Security Type**, select **WPA2-PSK** and then check the box **WPA2-MyPSK**.  Enter a long complex default passphrase (it wont be used).

Select **Cloud MyPSK Users** in the select menu.

![](/files/JRy3SU1qCjGSjC6zXR53)

Once you have the SSID properly configured, you can deploy it on your access points.<br>

{% hint style="warning" %}
Cusna implements an automatic VLAN management to segregate each resident traffic. Cusna uses the slot of VLANs 2000-4000 so you should avoid using these VLANs for any other purposes.
{% endhint %}

## Cusna setup

To connect Cusna to your Enginus Cloud account you need to get the Enginus API Key.

Click on your avatar icon and select **API Key**. Enter a name (e.g. Cusna) and click "**Generate new API key**.

![](/files/snoe8GdERrkrfA24tstr)

Copy your API Key.

Login in your [Cusna](https://cusna.io) account ad go to **Settings**. Select Enginus and enter the **API Key** in the input field. Click **Setup**.

## Operating Cusna

### Creating Networks

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the **Network** and the **SSID** that you have enabled on the Access Point of the related to property.

### Creating Accounts

When you create a new  Account, a new PPSK user will be created in your Engenius account with the personal WiFi Passphrase.

{% hint style="info" %}
The default, initial WiFi Passphrase is the resident phone number!
{% endhint %}


# Zyxel Nebula (Pro)

{% hint style="info" %}
To enable Zyxel Nebula on your account [contact support](mailto:support@cloud4wi.com).
{% endhint %}

## Nebula setup&#x20;

Login to your [Nebula portal](https://nebula.zyxel.com/)

First step, you need to create a Site and add your Device. In general, you would have a Site for each property.

Then, create an SSID (WiFi network) with DPPSK as an authentication method and fill in a very long complex backup key. \
Go to **Access point** –> **Configure** –> **SSID Overview** and set **WLAN security** = **DPPSK**\ <br>

![](/files/Jzdrxfcbiag1aHg6XJIe)

<br>

## Cusna setup

To connect Cusna to your Zyxel Nebula account you need to get the Nebula API Key.

Go to **Site-Wide**, **General Setting** and scroll down to the end of the page until you find the **API Access** section.

Click Generate and then copy the **API token**.

![](/files/LKXxU7JSFFk0YFRxna9q)

Login in your [Cusna](https://cusna.io) account ad go to **Settings**. Select *Zyxel* and enter the **API token** in the input field.

Click **Setup**.

## Operating Cusna

### Creating Networks

When you create or edit a Network in the Cusna dashboard, in the WiFi configuration section, you have to pick the **Site** and the **SSID** that you have enabled on the Access Point of the related to property.

### Creating Accounts

When you create a new Account, a new PPSK user will be created in your Nebula account with the personal WiFi Passphrase.

{% hint style="info" %}
The default, initial WiFi Passphrase is the resident phone number!
{% endhint %}


# Changelog

**12/10/2024**

* For Meraki networks, you can now inspect the name of the Group Policies initialized in the Meraki organization for each Network Policy ([more](/service-management/network-policies#troubleshooting-network-policies))

**12/02/2024**

* The organization name used by MSPs to create and manage organizations is now independent of the company name. Organization admins can change the company name at any time without affecting the organization name visible to the MSP.
* MSPs now have the option to prevent organization admins from customizing the email sender. However, MSPs can still manage the organization and configure this option on behalf of the admins.

**11/26/2024**

* Enables sending an email to tenants a configurable number of days before their service is scheduled for termination ([more](/service-management/general-options/service-options#service-termination-notice))
* Data retention configuration allows to automatically delete accounts and related PII after a certain number of days since their last service termination date ([more](/service-management/account-settings#account-management))

**11/25/2024**

* Admins can now define a custom set of characters for automatically generating WiFi passphrases. The default character set is optimized to exclude easily confusable characters ([more](/service-management/general-options/service-options#passphrase-options))

**11/25/2024**

* Resident can now select their unit in the registration form during first time onboarding ([more](/service-management/wifi-portal-and-onboarding/access-control-options#account-registration))
* Phone number validation via SMS OTP during onboarding. Requires [configuration of a Twilio Verify](/add-ons/sms-services-via-twilio) account. Contact support to request the activation of this feature. ([more](/service-management/wifi-portal-and-onboarding/access-control-options#account-registration))

**11/22/2024**

* Automatic Service Suspension option allows to define criteria to automatically suspend the Account's service ([more](/service-management/wifi-portal-and-onboarding/access-control-options#automatic-service-suspension))

**11/21/2024**

* Two Factor Authentication for Dashboard Admins can be enabled by each Admin in the Profile section  ([more](/service-management/my-profile#two-factor-authentication))
* Admins can now update their password directly form the Profile page without going trough the entire password reset flow ([more](/service-management/my-profile#password-update))
* A password security policy has been enforced (min 8 characters, 1 number, 1 capital letter, 1 non-alphanumeric character)

**11/20/2024**

* Organizations can now delete permanently their own account on the Account Settings page ([more](/service-management/account-settings#account-management))

**11/18/2024**

* In the Network list, a new status column indicates whether any anomalies are affecting each network in the table. By clicking the alert icon, the user is redirected to a list of anomalies specific to the corresponding network.

**11/15/2024**

* Customer support platform can now be integrated to provide end user a direct channel to support using the Organization systems. FreshWorks and Drift are the first system available. More to come! ([more](/service-management/support-platforms-integrations))

**11/13/2024**

* Locations are now called Networks, a name that better represents services provided across multiple physical locations within a broader geographical area&#x20;

**10/30/2024**

* \[Beta Program Only] Ethernet Ports management\
  A new feature now allows control over which Ethernet (ETH) ports on an Access Point assigned to a Unit are enabled or disabled. It’s also possible to assign different ports of the same Access Point to separate accounts, enabling, for example, a single Access Point in a dormitory unit to provide wired network access to two different students, each on their own private network (PAN).

**10/30/2024**

* MSP Admin Owners can now enable or disable specific features on each Organization, such as Email Sender customization and Units management
* Multiple bug fixes
  * Network Policy popup not correctly displaying existing policy values
  * Contact profile collection dropdown list appearing under other interface elements
  * Network Policy can be deleted only if not assigned to any account. However, if there were assigned as default Network Policy for existing locations, it would casue issues when provisioning new Accounts on those Locations.

**10/23/2024**

* MSP Admins Owner, can set the permissions of other MSP Admins, including the ability to create new Organizations and the ability to order new licenses

**10/22/2024**

* When using Fortinet Fortigate, Cusna now automatically creates and manages Interfaces and DHCP servers on each interface. All interfaces are grouped in a dedicated Zone per Location

**10/18/2024**

* Admins can now set the [length of the WiFi passphrases](/service-management/general-options/service-options#passphrase-length) automatically generated

**10/17/2024**

* The utility for publishing a [WiFi Portal on a Meraki SSID](/service-management/wifi-portal-and-onboarding/wifi-portal-distribution) now prevents the selection of SSIDs that are already in use for iPSK services
* New Locations can no longer be associated with Meraki networks that are already linked to other Locations within the same Organization&#x20;

**10/16/2024**

* MSP Admin Owner can now change the settings and preferences of their own MSP account ([docs](/msp-operations/msp-account-settings))

**10/15/2024**

* MSP can now set the list of supported WiFi vendors available on their managed Organizations&#x20;
* Bug Fix: when deleting Location, only the first Group Policy of the associated network was deleted on Meraki

**10/04/2024**

* WiFi Passphrase are now by default a combination of letters, upper and lowercase, and numbers

**10/03/2024**

* Added a [Network Health](/service-management/service-monitoring-and-assurance/network-health) widget in dashboard and Network Health page for Meraki deployments

**09/18/2024**

* The General options page under the Setup menu group has been exploded in two independent pages, [Onboarding](/service-management/wifi-portal-and-onboarding#wifi-portal-options) and [General](/service-management/general-options) to simplify usability

**09/17/2024**

* Support of multiple [Fortinet](/wifi-integration/summary-of-supported-wifi-vendors/fortinet-fortigate-secure-wireless-controller) controllers in the same Cusna account

**09/16/2024**

* MSPs can set a custom Help Center link for Organizations under their management
* License and Support menu are now hidden for Organizations under MSP management
* Added new option to [Reset Account](/service-management/account-settings), available to Organization Admins with Owner role and MSP Managers

**09/13/2024**

* The Organization Dashboard now offer a dedicated page to visualize all open issues&#x20;
* Fortigate Wi-Fi Controller is now officially supported ([docs](/wifi-integration/summary-of-supported-wifi-vendors/fortinet-fortigate-secure-wireless-controller))

**09/12/2024**

* [MSP can set a MAX MAU Threshold](/msp-operations/msp-dashboard) on any managed Organization
* MSP Admin with Owner role will receive an alert via email when any Organization hits the 90% of the MAX MAU Threshold. The same notificaiton appears in the Alerts page

**09/10/2024**

* Organization Admins and MSP Admins can opt-in to receive Alerts notifications via email (docs)

**09/5/2024**

* MSP dashboard now includes a dedicated Alerts page that visualizes all issues related to the managed Organizations. Issue can be filtered by Organization and Type and marked as resolved ([docs](/msp-operations/msp-dashboard))

**09/3/2024**

* Multiple Admins are not supported at the MSP level. MSP Admins with Owner role can create and mange other Admins users who can access the MSP dashboard ([docs](/msp-operations/msp-dashboard))

**09/2/2024**

* New License section has been added to the MSP dashboard, accessible by MSP Administrators with Owner role. The sections offers full visibility on the MAU consumptions per Organization and per each of the past 12 months ([docs](/msp-operations/msp-dashboard))
* MSP Admins with Owner role can "add" MAU Subscription at any time to reduce their MAU Overages for the current month and forward  ([docs](/msp-operations/msp-dashboard))

**08/30/2024**

* MSP Admins with Owner role can now create new Organizations autonomously, up to the max number of Organization set on the MSP  ([docs](/msp-operations/msp-dashboard))


# Datasheet

### For Organizations

<table data-view="cards" data-full-width="true"><thead><tr><th>Function</th><th>Description</th><th>Features</th></tr></thead><tbody><tr><td><strong>Multi-vendor Cloud PPSK</strong></td><td>Supports cloud PPSK lifecycle management across multiple WiFi vendors</td><td><ul><li><a href="/pages/WJ9hDwmYxz4WkpGQjK5T">Cisco Meraki</a></li><li><a href="/pages/zL3T08nG62UVSStym90B">Extreme Networks</a></li><li><a href="/pages/Es6JHjb6B29HRgR33Y4Q">Cambium cnMAestro </a></li><li><a href="/pages/uW8ZTSgCaf2T5GAg7eQU">TP-Link Omada</a> (cloud or on prem)</li><li><a href="/pages/4q7g0uLYt9oD40oOD2OB">Huawei iMasterNCE Campus</a></li><li><a href="/pages/IrysTvkxfsVNoZOcmbbd">Junioper Mist</a></li><li><a href="/pages/lz4NSK4Ds6YRAggYARBm">Ruckus SmartZone</a></li><li><a href="/pages/zLVRrfxmdN4s9lWDAowI">Fortinet Fortigate</a> </li></ul></td></tr><tr><td><strong>Delegation to local managers</strong> </td><td>Each Network can be assigned with a dedicated Admin with permission to manage Accounts</td><td><ul><li>Network Admins can manage one or multiple <a href="/pages/2x3aN1JlYBBNp2vyIPk9">Networks</a></li><li>Network can be geographically distribute and independent buildings or different area od the same Campus</li></ul></td></tr><tr><td><strong>Multi Admins and Roles</strong></td><td>Each Org can have multiple Admins with multiple roles</td><td><ul><li>Org Admin with Owner role can create other <a href="/pages/PLfUmOml1mtWCG23Wstf">Admins</a></li><li>Org Admin with Owner role can transfer Ownership to another Admin</li></ul></td></tr><tr><td><strong>End-user identity management integrations</strong></td><td>Integrations with multiple system of records where to verify identities of end-users to enable self-onboarding</td><td><ul><li><a href="/pages/hqHFVULPk0c8Lil6dPow">Google (oAuth)</a></li><li><a href="/pages/Eev5DottuINGuGjOr9gw">MS Entra (oAuth)</a></li><li>SAML (Google, <a href="/pages/zBnnERDDiD8vBZT9CmJA">MS Entra</a>, Okta, Auth0)</li><li>Shibboleth</li><li>Coworking management system integrations Optix, Office RnD, Nexudus, Adncards</li><li>Entrata (coming soon)</li><li><a href="/pages/2zUFCEJDOMkjoejK0qqX">Custom HTTP RESt APIs</a> to easily integrate and external system of records (even an google sheet or a custom DB)</li></ul></td></tr><tr><td><a href="/pages/Xwf29ezjdhAgu9OvXO59"><strong>Network Policies</strong> </a><strong>orchestration</strong></td><td>Allows to define and orchestrate Network Policies on the network for supported vendors</td><td><ul><li>Initialize and mange Group Policies on Meraki and keep them in sync across all Networks deployed in he project</li></ul></td></tr><tr><td><a href="/pages/DdiC5zt3cY5BXwt4ERaJ#dynamic-pan-orchestration"><strong>Dynamic PAN orchestration</strong></a></td><td>Allows to automatically manage Personal area networks for Accounts</td><td><ul><li>Automatic PAN orchestration via VLANs or L3 segments (such as Meraki WPN or Extreme PCGs)</li><li><p>Automatic orchestration provide multipel options:</p><ul><li>assign unique PAN to each Account</li><li>assign PAN based on assigned Unit</li><li>assign PAN based on Account Group</li></ul></li><li>Option to free-up VLANs upon service termination for re-use by other Accounts</li></ul></td></tr><tr><td><a href="/pages/NKpcgroJOp5LwYVYcCI1"><strong>WiFi Portal</strong></a></td><td>Self-service portal for users to manage their service</td><td><ul><li>Admins can define the content, logo, color, theme of the Portal and granularly enable/disable each capability</li><li>See personal passphrase and network PPSK name</li><li>Scan QR code for quick connection to the WiFi network</li><li><a href="/pages/ozAWplwD0rcPtg9u4CJ4#allow-users-to-re-generate-their-wifi-passphrase">Re-generate the passphrase</a> (if enabled by Admins in the dashboard)</li><li>See and edit personal profile and service details</li><li>Delete their own account (compliance)</li><li>Enable/disable dedicated passphrase for Guests (if enabled by Admins in the dashboard)</li><li>Enroll personal devices into Passpoint (if enabled by Admins in the dashboard)</li><li>Manually manage legacy devices by adding, removing editing individual MAC addresses</li><li>Audit the list of devices used to connect</li></ul></td></tr><tr><td><a href="/pages/ozAWplwD0rcPtg9u4CJ4#allow-users-to-create-a-wifi-passphrase-for-guests"><strong>Guest access</strong></a></td><td>Tenants can create a dedicated, temporary passphrase for guests</td><td><ul><li>Can be enabled/disabled by Admins</li><li>Tenants can generate in one click a dedicated passphrase for guests that gets disabled automatically at the end of the day</li></ul></td></tr><tr><td><a href="/pages/DdiC5zt3cY5BXwt4ERaJ#passphrase-options"><strong>Passphrase option</strong></a></td><td>Manual definition of passphrase policies</td><td><ul><li>Length of the passphrase</li><li>list o characters used to generate the passphrase</li><li>By default, Cusna avoids characters that can be easily confused</li></ul></td></tr><tr><td><strong>Onboarding Portals</strong></td><td>Customizable web portals for end-users self-onboarding</td><td><ul><li>Unique <a href="/pages/p5Ldr7DdICH6Up1Wl9h4">short URL</a> and QR code for each Network</li><li><a href="/pages/ozAWplwD0rcPtg9u4CJ4#universal-wifi-portal-url">Universal URL </a>where users can pick their network</li><li>Taxonomy, content, logo and theme customization at <a href="/pages/ozAWplwD0rcPtg9u4CJ4#wifi-portal-taxonomy-and-contents">global scope </a>and for each network</li><li>Advanced <a href="/pages/ozAWplwD0rcPtg9u4CJ4#wifi-portal-custom-advanced-styling">custom CSS </a>style override</li><li>Simplified <a href="/pages/p5Ldr7DdICH6Up1Wl9h4#configuring-the-captive-portal">publishing of portals on SSIDs</a> as captive portals for some vendors such as Meraki</li></ul></td></tr><tr><td><a href="/pages/LDwDNGN3CcCYDPDZ7tGT#passwordless-login"><strong>Passwordless Identification and Onboarding</strong></a> <strong>option</strong></td><td>Allows tenants to get onboarding and access their service portal without passwords</td><td><ul><li>Existing Accounts can simply enter with their email address and click a magic link sent to their email to access the portal</li><li>Both in case of IdP integration and or email whitelist definition, also new users can follow the same process with magic link and they are prompted to a registration form on their first access</li><li>Possibility to define a <a href="/pages/LDwDNGN3CcCYDPDZ7tGT#email-domain-whitelist">list of domains</a> to allow users to self-onboard if they have an email address with such domains (require email verification with magic link)</li></ul></td></tr><tr><td><strong>Self-registration process</strong></td><td>Tenants are prompted to a registration step on their first access</td><td><ul><li>Compliance acceptance on first access</li><li>Customizable list of <a href="/pages/LDwDNGN3CcCYDPDZ7tGT#account-registration">profile attributes</a> (first, last name, email, phone, etc..) to be collected</li><li>Option to enable phone verification via <a href="/pages/LDwDNGN3CcCYDPDZ7tGT#account-registration">OTP sent via SMS</a> (require setup of Twilio Verify integration)</li><li>Option to let tenants select their Unit (only free Units listed)</li><li>Forced paid plan enrollment during first access if enabled by Admins</li></ul></td></tr><tr><td><a href="/pages/LDwDNGN3CcCYDPDZ7tGT#passpoint"><strong>Passpoint</strong></a> </td><td>Option to let tenants onboard their devices with Passpoint</td><td><ul><li>Admins can decide to enable Passpoint onboarding or not (requires a dedicated SSID)</li><li>Devices connecting via Passpoint will be assigned to the Account PAN in the future but right now are on a generic guest network</li></ul></td></tr><tr><td><a href="/pages/4Kwr9R8k9r8I6DQPeP9h"><strong>Accounts management</strong></a></td><td>Ability to visualize and manage individual accounts</td><td><ul><li>Account summary view with search, filtering and status insights and bulk export in Excel</li><li>Account profile page, with possibility to edit passphrase, VLAN, Unit and personal data</li><li>Print WiFi service card with PPSK and QR code</li><li>Account activity history logs</li><li>Account service suspension</li><li>Accounts delete</li><li>Bulk import of accounts from XLS</li></ul></td></tr><tr><td>Ac<strong>counts service lifecycle management</strong></td><td>Service activation and termination can be manage manually or automatic</td><td><ul><li>Schedule activation in a future date</li><li>Schedule automatic termination on a future date</li><li>Activation and termination date can be inherited form eterna IdP/PMS in case of self-onboarding</li><li>Option to force an <a href="/pages/DdiC5zt3cY5BXwt4ERaJ#service-termination-notice">automatic expiration</a> after a configurable number of days</li><li>Option to notify accounts in advance, a configurable number of days before the scheduled service termination </li><li>Account welcome and confirmed activation emails, branded with colors and logo of the Organization</li></ul></td></tr><tr><td><strong>Multiple Accounts types</strong></td><td>Ability to differentiate between Tenants (people), and Things</td><td><ul><li>Tenants: represent individuals, passphrase is automatically generated and Accounts have personal metadata (emails, name, etc..)</li><li><p>Spaces: dedicated for common spaces such as meeting rooms. Passphrase do not expire and can be set manually. </p><ul><li>Auto-rotation: option to automatically rotate Space passphrase daily</li></ul></li><li>IoT Groups: dedicated to devices, usually fixed device sin the venues, that need to be connected with individual or group-based passphrase that can be automatically generated or specified manually</li><li>Visitors: temporary accounts that gets automatically disabled at the end of the day</li></ul></td></tr><tr><td><a href="/pages/X4KedxUxtCdXfdsc3jA7"><strong>Visitors Access</strong></a></td><td>Allows Visitors to get onboarded with a temporary account</td><td><ul><li>Allow visitors to register on the Onboarding portal filling a form</li><li>By default Visitors are terminated at the end of the same day</li><li>Visitors can optionall request a service extention until a certain date, by specifying a reason and desired date</li><li>Admins are notified via email and can approve or reject the extentions requests in the dashboard</li></ul></td></tr><tr><td><a href="/pages/N5zF8Yhz4WHDQ1pweKK1"><strong>Groups</strong></a></td><td>Ability to organize Accounts in Groups for simplified provisioning of shared configurations and policies</td><td><ul><li>Network-specific or Org-level Groups</li><li>Default Group VLAN shared across all Accounts (optional)</li><li>Option to make Group members shared the same passphrase</li><li>Group-level Network Policy assigned to all Group members</li><li>Group-level service activation date to enable all group member in bulk in the future</li><li>Group-level termination date to terminate the service of all group members in the future</li><li><a href="/pages/WxPvn9u9LRO98hWoiMg2">Group-mapping</a> option allows to map Groups inherited by the third party connected IdP (e.g. Ms Entra) with Cusna Group</li><li>Option to block access only to the users mapped in one of the defined groups</li></ul></td></tr><tr><td><a href="/pages/y1n7wDDQiX9JxZy76QDh"><strong>Units</strong></a></td><td>Ability to manage the inventory of units/room in a building and assign network devices</td><td><ul><li>Manual or automatic pre-assignment of Unit-level VLANs to simplify configuration of switches</li><li>Assign Access Points to a unit to automatically configure cable ports to be in the same PAN ans the wireless devices (for supported vendors)</li><li>Granular assignment of individual Access Point ports to different Accounts in the same Unit (for supported vendors)</li><li>Unit-specific onboarding portal URL that allows deploying QR codes in Unit for simplified onboarding</li><li>Unit selection can be enabled in the user registration form during initial onboarding</li></ul></td></tr><tr><td><strong>Observability and accountability</strong></td><td>Ability to track the clients used by each account over time</td><td><ul><li>Tracking of all clients used by each Account to connect to the WiFi network (supported vendors only)</li><li>Ability to manually block/allow specific Clients (supported vendors only)</li><li>List is visible to both Admins in the dashboard and Tenants in the WiFi Portal</li></ul></td></tr><tr><td><a href="/pages/U6yd3E4oFuHgHkpDU5Y7"><strong>Legacy devices support</strong></a></td><td>Onboarding and authentication of legacy devices via MAB</td><td><ul><li>Tenants can manually add/remove and mange personal legacy devices in the WIFI portal by specifying their MAC address</li><li>Devices are authorized via MAC authentication and force in the same PAN as the client connected via PSK</li><li>Can be use for both wired and wireless clients (required a dedicated SSID with MAB configured)</li></ul></td></tr><tr><td><a href="/pages/c3Tpb4glpkdBKaosby0w"><strong>Support platforms integration</strong></a></td><td>Ability to integrate the existing company support system in the WiFi Portal</td><td><ul><li>WiFi Portal can show a widget or links to the existing support channels</li><li>Drift, FreshWorks (and anything on demand)</li></ul></td></tr><tr><td><a href="/pages/Ny5hWRJ2jGtW7JNuGEaC"><strong>Native service billing</strong></a></td><td>Allows to collect service fees directly form tenants</td><td><ul><li>Simplify company billing system setup via Stripe Connect</li><li>Ability to create multiple service Plans with different network policies (bandwidth)</li><li>Manual assignment of Plans to Accounts to force Accounts to select among available plans during onboarding</li><li>Tenants can change plan, change payment details, consult payment history and see upcoming bills in their WiFi portal</li><li>Admins can see billing details for each Account in the dashboard</li></ul></td></tr><tr><td><strong>Compliance</strong></td><td>Set of capability for security and compliance</td><td><ul><li>Orgs must configure their own Privacy Policy and (optionally) terms of service that are presented to end user during onboarding</li><li>Customizable <a href="/pages/JWc02oRS6ohWUUdCgqrY#account-management">Retention</a> policy allows to automatically delete PII based on customizable timing</li><li>Admin can <a href="/pages/Ig6eEtXneR1DMb3eI4yi#two-factor-authentication">enable 2-factor authentication</a> to access the dashboard</li><li>Complex password policies are enforced by default</li></ul></td></tr><tr><td>M<strong>onitoring and assurance</strong></td><td>Set of capability to help monitor and troubleshoot the service</td><td><ul><li>Admins can subscribe to receive <a href="/pages/B8prtIPmDze4VMoH6GSn">email notifications</a> about all anomaly events</li><li>Anomaly dashboard shows all issue and anomalies</li><li>Network status widget (for supported vendors) reports the status of the APs used int eh deployed networks and provide a list of all APs with related status and notes</li></ul></td></tr><tr><td><strong>Account administration</strong></td><td>Enterprise grade account management</td><td><ul><li>Custom email sender for all service-related email communication</li><li>Activity logs allows to audit the history of all operations occurred, from Account service lifecycle to setting changes</li><li>Simplified Password changes in the dashboard for admins</li><li>Option to force password reset option for Admins</li><li>Ability to reset the workspaces to start fresh with new vendor integration</li><li>Ability do terminate and delete account</li><li><p>Intuitive dashboard with summary fo the service status, report of main KPIs</p><ul><li>Widget reporting daily active clients connected on the deployed networks</li><li>Monitoring of current Monthly Active Accounts (MAA)</li></ul></li></ul></td></tr><tr><td><strong>APIs</strong></td><td>Offer the ability to integrate with external provisioning systems</td><td><ul><li>Accounts management APIs (create, edit, delete, activate, suspend)</li></ul></td></tr></tbody></table>

### For Managed Service Providers

<table data-view="cards" data-full-width="true"><thead><tr><th>Function</th><th>Description</th><th>Features</th></tr></thead><tbody><tr><td><a href="/pages/ARIhq2TYcquLFivHLXiQ#managing-organizations"><strong>Managing Organizations</strong></a></td><td>MSPs have a dedicated dashboard where they can provision and manage their customers</td><td><ul><li><a href="/pages/ARIhq2TYcquLFivHLXiQ#creating-new-organizations">Create new Organization</a></li><li>List of managed Organizations with summary of most important information</li><li>Click to login in each Organization account with MSP-level permissions</li><li>Granular control on enabled features and capabilities on each Organization</li><li>Ability to permanently delete Organizations</li></ul></td></tr><tr><td><a href="/pages/ARIhq2TYcquLFivHLXiQ#license-management">L<strong>icensing</strong></a></td><td>MSPs pay for what they consume across all Organizations based on Monthly Active Accounts</td><td><ul><li>Ability to set the Maximum MAA on each Organization to control costs</li><li><p>License dashboard with license control</p><ul><li>Current month MAA and Overages</li><li>Current and history of MAA Subscription</li><li>Report of MAA per each managed Organization per each Month of the last 12 months</li></ul></li><li>Ability to order MAA Allowance subscriptions to reduce Overage MAAs and save on costs</li></ul></td></tr><tr><td><strong>Service assurance</strong></td><td>MSP can easily monitor issues and anomalies occurring across all their managed organizations</td><td><ul><li><a href="/pages/ARIhq2TYcquLFivHLXiQ#alerts">Dashboard</a> with the list of active anomalies across all Organizations, with multiple filters</li><li>Option to receive <a href="/pages/Ig6eEtXneR1DMb3eI4yi#notificaiotns">Anomalies notifications</a> in real time via email for all Admins</li></ul></td></tr><tr><td><a href="/pages/ARIhq2TYcquLFivHLXiQ#managing-msp-administrators"><strong>Account Administrations</strong></a></td><td>MSPs can have multiple Admins with different roles</td><td><ul><li><p>MSP Admin with Owner role can:</p><ul><li>create and edit other Admins</li><li>assign generic permissions or add the permissions to buy MAA Subscriptions and to activate new Organizations</li><li>transfer ownership to another Admin</li></ul></li></ul></td></tr><tr><td><a href="/pages/xEMBZQiutvjvlIhF5tjA"><strong>MSP settings and control</strong></a></td><td>MSPs can configure generic options that are imposed on all managed organizations</td><td><ul><li>Ability to filter the list of WiFi vendors that are available to managed organizations</li><li>Custom support URL that overrides the default one in all Organization's dashboard</li><li>Default privacy policy and terms of use that are configured as default one for all managed orgs</li><li>Logo and access colors that are initialized as default ones for all new Organizations</li></ul></td></tr></tbody></table>


# Student living

## Overview

Campuses and universities are complex environments with a wide range of use cases to address. Cusna, with its PPSK-based connectivity approach, is the ideal solution for providing universal access to managed networks in both on-campus and off-campus living environments. Moreover, once a PPSK is assigned to students, it can also be used on networks beyond the residences and across the campus.

## Network setup

The setup of the infrastructure depends significantly on the vendor chosen for the project and the number of end users it needs to support.

When using network-based PPSK technology (where PPSKs are deployed and managed within network elements), there are often limitations on the number of PPSKs that can be assigned per network segment (learn more).

For example, if the technology limits the number of PPSKs to 5,000 per network, and the campus serves more than 5,000 students, it may be necessary to segment the deployment into multiple networks, such as one network per dormitory or site. In this setup, each PPSK would function only within the network it was assigned to.

To allow students to connect to networks outside their assigned dormitory, they can be encouraged to download a Passpoint profile from their WiFi portal onto their portable devices.

## Onboarding

Students can self-onboard through the WiFi Portal, which serves both as the initial onboarding platform and a hub for managing their service preferences.

The WiFi Portal URL can be shared in several ways, such as:

* Including it in welcome emails and onboarding communications.
* Publishing it in a documentation article on the university’s website or WiFi information page.
* Incorporating it into onboarding materials distributed to students.

Once students access the portal, they can log in using their school credentials. Typically, external IdPs such as [Microsoft Entra](/cloud-identity-platforms-integrations/enterprise-cloud-idps/microsoft-entra-id-saml), [Google](/cloud-identity-platforms-integrations/enterprise-cloud-idps/google-workspace-oauth), or Shibboleth are used for authentication. Administrators must configure the IdP integration in the Cusna dashboard, including setting options such as group mapping and filtering in the onboarding settings.

A common configuration in this scenario is enabling authentication via [IdP SSO](/service-management/wifi-portal-and-onboarding#sso-authentication) (using school credentials). The button label presented to students can be customized, for example, “Access with your school credentials.”

A passwordless login option allows students who have already onboarded to log in using just their email address. However, adding this option may create unnecessary complexity and confusion for students. Therefore, it is recommended to disable this feature in such cases ([learn more](/service-management/wifi-portal-and-onboarding#passwrodless-login)).

<details>

<summary>Onboarding flow with Google as IdP</summary>

![](/files/lkhDcSmc2ePpnxkpeqPa)

</details>

<details>

<summary>Onboarding flow with Microsoft Entra</summary>

<img src="/files/x5dJ1MXM9mip91D3sKdT" alt="" data-size="original">

</details>

## Service lifecycle management

Once students are activated, they can access the network with all their devices.

If they encounter issues connecting a device using PPSK, the [MAC bypass](/service-management/wifi-portal-and-onboarding/iot-devices-authentication) option can be enabled. This allows students to enter their device’s MAC address for authorization via RADIUS. Administrators can assist students by adding and managing these devices through the Dashboard on the Account profile page.

Most IdPs, particularly those relying on the SAML protocol (e.g., Shibboleth), do not provide information about when a user’s access should be terminated. In such cases, planning a de-onboarding strategy is essential.

A simple and effective approach is to enable an [automatic suspension](/service-management/general-options/service-options#automatic-service-termination) of service after a set number of days (e.g., every 90 days). Students are [notified via email](/service-management/general-options/service-options#service-termination-notice) in advance and can easily renew their account by visiting the portal and logging in with SSO.

Another strategy is to assign a generic expiration date to the group the students belong to. In this setup, all users in the group will have their accounts terminated on the configured date.

### Setup demo

{% @arcade/embed flowId="5GOIvsYiv1ofLuEy4Fny" url="<https://app.arcade.software/share/5GOIvsYiv1ofLuEy4Fny>" %}


# Sample FAQ: WiFi for the Resident Hall

MSPX is the new network services contractor at UniversitY. They have partnered with UniversitY to provide wired and wireless network/internet access to students in the residence halls. This change offers several benefits over the previous network.

Go to [**WiFi Portal**](https://www.cusna.io/onboarding/1739255303699x292547217391616000) to get started!

***

{% hint style="info" %}
**Personal Area Network (PAN)**

* Your Personal Area Network is a private network for your devices. This is a secure network where your devices will be able to interact with all your devices added to your account. Up to X simultaneously active devices.
* This will enable you to enjoy the benefits and functionality you would have in a home or small office network.
* You will be able to access your printer and print from your devices, pair any smart devices to devices added to your account and take advantage of the functionality of all the internet of things (IoT).
* When you register a device and connect to the network with your WiFi Password (PSK), your devices are automatically grouped together.
* After all of your devices are connected to WiFi, connect them the same way you would at home – they can "see" each other on the network.
  {% endhint %}

## Get Connected

### **If this is your first time on-site, from this device:**

1. Click the "*Log in with your School account*" button and enter your school-provided credentials to create a new account.
2. Accept the T\&C and fill any additional data that might be asked in the portal
3. The next page will show you your WiFi Password or Pre-Shared Key (PSK) - copy this.
4. Sign out of the portal.
5. Go to the Wireless settings on your device and connect to the “*MyResNet*” SSID.
6. Join the SSID with your WiFi password and click to auto-join this SSID.
7. To add more devices to the network, simply go to the wireless settings on each device and repeat steps 4 and 5 above.
8. If you connected originally via the “Start Here” network, go to your device WiFi settings and choose to Forget that network.

### **Set up your account while not on-site**

1. Click the "*Log in with your School account*" button above and enter your school-provided credentials to create your account.
2. Accept the T\&C and fill any additional data that might be asked in the portal
3. The next page will show you your WiFi Password or Pre-Shared Key (PSK) - copy and remember this.
4. Sign out of the portal.
5. When you arrive on campus:
   * Go to the Wireless settings on your device and select the “*MyResNet*” SSID.&#x20;
   * Join the SSID with your WiFi password and click to auto-join this SSID.
   * To add more devices to the network, simply go to the wireless settings on each device and repeat the previous two steps to connect.
   * You can return to the portal at any time to add/change/manage your account and devices.

### **Connect Gaming Consoles and other devices:**

1. Find your Wi-Fi Password or Pre-Shared Key (PSK) - yo can log into your account to find it.
2. Go to your device's Wi-Fi Settings and select the "*MyResNet*" network. Enter your Wi-Fi Password/PSK to connect.
3. If your school has ports for wired connections, you must log in in your account, click “Add Device” and enter the MAC address of the wired device in order to register it.
4. This section applies to Xbox and PlayStation products, as well as other families of gaming devices.

## FAQ

### My Account

**Question:** How do I retrieve my username and password?\
**Answer:** If you are a current student, your login credentials have been provided by the school. You will need to go to the appropriate school-owned portal to request your username and password.

**Question:** Can I have change my WiFi Password?\
**Answer:** you can log in to your account and click "re-generate" to create a new WiFi Passowrd. You cannot select manually your own WiFi password. If you change password, all devices that you have connected with the previous WIFi password must be re-configured with the new one.

### Personal Area Network

**Question:** What is a Personal Area Network (PAN)?\
**Answer:** Your Personal Area Network is a private network for your devices. This is a secure network where your wireless devices can interact with each other once added to your account. This will enable you to enjoy the benefits and functionality you would have in a home or small office network. You will be able to access your printer and print from your devices, pair any smart devices to devices added to your account and take advantage of the functionality of all the internet of things (IoT).

**Question:** How do I use the Personal Area Network?\
**Answer:** When you register a wireless device and connect to the network with your Wi-Fi Password (PSK), your devices are automatically grouped together. After all of your devices are connected to Wi-Fi, connect them the same way you would at home – they can "see" each other on the network.

### Getting connected

**Question:** What network to use\
**Answer:**

1. If you are a resident, do not use the Guest Network (where one is available). Guest networks have lower bandwidth than Resident networks.
2. If your device can connect to it, use the *MyResNet* network, as it is the highest-speed network.

**Question:** Can I have a router?\
**Answer:** Routers are not permitted on the network due to wireless interference negatively impacting other users' internet connectivity and quality of service. This includes MiFi-type routers that use cellular data, as the router will still broadcast on a wireless channel that will interfere with the larger Wi-Fi network. Users do not need routers, as their devices will be on the users' individual Personal Area Network, allowing their wireless devices to communicate securely within the wireless network. If you currently utilize a router, you will be required to disconnect the equipment in order to remove the interference impacting other users on the network.

**Question:** Can I cast from device to device?\
**Answer:** Casting from one device to another device is supported. Devices you wish to be able to cast to must be added to your account.

**Question:** Can I use smart home devices?\
**Answer:** Yes, you will be able to add your smart home devices to your account and set them up within your Personal Area Network (PAN).

### MAC Address

**Question:** What is a MAC Address?\
**Answer:** A MAC address is a hardware identification number that is unique to each device that can connect to a network. A device that can connect with a wired Ethernet connection has a wired or an ethernet MAC address. If the device can connect to a Wi-Fi network, it will have a wireless MAC address. A device that can connect with an Ethernet (wired) or wireless (Wi-Fi) connection will have both. MAC address is also known as physical addresses or hardware address. When adding a device, you will typically use the Wireless MAC Address.

**Question:** How do I find my MAC Address?\
**Answer:** In your Account, you'll find a link with the step by step instructions for each type of personal and headless device

### iOS18 Apple Devices

**Question:** I have iOS18 and see a feature to Rotate my Wi-Fi Address. Should I turn that on?\
**Answer:** No, this new iOS18 security feature is not needed once you have connected to a secure network, and your Apple device will turn it off by default. Please leave it off for the best connection experience. The Wi-Fi network will recognize your device based on your Wi-Fi Password used when connecting to the secure network.

**Question:** What happens if I turn on the Rotate Wi-Fi Address feature?\
**Answer:** If Rotation is turned on, the network will begin registering every Wi-Fi address that you rotate through and will eventually hit a limit (currently set to 50). Once that limit is reached, you will need to log into your account and delete the older unused Wi-Fi addresses in order to connect to Wi-Fi again.


# Hospitality

**Meeting Modern Connectivity Demands:** Hotel guests now arrive with an array of personal devices – from smartphones and laptops to streaming sticks and smart gadgets – expecting instant, reliable Wi-Fi across all of them. Studies show 98% of guests carry smartphones, 70% bring laptops, and many travel with **at least two devices** ready to connect​. Usage is heavy: **80%** use hotel Wi-Fi for remote work tasks (e.g. video calls), **66%** for streaming Netflix/YouTube, and **72%** want to cast content from their device to the in-room TV​. As a result, Wi-Fi has evolved from a nice-to-have amenity to a mission-critical service. In fact, **65% of guests get online within 7 minutes** of check-in (one-third ask for the Wi-Fi password immediately), underscoring that connectivity is **no longer optional but an absolute necessity impacting satisfaction.** Conversely, a poor Wi-Fi experience can severely damage guest loyalty – *most guests will refuse to rebook with a hotel after a bad Wi-Fi experience*​. Frequent complaints include slow speeds and dropped connections (cited by 42% of guests), cumbersome login processes (29% had issues logging in), and dead zones on the property. Guests today expect a smooth, “at-home” connectivity experience in hotels, and falling short carries real costs in guest sentiment and repeat business​.

### MAC Randomization and Onboarding Friction

One emerging hurdle is **MAC address randomization**, a privacy feature now enabled by default on modern iOS and Android devices. This randomizes a device’s MAC address periodically or per network to prevent tracking. For hotels that traditionally authenticate devices by MAC (e.g. remembering a device for auto-connect or linking to room/loyalty info), this has become a support nightmare. A guest’s phone or laptop may appear as a “new” device each day even on the same network. *At best, the guest is forced to re-authenticate repeatedly during a stay; at worst, they get kicked off entirely when the system doesn’t recognize the device*​.

Apple led the charge by making MAC randomization the default in iOS, and now **all major OS vendors have followed suit**​. The result: **major friction for guests and IT**. Guests grow frustrated having to re-enter portal credentials or call support daily just to keep a device online. IT teams, in turn, face rising help-desk tickets to “fix the Wi-Fi” which in reality stem from privacy changes on devices. Traditional guest Wi-Fi platforms that rely on MAC addresses for recognition or billing (like remembering a device’s 24-hour access purchase) are increasingly unreliable in this new landscape​. This drives home the need for more robust onboarding methods that don’t depend solely on static device identifiers.

### Headless Devices: The Self-Onboarding Dilemma

Another critical challenge is **onboarding headless devices** – gadgets without a web browser or screen to navigate captive portals. Guests now travel with an expanding menagerie of such devices: smart speakers (e.g. voice assistants), streaming dongles (Chromecast, Fire Stick), gaming consoles, e-readers, health and medical IoT devices, even Wi-Fi enabled cameras and smart toys. These devices typically cannot perform the browser-based login that hotel captive portals demand. The result is often *frustration and failure*: *“Hotel Wi-Fi is often incompatible with them, which results in an incredibly frustrating experience for all involved,”* as one hospitality Wi-Fi engineer put it​.

Most of these devices simply **lack the ability to get through a captive portal** – they can see the open SSID but cannot display the splash page to accept terms or enter room details​. In the **best case**, guests must phone the hotel’s IT support, read out the device’s MAC address (if they can even find it), and have IT manually whitelist that MAC on the network – a time-consuming workaround for both guest and staff​. In the worst case, the device remains offline for the stay because the guest cannot complete registration and the hotel has no alternative onboarding path​. For example, a family on vacation might bring a new gaming console for the kids, only to discover it **will never connect** because figuring out how to bypass the portal or locate its MAC address is too difficult. This **headless device hurdle** is increasingly common. Many IoT and entertainment devices “**lack browsers, making traditional onboarding tools ineffective**”​. Hoteliers are grappling with how to let guests **self-onboard such devices securely, without involving IT for each gadget**. Without a solution, hotels risk telling guests they simply cannot use their smart speaker or console – a poor experience in an era when guests want to use their personal gadgets freely.

### Security Gaps of Open Networks and Shared Passwords

Traditional guest Wi-Fi networks often sacrifice security for ease of use. The common approaches – **open networks with captive portals, or a shared WPA2 passphrase for all guests** – come with significant security risks. Open, unencrypted Wi-Fi means that **data sent over the network can be captured out of the air** by anyone with simple tools. If no encryption is in place, anything a guest transmits in cleartext (unencrypted web pages, app data) is **openly broadcast** to eavesdroppers​.

While many websites use HTTPS and some apps encrypt data, guests cannot be sure all their traffic is safe on an open network. Captive portals themselves do **nothing to encrypt data** after you “accept terms” – they are merely access control. As security experts note, a captive portal setup is typically an open network where *“all network traffic is effectively blocked until login, but once a user passes that gate, they are likely unprotected inside that network”*. Even if a Wi-Fi password is used for the guest network, if it’s the **same password for all guests (e.g. posted at the front desk)**, it offers little security. Everyone on that network knows the key, and with readily available hardware, a malicious actor could join and **monitor or intercept others’ traffic**​. Guests connecting smart devices in their room (like a personal Chromecast or an IP camera) are especially vulnerable on a shared network – such devices often have weak security, and an attacker on the same network could hijack them or snoop on their data​. In short, without **per-user encryption and network segmentation**, guests are sharing a virtual “living room” with strangers. This exposes personal data and opens the door to attacks like sniffing and Man-in-the-Middle. **Modern travelers are increasingly privacy-conscious** and demand security: hotels report that 80% of guests highly value cybersecurity measures on Wi-Fi​. Yet most hospitality Wi-Fi setups today fail to provide the **encrypted, personal wireless space** that people take for granted at home. The challenge for hotels is to deliver **home-like security** (where each user’s data is isolated) on a large scale, without making connectivity complicated.

### Rising Expectations for a “At-Home” Wi-Fi Experience

Guest expectations around connectivity have never been higher. Beyond raw speed and coverage, travelers want **seamless, personalized connectivity** akin to what they enjoy at home. This includes **instantly onboarding all their devices**, roaming throughout the property without reauthenticating, and using personal apps and streaming services on in-room devices. A recent survey found that **85% of hotel guests appreciate being able to control aspects of their stay via personal devices** (e.g. streaming to the TV, mobile room keys)​ – all of which require robust Wi-Fi integration. Guests now commonly arrive with streaming devices or health devices that connect to Wi-Fi, expecting they can connect them for a multi-day stay. **Remote workers** are another growing segment – 80% of guests say they plan to use hotel Wi-Fi for work, often needing VPNs and video calls without interruption​. For hotels, meeting these expectations is not just about bandwidth; it’s about user experience. **Login fatigue** is a real issue – guests are frustrated with having to re-enter credentials or go through captive portals on every device. **29% of guests in one study reported issues logging in to hotel Wi-Fi**​, indicating the hassle factor is widespread. Modern connectivity solutions aim to make access **frictionless**: ideally, a guest authenticates once and all their devices (laptop, phone, tablet, smart watch, etc.) come online easily, and even **remember the network on future visits**. Indeed, technologies like Passpoint now allow a one-time setup that will auto-connect guests securely at any property in a brand’s portfolio​. Guests essentially expect the hotel network to **“just know” who they are and what they need**, without tedious onboarding each time. Failing to deliver this convenience can hurt satisfaction. On the flip side, a smooth connectivity experience boosts ratings and loyalty. Fast, easy, secure Wi-Fi consistently ranks as one of the **top drivers of guest satisfaction** – often ahead of other amenities. Hotels that invest in modern Wi-Fi see payoffs in online reviews and repeat bookings, whereas those clinging to outdated systems face mounting complaints. In summary, today’s guest wants hotel Wi-Fi to be *invisible* (no hassles to connect), *indispensable* (supporting all the apps/devices they use daily), and *individualized* (a private, secure experience). Meeting these expectations requires a new approach to how guests access and use hotel networks.

### Beyond Captive Portals: Modern Solutions (Personal PSK, Passpoint, & More)

The good news is that technology has caught up to these challenges. **Modern Wi-Fi authentication solutions** are emerging in hospitality to replace the old captive portal model. Two notable approaches gaining traction are **Passpoint (Hotspot 2.0)** and **Personal Pre-Shared Keys (PPSK)**, sometimes called **Individual PSK or Dynamic PSK**. These solutions aim to give each guest a **secure, personalized connection** without the pain points of open networks or shared passwords.

* **Passpoint:** An industry-standard solution championed by the Wi-Fi Alliance, Passpoint enables seamless, certificate-based authentication. Hotels can provide a Passpoint profile to guests (often through a mobile app or a one-time login) – afterwards the device will automatically recognize and connect to the hotel’s secure network on every visit, **no captive portal needed**​. Passpoint networks use enterprise-grade encryption (WPA2-Enterprise/WPA3) behind the scenes, meaning each guest’s session is private. Large hotel brands have started adopting this en masse; for example, **Hyatt is implementing Passpoint worldwide** to let guests “instantly and securely connect” at any Hyatt property​. The benefit is a **frictionless experience** (much like your phone auto-connecting to cellular) combined with robust security. The challenge for smaller hotels has been the backend complexity – tying Passpoint into their systems – but managed solutions are emerging to handle that. Overall, Passpoint’s momentum is growing across hospitality as guests and brands recognize the value of **auto-connect, encrypted Wi-Fi**​.
* **Personal PSK (PPSK):** This approach provides each guest (or each room/family) a **unique Wi-Fi passphrase**, distinct from any other guest’s. The hotel broadcasts one WPA2 encrypted network for all guests, but **accepts multiple keys**, each mapping a guest to their own “personal network” segment​. This effectively creates a **personal Wi-Fi environment** for each guest or room – their devices can see and talk to each other, but are isolated from other guests. It’s like giving everyone their own private WPA2 network, without deploying hundreds of SSIDs. The PPSK approach directly tackles our earlier problems if properly implemented: **MAC randomization** no longer matters (authentication is by your personal key, not your MAC), and **headless devices** can connect using the same key with no captive portal needed. A guest can enter their personal Wi-Fi password into a smart speaker or console once, just like at home, and it will be online. Security is vastly improved too – **each guest’s traffic is encrypted with their own key**, preventing snooping. Some hospitality solutions also pair this with **personal VLANs**, meaning each guest’s devices are on an isolated subnet. In effect, it delivers “a home Wi-Fi service for hotel guests” where **“a guest’s PAN (Personal Area Network) is linked to their unique room VLAN… keeping device-to-device communication in their personal network”**. Hotels such as boutique resorts and luxury brands have trialed giving each room a unique Wi-Fi code, and the results are positive – guests can easily connect all their gadgets and even **use in-room IoT amenities securely** (like smart TVs, voice assistants) without cross-room interference.

While **PPSK and Passpoint** take different technical paths, they share the goal of **seamless, secure connectivity** tailored per guest. These approaches are **complementary** in many cases – Passpoint is great for brand-loyal guests with mobile devices (auto-connect across properties), while PPSK covers the broad range of devices (including IoT) with a simple password method. The hospitality market is seeing growing adoption of both. **Passpoint deployments are rising** not just in hotels but across travel industries​. At the same time, **individual PSK solutions are being rolled out** by forward-thinking hotels and conference centers that want to offer guests their own secure slice of the network. Industry analysts predict that within a few years, the majority of large hotel chains will move away from traditional captive portals in favor of these modern solutions that deliver **convenience&#x20;*****and*****&#x20;security**​.

### Streamlining Wi-Fi Management for IT and MSPs

For hotel IT teams and managed service providers, these new connectivity models might sound complex to administer – but that’s where **automation and cloud management** come in. **Automated, end-to-end lifecycle management** of guest Wi-Fi access is a game-changer for operational efficiency. The right platform can handle everything from provisioning a guest’s credentials at check-in, to onboarding their devices, applying the right network policies, and then seamlessly **revoking access at check-out** – all without manual intervention. This level of automation directly addresses the pain points that bog down IT staff today. Consider the time spent resetting guest passwords, helping connect a guest’s second or third device, or clearing out old device entries; a lifecycle management solution does this in the background, freeing up IT resources. In fact, hoteliers are increasingly seeking tech to **ease the strain on staff** – 65% report that adopting new technology to streamline operations is key to overcoming labor shortages​. Automating Wi-Fi access is a prime example: guests can self-serve their connectivity needs, while staff focus on higher-value interactions.

Modern cloud-based Wi-Fi management solutions for hospitality often provide **intuitive portals or integrations for this purpose**. For instance, a system might integrate with the Property Management System (PMS) so that when a guest checks in, a unique Wi-Fi passkey or user profile is automatically generated for the duration of their stay​. That information can be sent to the guest via email or printed on their check-in info. The guest then logs in once, and the system onboards all their devices under that profile. If the hotel uses an app, the credentials could even be delivered with one click in-app. Throughout the guest’s stay, the system monitors their connection quality and can even **support multiple properties** – so if the guest moves to another hotel in the chain, their profile follows them (for example, via Passpoint roaming or a cloud account). When the guest checks out, the system automatically deactivates their credentials, ensuring no lingering access. All of this happens without a front-desk agent or IT admin needing to touch the network configuration. This **automation is essential** – as one network engineer noted regarding unique PSK per guest, *“getting guests checked in quickly is extremely important… Automation is key to making this work.”*&#x200B;

From the IT perspective, a centralized Wi-Fi access management platform provides **full visibility and control**. Network admins or managed service providers (MSPs) can see how many devices each guest has, what bandwidth they’re using, and enforce fair usage or upgrades as needed. They can remotely troubleshoot connectivity issues by viewing the guest’s authentication logs in real-time. For MSPs handling multiple hotel properties, this means **everything is controlled from a single pane of glass** – they can onboard a new hotel’s Wi-Fi in minutes, apply standardized access policies across all sites, and monitor the health of every network centrally​. This not only improves service quality but also lowers operational costs. In the past, hotels might maintain separate networks for guest Wi-Fi, staff devices, IoT, etc., which was costly and complex. Now, through smarter segmentation and automation, **a single converged network can serve all needs securely**, allowing hotels to “tap their budgets for other priorities”​. The **total cost of ownership (TCO)** of Wi-Fi infrastructure improves when guest onboarding is simplified: fewer support calls (reducing helpdesk workload), less on-site IT support required, and better capacity planning through analytics. One vendor’s study notes that individualized keys and self-service onboarding can **“reduce IT support burden”** significantly while scaling to thousands of devices in the cloud​. In short, automating the Wi-Fi access lifecycle isn’t just nice-to-have – it’s becoming a necessity for hospitality IT to do more with less and deliver consistent service quality.

### Competitive Landscape and Gaps

A number of **competitive solutions** have sprung up to tackle these guest Wi-Fi challenges, each with pros and cons. Captive portal vendors (the traditional gateway providers) have added features like social media logins, loyalty program integration, and even basic device remembering via MAC auth. However, these band-aids don’t fully solve the fundamental issues (security and headless device support) and can still falter under MAC randomization changes. Some enterprise solutions involve **802.1X with dynamic VLAN assignments** (some hotels have tried using individual 802.1X certificates for guests, or creating a unique SSID per room with 802.1X authentication). While very secure, these approaches are often overly complex for the average guest and onerous for IT to manage without an orchestration layer. Additionally, a few specialist hospitality tech companies have point solutions that use IoT gateways to connect guest devices. But these can require expensive additional hardware or don’t integrate well with existing Wi-Fi infrastructure.

In summary, **no single legacy solution has ticked all the boxes** of easy onboarding, robust security, and smooth management – which is why a new generation of cloud-based SaaS platforms is entering the space. This is where **Cusna** comes in as a potential game-changer. By focusing on the holistic guest connectivity experience, Cusna addresses the gaps left by others. Traditional vendors might give you the building blocks (e.g. iPSK capability) but not the end-to-end workflow automation or multi-vendor support that a SaaS solution can provide. For instance, a hotel using Cisco or Aruba APs might not have had access to a simple PPSK solution before – Cloud4Wi’s platform-agnostic approach can layer on advanced onboarding and personal key management without ripping out existing hardware. Many current solutions also lack a friendly guest-facing interface. **Cusna** differentiates by offering a slick, customizable portal for guests to easily register once, obtain a personal WiFi password and then enjoy hassle-free connectivity throughout their stay, all while the system invisibly handles device authentication, security isolation, and lifecycle management in the background.

### In‑Network Communication for Headless Devices and Personal Area Networks

Headless devices – such as streaming sticks controlled by a smartphone, smart speakers, or even medical IoT gadgets – need to communicate seamlessly with each other within a user’s personal network. These devices often rely on local discovery protocols (e.g. AirPlay, Chromecast, mDNS) so that a phone or controller can find and manage them on the same Wi-Fi. Traditional guest Wi-Fi designs, however, pose a challenge: they emphasize client isolation for security, which inadvertently breaks legitimate multi-device interactions. In a typical captive-portal guest network, each device gets Internet access but is barred from seeing any other devices on the network​. This means a guest’s phone cannot detect or pair with their own speaker or streaming device if both are on an “isolated” guest SSID. In fact, most IoT and smart devices **need** to be on the same local network as their controllers to function properly – if they’re connected to an isolated guest Wi-Fi, they become invisible to the user’s other devices​. For example, putting a wireless printer or smart TV on a captive-portal guest network often makes it unreachable for your laptop or phone (no printing or casting can occur on the local LAN)​. The only workaround in such isolation is to route all device communication over the internet (via cloud services), which introduces latency, requires internet availability, and raises privacy concerns. This **usability gap**—where headless gadgets can’t talk to their controllers nearby—is a direct result of guest network architectures that prioritize separating devices for security.

To address this, modern guest Wi‑Fi solutions are shifting toward **Personal Area Networks (PANs)** for each user. Instead of lumping every guest device into one big isolated network (or conversely, one free-for-all network), each guest or user is given their own **private Wi‑Fi segment** that behaves like a mini home network just for them. Within this personal segment, all of that guest’s devices can discover and communicate with each other freely, but they remain isolated from everyone else’s devices. This approach preserves security *and* enables functionality for headless and multi-device use cases. A user in a hotel, for instance, can connect their streaming stick and their phone to the hotel Wi‑Fi and the two will be in their own PAN – the phone can cast videos to the streaming stick as if on a home router, and no other guest can see or connect to either device. Legacy guest networks offered a poor choice between **no isolation** (everyone sees everything – a privacy and security nightmare​) or **total isolation** (nobody can see anything – breaking IoT devices). PANs solve this by offering **per-guest isolation**: you see only your own devices, providing a *“home-like user experience”* on a shared network. Discovery protocols like AirPlay, Chromecast, or Sonos auto-discovery will only surface your personal devices rather than a clutter of others, and *no one else* can access or spy on your devices​. This concept is sometimes also called a “private client group” or “user-defined network” – essentially a VLAN-like bubble unique to each user.

**Why not just use VLANs?** In theory, one could give each guest or room a separate VLAN and SSID to isolate their traffic. However, VLAN-based PANs at scale become unwieldy. Managing potentially thousands of VLANs (one per user or family) across switches and APs is complex and doesn’t scale well – network engineers would need to configure VLAN IDs, trunk ports, and IP subnets/DHCP scopes for each one. This approach **burdens the network infrastructure** with excessive configuration overhead​. Every new guest might require a new VLAN interface and a unique IP range, quickly exhausting VLAN limits or admin patience. Additionally, roaming or moving between access points can break connectivity if the user’s dedicated VLAN isn’t available everywhere, unless the network backhaul is meticulously set up to tunnel or propagate all those VLANs. All of this adds deployment cost and complexity for guest Wi-Fi solutions.

Fortunately, modern wireless networking equipment offers smarter Layer-3 segmentation techniques to achieve PANs *without* dedicating a VLAN per user. Several enterprise Wi-Fi vendors have introduced features that dynamically isolate clients into personal network partitions on the same SSID and IP subnet:

* **Cisco Meraki – Wi-Fi Personal Network (WPN):** Meraki’s WPN segments the wireless network on a per-user basis while **keeping all users on a single VLAN**​. This means administrators no longer need separate VLANs for each room or user. WPN creates a contained “virtual network” for each user, so that *only their devices* can communicate and be discovered, delivering a private home-like environment even on a shared SSID​. Meraki’s implementation can use techniques like individual pre-shared keys (iPSKs) or identity-based grouping to enforce this isolation. The key point is that discovery and multicast traffic (e.g. AirPlay, Chromecast) is segmented per user, resolving the headless device usability issue without VLAN sprawl​.
* **Cisco Catalyst – User Defined Network (UDN):** Cisco’s UDN (available with Catalyst 9800 series controllers and DNA Center) similarly gives each user their own “network slice.” Users onboard their devices (often via a mobile app or portal tied into Cisco’s system), and those devices are tagged to the user’s personal network ID. **Only devices in the same user’s group can see each other**, while others remain invisible​. This provides the resident or guest a secure personal network experience on shared Wi-Fi. UDN even allows users to invite *trusted friends* into their personal network (for example, if you want a friend in the next dorm room to cast to your smart TV, you can explicitly share access)​. All of this is achieved through software-defined segmentation rather than unique VLANs, using the wireless controller to restrict traffic at Layer 3.
* **Aruba Networks – Personal Wi-Fi Network (PWN):** Aruba’s solution (in ArubaOS 10 and Aruba Central) uses **Multi-PSK** (multiple simultaneous pre-shared keys on one SSID) combined with role-based firewalling to create personal networks. Essentially, each user or device group gets a unique WPA2/WPA3 key, and Aruba’s infrastructure isolates traffic such that devices using that key can talk to each other but not beyond​. Like other solutions, this allows a guest’s devices to operate together *“in a VLAN”* (logically) that is their own, ensuring only devices within that group interact with each other. Services like mDNS (AirPrint, AirPlay, etc.) are filtered so they stay within the owner’s group unless explicitly shared. This PWN approach avoids multiplying SSIDs or VLANs while still granting each user a private space.
* **Extreme Networks – Private Client Groups (PCGs):** Extreme’s access points support Private PSK (PPSK) and Private Client Group features via ExtremeCloud IQ. Administrators can issue unique pre-shared keys to each user or device group, and the AP will enforce a private client group for those using the same key. All devices using a particular PPSK can discover each other and exchange data, but **broadcasts and traffic are filtered** so nothing leaks between groups​. This achieves the personal LAN effect on a single SSID. Extreme’s PCG can operate in different modes (e.g. one PPSK per user, or one shared PPSK for a defined group like a family) to balance security with ease of use. Crucially, it avoids the need to create a mountain of VLANs or separate SSIDs for isolation.

These advancements make it feasible to deliver **per-guest personal networks** at scale without redesigning the underlying LAN for each user. Cloud4Wi’s **Cusna** solution builds on these technologies to provide seamless PAN orchestration across multi-vendor Wi-Fi infrastructures. In practice, Cusna acts as a cloud-managed brain that integrates with the access network (via standard mechanisms like RADIUS, APIs, or vendor-specific hooks) to automatically assign each guest’s devices into an isolated personal area network. This happens behind the scenes: a guest connects to the single guest SSID and logs in through the captive portal (for example), and Cusna ensures that device is placed into that guest’s unique segment. If the guest onboards a second or third device (including headless ones) through the same portal or a pre-shared key, those devices are tagged to the same PAN, allowing them to see each other instantly. The **heavy lifting of segmentation is handled in software**, leveraging the capabilities of Meraki, Cisco, Aruba, Extreme (and others) that we described above. For instance, on a Meraki network, Cusna can automate the creation and assignment of iPSKs/WPN Group Policies for each guest user, so that all their gear joins the correct personal VLAN or group **without** an admin manually configuring keys or VLANs for each person. The result is that each guest’s devices communicate freely and securely within their own mini-network, while *remaining isolated from every other guest’s devices by default*. Importantly, this is achieved with minimal impact on the existing network configuration. IT teams don’t need to design complex VLAN schemas or deploy separate SSIDs per user – they simply enable the PAN capability on their Wi-Fi platform (as discussed above) and let Cusna handle the dynamic assignments and credentials. Switch configuration is kept simple (often just one or a few VLANs for all guests), and DHCP management is straightforward (serving a common pool, since the segmentation is done at Layer 3 via the AP/controller logic). In short, Cusna by Cloud4Wi marries the convenience of a cloud-managed guest Wi-Fi onboarding solution with the power of modern network segmentation, ensuring headless devices and multi-device guests get the connectivity experience they need **without compromising security or requiring a networking overhaul**. The guest enjoys a frictionless, secure “at-home” experience on your Wi-Fi, and the IT team enjoys a solution that is scalable and easy to manage.​

### Enhancing Guest Loyalty and ROI with Next-Gen Wi-Fi

Investing in a modern connectivity solution is not just an IT upgrade; it’s a strategic move that can drive guest loyalty and improve financial outcomes. When guests have an experience where “the Wi-Fi just works” – their phone connects securely as soon as they step into the lobby, their laptop and iPad remember the network from last time, and their smart devices work as they do at home – it creates a strong positive impression. Guests can focus on their trip, whether business or leisure, rather than fighting the Wi-Fi. This convenience and peace of mind translate into **higher guest satisfaction scores** and more positive reviews. Over time, that boosts a hotel’s reputation and **increases the likelihood of repeat visits**. On the flip side, we know that poor Wi-Fi is a top driver of negative reviews and lost business; solving it removes a major source of friction. In fact, delivering excellent Wi-Fi can become a selling point – **73% of travelers say they are more likely to choose a hotel that offers tech like seamless mobile check-in and connectivity**​. This suggests guests actively seek out hotels that keep up with modern tech trends, including connectivity.

From an operational standpoint, solutions like Cusna  can significantly **lower the total cost of ownership** of hotel Wi-Fi. By automating processes that used to require human intervention (generating guest credentials, onboarding devices, troubleshooting access issues), hotels cut down on support labor. Fewer calls to the front desk or IT support for Wi-Fi problems means staff can be reallocated to more guest-centric tasks – or hotels can operate with leaner staff without sacrificing service. Moreover, an intelligent platform can optimize network usage (for example, by segmenting heavy IoT traffic away from guest bandwidth) to improve performance without necessarily increasing internet circuit costs​.

All these efficiencies contribute to a better ROI on the Wi-Fi infrastructure. Hotels also avoid potential costs associated with security incidents. A secure, encrypted network for each guest reduces the risk of data breaches or malicious attacks on guests via the Wi-Fi. This can protect the hotel from liability and the damaging publicity of cyber incidents – an increasingly important consideration as hospitality has become a target for cyber attacks in recent years​.

***

In conclusion, the hospitality industry is at an inflection point with guest Wi-Fi. **Guest expectations have outgrown the old captive portal model**, and issues like MAC randomization and IoT onboarding underscore that status quo solutions aren’t sufficient. Hotels that adapt by deploying next-gen connectivity – such as personal pre-shared keys, Passpoint, and automated access management – will set themselves apart as tech-forward, guest-centric properties. The payoff is twofold: **delighted guests who feel right at home (and keep coming back)**, and **streamlined operations for IT and management with lower support costs**. A platform like *Cusna* is poised to deliver on this vision, enabling hotels to offer **seamless, secure, and personalized Wi-Fi** as part of the guest experience. Backed by industry-leading cloud management and automation, it transforms Wi-Fi from a common pain point into a competitive advantage. The hotels that leverage such innovations can expect not only happier guests in the short term, but also long-term loyalty and improved profitability – truly a win-win in the evolving landscape of hospitality tech.


# BYOD

In most corporate networks, the conventional method to deliver BYOD connectivity relies on a **captive portal** paired with corporate SSO. Employees use a web-based login process each time they join the network, which is secure and familiar. However, this “as-is” solution comes with several challenges that have become more pronounced over time.

One major issue is that modern operating systems increasingly **randomize MAC addresses** to protect user privacy. This MAC rotation forces users to re-enroll every time their device’s identity changes, creating a frustrating cycle of repeated logins and credential revalidation. Additionally, because **each device must undergo its own enrollment process** via the captive portal, the overall user experience suffers when employees carry multiple personal devices. This situation becomes even more complicated for **headless devices**—like medical monitors or IoT sensors—that lack a traditional user interface. Such devices are typically incompatible with captive portal mechanisms, leaving them unable to connect through these conventional means. Moreover, the use of **open networks**, even with captive portals, is no longer acceptable from a security standpoint; organizations today require more robust solutions that ensure every connection is both authenticated and monitored.

PPSK offers a transformative alternative that directly addresses these issues. With PPSK, network access is secured through the assignment of unique pre-shared keys that are tied to an individual’s identity during a **one-time enrollment process**. This key can then be used seamlessly across all of an employee’s devices, effectively eliminating the need for repeated re-enrollment—even when MAC addresses rotate. Because the authentication mechanism is based on a pre-shared key rather than a device’s MAC address, it also readily supports **headless devices,** which can now connect without any interface-based challenges. Furthermore, by moving away from a reliance on open or captive portal-based connections, PPSK offers a far more **secure network environment**. The centralized management of keys also means that administrators benefit from enhanced **visibility**, robust **access control**, and detailed **connection logs**, ensuring **accountability** at every step. A significant advantage of this centralized approach is the facilitation of **cross-branch roaming**; employees can move seamlessly between locations without any additional configuration steps, making the network both agile and secure.

In summary, transitioning to a PPSK solution not only simplifies the enrollment process—ensuring one-time setup for all devices—but also overcomes the shortcomings of MAC rotation and captive portal limitations. The result is a more secure, user-friendly, and administratively efficient way to manage BYOD in today’s diverse workplace.