App assignments

An app assignment records that a person, or a group, is entitled to an application, and how they sign in to it. It is the list an auditor means when they ask who has access to what, and — now — it is also a real access control, not only a record.

Where it lives

Identity → App assignments, headed App assignments, with the description Who can sign in to which application, and how. One row per person-or-group per app — this is the list an auditor asks for. Press Assign an app.

Reading needs users.read and creating, changing or removing an assignment needs users.write. Note that it rides on the user permissions rather than having its own, so anybody who can edit a user record can edit an assignment.

The table shows Application, Assigned to, Kind, Sign-in method and Status, with a search across app, person and group. The counters above it are worth reading as a summary of your posture: Assignments, Via a group (subtitled Grows as people join), One person only, and Inactive (Recorded, but nobody gets in).

Creating one

The wizard has three steps — The app, Who gets it, How they sign in.

`App ID`

A short lower-case name for the application, used everywhere Qorionix refers to it — including the conditional-access policy that governs sign-ins to it. Choose it once and do not change it.

`Display name` and `Logo URL`

For humans and for the tile.

`Assign to`

A group or one person, and the wizard has a firm opinion about which: a group means Everyone in the group gets the app, and anyone who joins it later gets it automatically. This is the one to use — it means onboarding somebody is one action, not twelve. One person is Right for an exception, but if you find yourself doing it repeatedly, make a group instead.

`Sign-in method`

None — just record the access, SAML, OpenID Connect, or Password fill-in (SWA). This field itself is descriptive — which protocol an app actually uses is decided by how it's registered, not by this label — but see the callout above: Status, unlike this field, now genuinely gates.

`Status`

Active or Inactive. The help text is now literally accurate rather than aspirational: Set it to Inactive to park an assignment without deleting it — the record stays for your access reviews, but nobody gets in through it. Once an application has crossed into being gated (see the callout above), an Inactive assignment really does stop working.

An assignment must name either a user or a group, and not both and not neither. Naming a person who is not a member of your organisation is refused — a check that closes a hole where any platform user identifier could be assigned across tenants.

Use groups, and know what that depends on

The advice to assign to groups rather than to people is right, and it comes with a dependency worth stating: an assignment to a group is only as good as the group's membership, and the membership lives on a different screen. Changing it is an administrative action — creating a group, deleting one, and adding or removing members all require the permission that gates group writes, held by default by admin- and owner-level roles, and an API key without the matching scope is refused. An earlier version of this article said group membership had no permission gate at all; that is no longer true. See Groups and automatic membership.

So an assignment to a group is a record whose subject can change without the assignment itself being touched, by anybody holding that permission. That does not make group assignment the wrong choice — it is still the right one operationally — but it means the group membership is the thing to review, not just the assignment.

If the group list is empty, the wizard tells you plainly: This organization has no groups yet. Create one under Identity → Groups first, or assign the app to one person for now.

Three states the screen will tell you about

This screen depends on being able to resolve names for people and groups, and it is unusually honest when it cannot:

• The list of people and groups could not be loaded, so the pickers above may be empty. Refresh the page before assigning anything. — do not assign against an empty picker.
• People and groups could not be loaded, so some rows below show an internal ID instead of a name. The assignments themselves are correct. — a display problem, not a data problem.
• The neighbouring App catalog screen flags an application with no redirect URI as Cannot sign in, with the row warning No redirect URI, so nobody can sign in to this application. That is a real misconfiguration and it is worth clearing before you assign anybody to it.

Using it for an access review

This is what the feature is for today, and it works.

1. 1

   Record what you believe is true

   One row per group per application. Remember that the first row you create for a previously-open app is the moment it becomes gated — everyone without an ACTIVE assignment loses access from then on, not just a documentation exercise.

2. 2

   Review the group memberships, not the assignments

   The assignment says Finance can open the payroll system. The question a review actually asks is who is in Finance, and that is where the answer changes month to month.

3. 3

   Park rather than delete

   Setting an assignment to Inactive keeps the history. An access review with no record of what used to be true is much less useful than one that shows a removal.

4. 4

   Verify a sample at the application

   This should now match what the record says — deactivating or removing an assignment on a gated app genuinely removes access. Pick two or three and confirm at the application itself anyway; a sample check is still good practice even now that the record and reality are the same thing.

Access reviews and certification covers the wider process. The removal confirmation on this screen — They lose single sign-on access to that app the next time they try to open it — is now accurate rather than aspirational, for any app that has at least one assignment row.

The neighbouring screens, so you pick the right one