Complete Steps to Onboard Island Browser in Azure Infrastructure
Island is an enterprise browser built on Chromium that lets IT and security teams control what employees can do inside web applications — down to copy/paste, screenshot, file upload, and print. Getting it wired into Azure changes how you think about browser security. This guide covers the full onboarding path: Entra ID app registration, SAML SSO, Intune deployment, conditional access, and policy verification.
April 2026 | ⏱ 16 min read | ⚙ Azure Entra ID • Intune • Island Management Console | Enterprise & Zero Trust deployments
What Is Island Browser?
Island is an enterprise-managed Chromium browser. Unlike consumer browsers locked down with extensions, Island gives IT full control over every session — which apps open in it, what users can do in those apps, and what data can leave. It integrates with your identity provider (Azure Entra ID in this case) for SSO, and you manage policies centrally from the Island Management Console (IMC). Endpoints run Island instead of Chrome or Edge for protected workloads.
⚠ Before You Start — Prerequisites
| ☑ | Azure Entra ID (formerly Azure AD) with at least P1 licensing for conditional access |
| ☑ | Microsoft Intune license active (for MDM deployment of the Island MSI/PKG) |
| ☑ | Island tenant provisioned — your Island account manager provides the Management Console URL and initial admin credentials |
| ☑ | Global Administrator or Application Administrator role in Entra ID |
| ☑ | Island browser installer (MSI for Windows, PKG for macOS) downloaded from the Island Management Console |
Steps Covered in This Guide
Step 1. Register Island as an Enterprise App in Azure Entra ID
Step 2. Configure SAML-Based Single Sign-On
Step 3. Map Azure AD Groups to Island Roles
Step 4. Configure Island Management Console (IMC) Identity Settings
Step 5. Deploy Island Browser via Microsoft Intune
Step 6. Create and Assign Island Browser Policies
Step 7. Set Up Azure Conditional Access for Island
Step 8. Onboard Protected Web Applications into Island
Step 9. Verify the Deployment End-to-End
Step 10. Troubleshooting Common Issues
|
Step 1 of 10 Register Island as an Enterprise App in Azure Entra ID |
|
Island doesn’t ship a pre-built app in the Azure gallery for SAML SSO, so you register it manually as a custom enterprise application. Here’s the exact path:
Azure Portal > Microsoft Entra ID > Enterprise Applications > + New Application > + Create your own application
In the “Create your own application” panel:
| Field | Value to Enter |
| Name | Island Browser SSO (or any name your team will recognize) |
| What are you looking to do? | Integrate any other application you don’t find in the gallery |
| Supported account types | Accounts in this organizational directory only |
Click Create. Azure provisions the enterprise application and drops you into its overview blade. Keep this tab open — you’ll pull values from here in Step 2.
Assign users and groups now. In the enterprise app blade, go to Users and groups > + Add user/group. Add the Azure AD security groups whose members will use Island. Only users in assigned groups can authenticate through this app. Get this wrong and SSO will silently fail during onboarding tests.
|
Step 2 of 10 Configure SAML-Based Single Sign-On |
|
In the enterprise application blade, click Single sign-on in the left nav, then choose SAML.
Enterprise App > Single sign-on > SAML
Section 1 of the SAML config asks for the Basic SAML Configuration. The values below come from your Island Management Console. Log into IMC, navigate to Settings > Identity Provider, and Island will display the exact ACS URL and Entity ID for your tenant.
| Azure SAML Field | Value (from Island IMC) |
| Identifier (Entity ID) | https://<your-island-tenant>.island.io/saml/metadata |
| Reply URL (ACS URL) | https://<your-island-tenant>.island.io/saml/acs |
| Sign on URL | https://<your-island-tenant>.island.io/saml/login |
| Relay State | Leave blank unless Island support specifies otherwise |
Save the Basic SAML Configuration. Scroll down to Section 3 — SAML Certificates and download the Federation Metadata XML file. You’ll upload this into Island IMC in Step 4.
Configure SAML Attributes and Claims
Island needs at minimum the user’s email address to match against its user records. In Section 2 of the SAML configuration, click Edit on Attributes & Claims and verify these are present:
| Claim Name | Source Attribute | Notes |
| emailaddress | user.mail | Primary identifier Island uses |
| givenname | user.givenname | Displayed in Island user list |
| surname | user.surname | Displayed in Island user list |
If your users’ user.mail attribute is not populated in Entra ID (common in some hybrid setups), use user.userprincipalname instead, and tell Island support so they can match the format on their side.
|
Step 3 of 10 Map Azure AD Groups to Island Roles |
|
Island uses group membership to determine which browser policies apply to a user. You send group information through the SAML assertion via a groups claim. Without this, every authenticated user lands in the default policy — which is fine for testing, but not for production.
In the Attributes & Claims blade, click Add a group claim:
| Setting | Recommended Value |
| Which groups to include | Security groups (avoid “All groups” — it inflates the token) |
| Source attribute | Group ID (sAMAccountName for on-prem synced groups) |
| Claim name (advanced) | http://schemas.microsoft.com/ws/2008/06/identity/claims/groups |
Token size warning: If users belong to more than 150–200 Azure AD groups, the groups claim gets dropped from the SAML token entirely due to token size limits. In that case, switch to sending specific group Object IDs for only the Island-relevant groups, or use app roles instead. Island support can advise based on your setup.
|
Step 4 of 10 Configure Island Management Console Identity Settings |
|
Log into the Island Management Console (IMC) with your admin credentials. Navigate to:
IMC > Settings > Identity Provider > + Add Identity Provider
Choose SAML 2.0 as the protocol. Upload the Federation Metadata XML you downloaded from Azure in Step 2. Island parses it automatically and fills in the SSO URL, certificate, and entity ID for you.
| IMC Field | Action / Value |
| IDP Metadata | Upload the Azure Federation Metadata XML file |
| Email Attribute | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
| Groups Attribute | http://schemas.microsoft.com/ws/2008/06/identity/claims/groups |
| Domain | Your organization’s email domain (e.g., yourcompany.com) |
| Just-in-Time Provisioning | Enable — creates Island user records automatically on first SSO login |
Save. IMC will show the Island SP metadata (Entity ID and ACS URL) for your tenant. These are the same values you already entered in Azure in Step 2 — confirm they match.
Map Azure AD Groups to Island Groups
In IMC, go to Settings > Groups and create Island groups that correspond to your Azure AD security groups. For each Island group, paste in the Azure AD group Object ID (not the display name). Island uses this to match the groups claim in the SAML token and assign the correct browser policy to each user.
Find the Object ID: Azure Portal > Entra ID > Groups > [Your Group] > Overview > Object ID. Copy it directly — it’s a GUID like a1b2c3d4-...
|
Step 5 of 10 Deploy Island Browser via Microsoft Intune |
|
Island distributes as an MSI (Windows) or PKG (macOS). You push it through Intune as a Win32 app (Windows) or a macOS LOB app. This is where most teams spend the most time — the app itself installs cleanly, but getting the enrollment token right matters.
Windows Deployment (Intune Win32 App)
Intune Portal > Apps > Windows > + Add > Windows app (Win32)
| Intune Field | Value / Action |
| App package file | Convert Island MSI to .intunewin using Microsoft Win32 Content Prep Tool |
| Install command | msiexec /i IslandBrowser.msi /qn ENROLLMENT_TOKEN=<YOUR_TOKEN> |
| Uninstall command | msiexec /x IslandBrowser.msi /qn |
| Install behavior | System |
| Detection rule | File exists: C:\Program Files\Island\Island.exe |
Enrollment Token: Get this from IMC > Settings > Deployment. It tells the Island browser instance which tenant to register with on first launch. Without it, Island installs but can’t connect to your management console.
macOS Deployment (Intune LOB App)
Intune Portal > Apps > macOS > + Add > Line-of-business app
Upload the Island PKG file. Set the bundle ID to com.island.Island. For the enrollment token, create a pre-install script that writes the token to a known path Island reads on first launch — Island’s deployment documentation specifies the exact location for your version.
Assignment: Assign the Intune app to the same Azure AD groups you assigned to the Island enterprise app in Step 1. Required deployment (not available) ensures the browser lands on all designated machines without waiting for users to install it themselves.
|
Step 6 of 10 Create and Assign Island Browser Policies |
|
Island policies are the core of the product. They define what a user in a given group can do: copy/paste, download files, print, take screenshots, run extensions, and more. You build them in IMC and they apply the moment a user opens Island and authenticates.
IMC > Policies > + Add Policy
Typical starting point for a production deployment:
| Policy Setting | Full Admin | Standard User | Contractor |
| Copy from protected apps | ✓ Allow | ✓ Allow | ✗ Block |
| Paste to external apps | ✓ Allow | ✗ Block | ✗ Block |
| File downloads | ✓ Allow | ✓ Allow | ✗ Block |
| Screenshot / screen capture | ✓ Allow | ✗ Block | ✗ Block |
| DevTools access | ✓ Allow | ✗ Block | ✗ Block |
Assign each policy to the corresponding Island group. Policy evaluation is top-down — if a user belongs to multiple groups, Island applies the first matching policy. Order your groups in IMC accordingly.
|
Step 7 of 10 Set Up Azure Conditional Access for Island |
|
Conditional Access ties Azure’s security signals — device compliance, user risk, sign-in risk — into the Island authentication flow. The most common use case: require that only Intune-compliant devices can authenticate with Island.
Azure Portal > Entra ID > Security > Conditional Access > + New Policy
A working baseline CA policy for Island:
| Policy Section | Configuration |
| Users | The Azure AD groups assigned to Island |
| Target resources | Select Apps → “Island Browser SSO” (the enterprise app from Step 1) |
| Conditions > Device platforms | Windows, macOS (whichever platforms Island runs on in your org) |
| Grant | Require device to be marked compliant (Intune compliance) |
| Grant (MFA) | Require multi-factor authentication |
| Session | Sign-in frequency: set to your org’s session policy (e.g., 8 hours for unmanaged devices) |
Test in Report-Only first. Set the policy to Report-Only mode before enabling it. Check the Sign-in Logs for a week to see who would be blocked. Switching it to Enabled with untested conditions will lock out users who haven’t enrolled their devices in Intune yet.
|
Step 8 of 10 Onboard Protected Web Applications into Island |
|
Island controls what users can do inside specific web applications. For that to work, you tell Island which apps are “protected” and which policies apply to them. An unprotected app opens in Island but gets no special controls.
IMC > Applications > + Add Application
For each application you want to protect:
| Field | What to Enter |
| Application name | Descriptive name (e.g., Salesforce, Jira, Internal HR Portal) |
| URL / Domain pattern | e.g., *.salesforce.com or exact URL |
| Force open in Island | Enable — redirects any click on this URL to Island automatically |
| Applied policy | Select the policy from Step 6 (can vary by application) |
The “Force open in Island” option means that if a user clicks a Salesforce link in Outlook, it opens in Island rather than Edge or Chrome. This is how you ensure the protected experience actually applies — users can’t sidestep it by opening the URL in a different browser.
Start with one or two low-risk applications — an internal tool or a test Salesforce sandbox. Get the policy settings right on those before rolling Island out to business-critical apps. Users notice immediately when copy/paste is blocked; you want to catch policy mistakes before they hit 500 people at once.
|
Step 9 of 10 Verify the Deployment End-to-End |
✅ |
Run through this checklist on a test machine with a test user account before broader rollout:
| Verification Check | Expected Result |
| Open Island Browser on enrolled device | Island launches and prompts for sign-in |
| Sign in with Azure AD credentials | MFA prompt appears, then authenticated session in Island |
| Navigate to a protected application URL | Opens inside Island, Island toolbar visible at bottom/top |
| Attempt blocked action (e.g., copy for Contractor policy) | Action is silently blocked or warning shown per policy config |
| Check IMC > Users | Test user appears with correct group assignment |
| Check IMC > Activity Logs | Session events logged with user, time, app, and policy name |
| Check Azure Sign-in Logs | Successful authentication against “Island Browser SSO” enterprise app, CA policy applied |
Confirm in IMC that the user’s assigned policy is the one you intended. Group precedence issues (user in multiple groups, wrong policy applied) are the most common post-deployment bug and they’re invisible unless you check the IMC user record directly.
Step 10 — Troubleshooting Common Issues
| Symptom | Most Likely Cause & Fix |
| SSO fails, “Application not found” | User not assigned to the enterprise app in Entra ID. Add their group under Users and Groups in the enterprise app. |
| SAML error: “Audience restricted” | Entity ID mismatch between Azure and IMC. Copy the exact string from IMC and repaste into Azure SAML config. |
| User authenticates but no policy applied in Island | Groups claim not reaching Island. Check Azure sign-in logs for the groups claim. Token may be too large — switch to selected groups instead of all groups. |
| Island browser shows “Not managed” after install | Enrollment token missing or wrong. Reinstall with correct ENROLLMENT_TOKEN from IMC > Settings > Deployment. |
| Conditional Access blocking Island login | Device not enrolled in Intune or non-compliant. Check device compliance in Intune. Confirm the CA policy targets the Island enterprise app specifically, not all apps. |
| Protected app opens in Edge/Chrome instead of Island | “Force open in Island” not enabled for that app in IMC, or Island’s OS-level URL handler not registered. Reinstall Island to re-register the protocol handler. |
| Wrong policy applied to user | User belongs to multiple Island groups. Policy order in IMC is first-match. Reorder groups or create a more specific condition for the user’s correct group. |
Frequently Asked Questions
Does Island work with Azure AD Hybrid Join devices?
Yes. Island’s Intune deployment works on both Hybrid Azure AD Joined and Azure AD Joined devices. The SAML authentication goes through Entra ID regardless of join type. The Conditional Access device compliance check uses Intune’s compliance policy, which works on both join modes as long as the device is enrolled in Intune.
Can Island replace Azure AD Application Proxy for internal apps?
Partially. Island can securely access internal applications if combined with a network path (VPN or Azure Virtual Network). Island itself doesn’t provide the network connectivity — it controls what users can do once they’re connected. App Proxy handles the connectivity layer. They can work alongside each other, with App Proxy providing access and Island controlling behavior within the session.
Does Island support OIDC instead of SAML for Azure integration?
Island supports both SAML 2.0 and OIDC. The SAML path is more commonly used for enterprise deployments because group claims are better supported in SAML tokens for Island’s current policy engine. Check with your Island account team for the latest support status, as OIDC support has been expanding across Island versions.
What happens if an Island user tries to open a protected URL in Chrome?
If “Force open in Island” is enabled in IMC for that URL, Island registers itself as the OS-level handler for those domains. Clicks from other applications (email, Teams, Slack) get intercepted and handed off to Island. Opening the URL directly in Chrome is still technically possible — Island doesn’t block Chrome from running — but you can combine this with Azure Conditional Access App Control to enforce that only Island sessions get valid session tokens for those apps.
How long does a full Island onboarding in Azure typically take?
For a straightforward deployment with one identity provider and a few applications, the Azure/IMC configuration side takes 2–4 hours. Intune packaging and testing adds another half-day. Rolling out to a pilot group of 20–50 users, validating policies, and adjusting takes 1–2 weeks. A full org-wide rollout with multiple application onboardings and policy tuning is typically a 4–8 week project.
The Short Version
| 1. | Create a custom enterprise app in Entra ID |
| 2. | Configure SAML SSO — ACS URL and Entity ID from Island IMC |
| 3. | Send groups claim with Azure AD group Object IDs |
| 4. | Upload Azure Federation Metadata XML into Island IMC |
| 5. | Deploy Island MSI/PKG via Intune with Enrollment Token |
| 6. | Create browser policies per group in IMC |
| 7. | Set up Conditional Access — test in Report-Only first |
| 8. | Add protected applications to IMC with “Force open in Island” |
| 9. | Verify with a pilot user before org-wide rollout |
