Control SSO access with group rules

With single sign-on (SSO), your colleagues sign in to URIports with their company account. Each colleague who signs in gets their own team member entry in your URIports team. Group rules decide what each of them can do, based on the groups or app roles they have in your identity provider, such as Microsoft Entra ID or Okta.

How group rules work

Every SSO connection has default permissions: the domains (or domain groups) that everyone who signs in through the connection can see.

A group rule adds permissions on top of those defaults for colleagues in a specific group or app role in your identity provider. A rule can give:

• Administrator rights (full access, including managing the team)
• Access to all domains, optionally with permission to manage ignore and block rules
• Access to one or more URIports domain groups (read-only)

A colleague gets the default permissions plus the rights of every rule that matches one of their groups. For example, with default permissions Domain group "Public" and these rules:

• A colleague in uriports-admins is an administrator.
• A colleague in marketing sees "Public" and "Brands".
• A colleague in neither group sees "Public".

Group rules are additive, not restrictive. A colleague in several groups gets the combined permissions of all matching rules. A rule never takes away what another rule or the default permissions give: membership of an administrator group makes someone an administrator, whatever their other groups are.

You can also choose to refuse sign-in for colleagues who match no rule.

Recommended setup: keep the default permissions to the minimum everyone needs, use dedicated groups in your identity provider for additional access, and give administrator rights only to a small, deliberately managed group.

When changes take effect

• Changes in URIports (group rules, default permissions) apply straight away, also to colleagues who are signed in at that moment.
• Changes in your identity provider (adding someone to a group or removing them) reach URIports the next time the colleague signs in, because the groups are sent with each sign-in.
• To remove someone's access immediately, set them to inactive in Settings > Team Access > Members. This ends their session at once.

Before you add a rule: send groups to URIports

Group rules only work if your identity provider includes the groups (or app roles) in the sign-in. Most identity providers don't do this by default.

Microsoft Entra ID

• Groups: App registrations > your URIports app > Token configuration > Add groups claim > Security groups, and choose Group ID for the ID token. Entra sends the object ID of each group, so use the object ID in your rule (you'll find it on the group's overview page).
• App roles (often easier): App registrations > your URIports app > App roles > Create app role (for example the value URIports.Admin), then assign it under Enterprise applications > your URIports app > Users and groups. Use the role's value in your rule.
• If a colleague is a member of more than 200 groups, Entra doesn't send the group list. Use app roles, or Groups assigned to the application (requires Entra ID P1), to avoid this. With Groups assigned to the application, only direct members of the assigned groups are included, not members of nested groups.

Okta

• Applications > your URIports app > Sign On > Token claims, then either:
  • Show legacy configuration > groups claim filter: name groups, Matches regex, .*, or
  • Add expression with the name roles (Okta reserves the name groups here) and the expression user.getGroups({'group.type': {'OKTA_GROUP', 'APP_GROUP'}}).![profile.name]
• Okta sends group names, so use the group name in your rule.

Google Workspace

With OpenID Connect, which URIports uses, Google doesn't send group membership. With Google, everyone gets the default permissions; use allowed email domains to limit who can sign in.

Other identity providers

Make sure the ID token contains a groups or roles claim with the group names or IDs. Check your identity provider's documentation for "groups claim".

Create a domain group

To give a rule access to only some of your domains, put those domains in a domain group first:

1. In URIports, go to Settings and find Domain groups.
2. Click Add group and enter a name, for example "Brands".
3. Select the domains that belong in the group (use the search box if you monitor many domains).
4. Save the group.

The group is now available in your group rules and in the connection's default permissions. Domain groups also let you filter all reports by a subset of your domains.

When you add or remove domains in a domain group later, the change applies straight away to everyone who has access through that group.

Add a group rule

1. In URIports, go to Settings > Team Access > Single sign-on and open the connection.
2. Under Group rules, click Add rule and enter the group or app role exactly as your identity provider sends it.
3. Choose the rights: Administrator, All domains (and Manage rules), or one or more domain groups.
4. Use Test the rules: enter the groups of a colleague to see what they would get.
5. Click Save changes. The rules apply straight away.

If your connection makes everyone an administrator

Some connections have the older setting Everyone is administrator. It stays as it is until you add a group rule: as soon as a connection has a group rule, it no longer makes everyone an administrator. So first make sure your identity provider sends the group (see above), and add a rule that gives administrator rights to the colleagues who need them.

As the account owner you always keep administrator rights, also when you add group rules.

Exceptions for one colleague

Open the colleague in Settings > Team Access > Members and choose Set individually to give them their own permissions. Group rules and the connection's default permissions then no longer apply to that colleague, and changes to their groups in your identity provider no longer update their URIports permissions. Use this sparingly: it's an exception to your centrally managed access.

Recommended security practices

1. Least privilege: keep the default permissions minimal and grant extra access with group rules.
2. A dedicated administrator group: give administrator rights only through a group (or app role) used for nothing else.
3. Prefer app roles where your identity provider supports them: they separate URIports permissions from your general groups.
4. Assign the URIports app in your identity provider only to the people who need it.
5. Review regularly who is in the groups that grant access, especially after role changes and departures.
6. Test the rules before you save them.
7. Protect the account owner with two-factor authentication or a passkey: the account owner always keeps administrator rights.