> For the complete documentation index, see [llms.txt](https://boza.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boza.gitbook.io/docs/getting-started/whitelist-boza.md).

# Whitelist Boza in your IdP

Allow your organization to sign in to Boza and grant the permissions required for the Google Workspace or Microsoft Entra ID integration.

{% hint style="warning" %}
Authorization can grant directory write access. Review the requested permissions and Boza's supported write workflows before approving the application for the organization.
{% endhint %}

## Choose the Right Authorization

| Goal                                          | Where to start                                                                                 |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Let users sign in to Boza                     | Allow the Boza OAuth application under your provider's third-party application policy          |
| Synchronize directory and activity data       | Open **Integrations** in Boza and connect the identity provider with an approved administrator |
| Run onboarding and offboarding                | Grant the directory write permissions shown during the connection                              |
| Deploy the extension through Google Workspace | Also grant the Chrome policy permissions requested by the guided deployment                    |

## Microsoft Entra ID

Boza's Microsoft Application (client) ID is:

```
6479d12c-ed32-40c3-a959-c57bfdc118d0
```

Do not create a separate non-gallery application with this ID. Authorizing Boza creates or updates the enterprise application—service principal—for Boza's existing multitenant application in your tenant.

### Preferred: Authorize from Boza

1. Sign in to Boza as a workspace Admin.
2. Open **Integrations** and select **Microsoft Entra ID**. In a demo workspace, you can instead start **Connect my environment**.
3. Click **Connect** or **Authorize**.
4. Sign in with a Microsoft administrator account permitted to grant the requested consent.
5. Review the publisher, application ID, tenant, and permissions.
6. Approve consent for the organization only if the details match your internal approval.
7. Return to Boza and confirm that the connector shows as active.

Review [Microsoft Entra ID Scopes & Permissions](/docs/settings-and-security/entra-id-scopes.md) before approval.

### If Your Tenant Uses Admin Consent Requests

When user consent is restricted, the person starting the connection may see **Need admin approval**.

1. Submit the request from the Microsoft consent screen, if your tenant enables requests.
2. In the Microsoft Entra admin center, open **Entra ID → Enterprise apps → Admin consent requests**.
3. Open the Boza request.
4. Confirm that the application ID matches the value above.
5. Select **Review permissions and consent**.
6. Approve, deny, or block the request according to your organization's policy.

Microsoft documents this process in [Review and take action on admin consent requests](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/review-admin-consent-requests).

### Verify Microsoft Authorization

1. In the Entra admin center, open **Entra ID → Enterprise apps → All applications**.
2. Find the enterprise application and verify its Application ID.
3. Open **Security → Permissions** and review the Admin consent entries.
4. Test **Sign in with Microsoft** at [app.getboza.io](https://app.getboza.io).
5. In Boza, compare a known user and organization group after synchronization starts.

If your tenant requires user assignment for enterprise applications, assign only the approved users or groups and test with a member of that scope.

Microsoft's current portal procedure is documented in [Grant tenant-wide admin consent to an application](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent).

### Microsoft Troubleshooting

**Need admin approval appears repeatedly.** Confirm that consent was granted to the enterprise application with the matching Application ID and that no Conditional Access or assignment policy blocks the test user.

**The application is not listed yet.** Start the Boza authorization with an administrator. The service principal is normally created when the application is consented in the tenant.

**Users can sign in but synchronization fails.** Sign-in approval and integration permissions are related but not identical. Reopen **Integrations → Microsoft Entra ID** and review the full requested scope set.

## Google Workspace

Boza's Google OAuth client ID is:

```
262718834558-u6kn7e5emcn7a7qp33ejt81k0ldngftq.apps.googleusercontent.com
```

Configure Boza in Google App access control when your organization restricts unconfigured third-party applications or Google services.

### Configure App Access

1. Sign in to the [Google Admin console](https://admin.google.com) with an account that has the required Security settings privilege.
2. Open **Security → Access and data control → API controls**.
3. Click **Manage Third-Party App Access**.
4. Under configured apps, click **Configure new app**.
5. Search for the OAuth client ID above.
6. Select the matching Boza application.
7. Choose the organizational units that are allowed to use Boza.
8. Choose the data-access level approved by your security team.
9. Review the application, scope, and access setting, then finish the configuration.

Google describes the available levels—**Trusted**, **Limited**, **Specific Google data**, and **Blocked**—in [Control which third-party and internal apps access Google Workspace data](https://knowledge.workspace.google.com/admin/apps/control-which-third-party-and-internal-apps-access-google-workspace-data).

{% hint style="warning" %}
**Trusted** allows the application to request access across Google Workspace services, including restricted services. Use the narrowest access level that supports the Boza workflows you approved, and do not select Trusted merely to bypass an unexplained authorization error.
{% endhint %}

### Connect and Verify Google Workspace

1. In Boza, open **Integrations → Google Workspace**.
2. Start the connection with an approved Google Workspace administrator.
3. Review the requested directory, audit, group, data-transfer, and Chrome policy permissions.
4. Return to Google **Manage Third-Party App Access** and confirm the configured access applies to the intended organizational units.
5. Test **Sign in with Google** at [app.getboza.io](https://app.getboza.io).
6. Compare a known user and organizational unit after synchronization starts.

See [Google Workspace](/docs/integrations/google-workspace.md) for the read and write behavior associated with those permissions.

### Google Troubleshooting

**Google reports `admin_policy_enforced`.** Confirm that the exact client ID is configured for the user's organizational unit and that the access level covers every Google service needed by the approved Boza workflow.

**Sign-in works but the integration is not connected.** Basic Google sign-in does not prove that an administrator granted the directory and audit permissions. Complete the connection from **Integrations**.

**A user remains blocked.** Check inherited settings on the user's organizational unit and whether a more specific **Blocked** rule overrides the top-level configuration.

## Review and Removal

Periodically review the enterprise application or configured Google app, its permissions, and the users in scope.

Disconnecting the connector in Boza stops future supported synchronization and provider actions, but it does not automatically:

* Revoke provider consent.
* Reverse users, groups, or policies already created or changed.
* Remove the enterprise application or Google app-access rule.
* Delete data already synchronized into Boza.

Coordinate revocation with your identity and security administrators so active workflows and extension deployment are not interrupted unexpectedly.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://boza.gitbook.io/docs/getting-started/whitelist-boza.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.