Permissions, Data & Security

This page covers everything an IT administrator or security reviewer needs to assess Iristick.Teams: the exact permissions the app requests, what it stores versus displays, how communication is encrypted, and how authentication is handled.

It applies to the out-of-the-box (OOTB) deployment, where Iristick hosts the backend. For the self-hosted variant, all data stays in your own Azure tenant — see OOTB vs Self-Hosted.

Why an Azure Communication Services Resource Is Required

A common question from IT and security teams is: if our users already have Microsoft 365 and Teams licenses, why does Iristick.Teams need an Azure Communication Services resource at all?

Because ACS is the only programmatic path Microsoft offers for a third-party app to join a Teams meeting as a participant. The official Microsoft Teams client uses internal Microsoft endpoints that are not exposed to third parties. Iristick.Teams is a third-party app, not the official Teams client, so it must use ACS to bridge into Teams calls. A Microsoft Graph access token alone does not grant the app permission to place a call — ACS calls require a separate, short-lived ACS Identity token, and that token can only be minted by the owner of an ACS resource.

What the ACS resource actually does

The ACS resource has a narrow role. It does not carry call media.

Role	What it does
Token issuer	Mints short-lived ACS Identity tokens (typically 24h) for each signed-in user
Routing endpoint	Provides the entry point the app dials into to reach a Teams call
*What it does not* do**	Carry audio or video. Once a call is up, media flows over the standard ACS media path — peer-to-peer to Microsoft-operated relays. Bytes never touch the ACS resource owner's infrastructure

Think of the ACS resource as a key issuer, not a data pipe. Whoever owns it can mint the tokens that let the app authenticate against ACS. Microsoft moves the actual call bytes regardless of who owns the resource.

Why OOTB uses Iristick's ACS resource and self-hosted uses yours

This is the single most important architectural choice between deployment modes:

OOTB: Iristick owns the ACS resource. Iristick's backend mints ACS Identity tokens on behalf of your users when they sign in. Microsoft still operates ACS underneath; audio and video still flow peer-to-peer through Microsoft relays. Iristick is in the token-issuing path, not the media path.
Self-hosted: You own the ACS resource in your own Azure subscription. The token-broker backend (binaries provided by Iristick) runs in your Azure. Your users get ACS tokens from your infrastructure. Nothing Iristick-controlled is in the authentication path.

Self-hosted is the right choice when your requirement is "no Iristick-controlled infrastructure may be in the path" — typically data residency, sovereignty, or contractual constraints. It is not required for call-content confidentiality, because call media goes through Microsoft ACS in both modes.

Service Principals Created in Your Tenant

When admin consent is granted, two service principals appear in your Microsoft Entra tenant:

Service Principal	App ID	Role
Iristick.Teams	`9e29744b-7398-4b14-8ba9-4b341b36c0b4`	The Iristick.Teams enterprise application — handles sign-in and Graph API access
Azure Communication Services	`1fd5118e-2576-4263-8130-9503064c837a`	Microsoft's first-party app — required to bridge calls into Microsoft Teams

Verify both service principals exist

Granting consent to Iristick.Teams should also provision the Azure Communication Services service principal, but in some tenants this does not happen automatically. If users sign in successfully but cannot join calls, the ACS service principal is the most common cause. See Troubleshooting → ACS service principal missing.

Permissions Requested

All permissions are delegated — the app acts only on behalf of the signed-in user, never independently. Tokens are short-lived and scoped to what your admin has granted.

Microsoft Graph (Iristick.Teams app)

Permission	Why it's needed
`User.Read`	Read the signed-in user's profile (display name, user ID, tenant ID, email)
`User.ReadBasic.All`	Look up contacts by display name and email
`Contacts.Read`	List and search through the user's contacts
`Calendars.Read`	Show today's Teams meetings so the user can join them from the glasses
`Team.ReadBasic.All`	Resolve team information for contacts
`OnlineMeetings.ReadWrite`	Create ad-hoc Microsoft Teams meetings from the glasses
`ChatMessage.Send`	Send chat messages triggered by voice commands (e.g. "TAKE PICTURE" posts to chat)
`Chat.Read`	Receive new chat messages so they can be displayed in the HUD
`Chat.ReadWrite`	Read and send chat messages within an active conversation

Azure Communication Services

Permission	Why it's needed
`Teams.ManageCalls`	Place and manage calls into Microsoft Teams via ACS

Data Handling

Stored by Iristick (OOTB only)

A limited set of metadata is stored in the Iristick backend for authentication, usage tracking, billing, and abuse monitoring:

Data	Purpose
Display name	User identification
User ID	Account linking
Tenant ID	Organization mapping
Email address	Contact and billing
Call summary	Usage tracking: who started the call, duration, which headset

Call summaries contain no participant content

Summaries record only metadata: initiator, duration, and headset. No information about other participants, call content, audio, or video is stored.

Displayed but not stored

The following is retrieved through the Microsoft Graph API and rendered in the app. It is not stored on Iristick servers — it stays in your Microsoft 365 environment.

Recent Microsoft Teams chats
Microsoft Teams contacts
Today's calendar meetings

Call media

Call audio and video flow directly between the device and Azure Communication Services. They do not pass through Iristick servers.

Encryption

In transit

All connections use TLS 1.2 or higher:

Connection	Protocol
App → Microsoft Graph API	HTTPS / TLS 1.2+
App → Azure Communication Services	HTTPS / TLS 1.2+
App → Iristick backend	HTTPS / TLS 1.2+

At rest

All data stored in the Iristick backend is encrypted with AES-256.

Authentication

Iristick.Teams authenticates users via MSAL (Microsoft Authentication Library). Three things follow from that:

Iristick never sees user credentials. Sign-in is redirected to a Microsoft-owned page. The user enters their Microsoft 365 credentials directly on Microsoft's platform. Iristick does not see, process, or store them.

Your admin stays in control. Authentication runs through Microsoft Entra ID. You decide which permissions the app receives, which users can sign in, and which conditional access policies apply. Permissions can be revoked at any time from the Azure portal.

Tokens, not passwords. After successful sign-in, Microsoft issues short-lived access tokens scoped to the permissions you granted. The app uses these to call Graph and ACS. Tokens expire automatically and are refreshed via standard OAuth flows.

flowchart LR
    A[User opens app] --> B[Redirected to Microsoft login]
    B --> C[User enters M365 credentials]
    C --> D[Microsoft Entra ID validates]
    D --> E[Token issued to app]
    E --> F[App accesses Graph API & ACS]
    E --> G[Token exchange with Iristick backend]

Access Control with App Roles

Iristick.Teams uses Microsoft Entra ID app roles as its access-control mechanism. App roles are a standard Entra ID feature for declaring which categories of users an enterprise application supports, and which users or groups are allowed to sign in.

The role defined

The Iristick.Teams app registration declares one app role:

Display name	Value	Description
User	`Iristick.Teams-User`	Standard user of the Iristick.Teams app

When you grant admin consent, the role flows automatically into the Iristick.Teams service principal in your tenant. No action required to create it.

Why only one role

Iristick.Teams has no admin, read-only, viewer, or other role distinctions inside the app — every signed-in user has the same in-app capabilities (join calls, manage their own session, send chat). There is therefore nothing to differentiate at the role level, so the design exposes a single User role rather than inventing roles that map to nothing functional.

If your tenant policy requires role-based assignment to gate access, this is the role you assign users or groups to.

Two access modes

By default, any licensed user in your tenant can sign in to Iristick.Teams once admin consent is granted — no per-user assignment required. This is the right default for most rollouts because the app is gated by license consumption anyway.

If you want tighter control, set Assignment required = Yes on the Iristick.Teams enterprise application. The effect:

Setting	Who can sign in
Assignment required = No (default)	Any user in your tenant with a Microsoft 365 Business Basic (or higher) license
Assignment required = Yes	Only users or groups explicitly assigned to the User role

Use Assignment required = Yes for pilot rollouts, regulated environments, or when you want to enforce that only a specific department, site, or group of fieldworkers can use the app — independent of who happens to hold a license.

How it appears in the token

When a user signs in, Microsoft Entra ID issues an access token that includes the assigned role in the roles claim:

{
  "roles": ["Iristick.Teams-User"],
  ...
}

The app uses this claim as one of the signals that the user is authorized. Users without the role (when Assignment required is on) receive a sign-in error and never reach the app — Microsoft Entra blocks them before any token is issued.

See Verify & Restrict Access for the click-by-click steps.

Self-Hosted Variant

Organizations with strict data residency or sovereignty requirements can deploy Iristick.Teams entirely within their own Azure tenant. In that configuration:

The ACS resource lives in your Azure subscription (in OOTB it lives in Iristick's)
The token broker and metadata backend run in your Azure (in OOTB they run in Iristick's backend)
No metadata (user info, call summaries) is stored on Iristick infrastructure
The app is distributed via your MDM

Call audio and video flow through Microsoft's Azure Communication Services in both deployments — they never traverse Iristick servers in either mode. Self-hosted is about removing Iristick-controlled infrastructure from the path, not about protecting call content.

See Self-Hosted Enterprise Setup and the OOTB vs Self-Hosted comparison.