Enabling SSO for portal users

This page explains how to enable single sign-on (SSO) so your employees can access Anghello with their corporate directory credentials.

Audience: Administrators
Application: Admin (app.anghello.co)
Estimated time: 5 minutes

In short

• Protocol: OpenID Connect (OIDC) via Microsoft Entra ID (formerly Azure Active Directory).
• Scope: SSO applies to Anghello portal user accounts, created by invitation with a role and a scope (site or organization). Permissions remain managed in Anghello.
• Enabling it: in most cases, no action is required — your invited employees sign in directly via the SSO button. If your tenant's consent policy is restricted ("Need admin approval" message), a single consent action by an administrator is enough, once for the whole organization.

Prerequisites

• The employees concerned must have an email address on your organization's domain and have been invited from Anghello.
• Only if your tenant requires approval: a role allowing organization-wide consent — Global Administrator or Cloud Application Administrator.

In most cases: nothing to do

Anghello SSO works with no prior setup: your invited employees click "Sign in with Microsoft", authenticate with their corporate credentials, and access Anghello.

If your tenant requires approval: grant consent (once)

If your employees instead see a "Need admin approval" message when signing in, your tenant's consent policy requires validation by an administrator. A single action lifts it for the whole organization, using either of the two equivalent methods below.

Shortcut: if the person signing in to Anghello holds an eligible administrator role themselves, the permissions screen directly offers the "Consent on behalf of your organization" checkbox. Ticking it before accepting has the same effect as the two methods below, for the whole organization.

Method A: from the Entra portal (recommended)

1. Sign in to the Microsoft Entra portal as a Global Administrator.
2. Go to Applications → Enterprise applications.
3. Search for Anghello in the list.
4. Open the application, then the Permissions menu.
5. Click "Grant admin consent for [your organization]".
6. Review the requested permissions (see below), then confirm.

The Anghello application appears in your Enterprise applications as soon as one of your employees has attempted to sign in once. If it doesn't appear yet, use Method B below: granting consent will automatically create the application in your tenant.

Method B: via the consent link

Open the following link while signed in as a Global Administrator, review the permissions, and accept: https://login.microsoftonline.com/organizations/adminconsent?client_id=53a260b7-14dc-4508-9815-0f95bb387600

That's it: all your employees can now sign in via the SSO button, with no approval message.

Permissions requested by Anghello

Anghello is a Microsoft verified publisher, and the requested permissions are deliberately kept to the minimum. For transparency, here they are:

Anghello does not request access to your emails or files, nor any write permission on your directory.

After enabling SSO

• User accounts are created by invitation from Anghello: your Anghello administrators invite each employee, assigning a role and a scope (one site, or the whole organization). No account is ever created spontaneously at sign-in: only explicitly invited employees have access.
• The invited employee activates their account at first sign-in via the "Sign in with SSO" button, using their corporate credentials.
• Permissions and access profiles are assigned in Anghello, independently of your directory.
• Your Anghello administrators can enforce SSO from the invitation onwards: in the "Invite a user" form, the "Allowed authentication methods" field lets you select only "Azure SSO (Microsoft)". The account will then never be able to sign in with a password: all authentication goes through your directory — the condition for your MFA and deprovisioning to genuinely apply, with no way around them.

What SSO gives you

Signing in through Entra ID gives you your directory's security guarantees, with no extra configuration:

• Centralized deprovisioning: when an employee is disabled in your directory, they can no longer sign in to Anghello. Access lifecycle stays managed from your Entra ID. Active sessions simply expire at their normal end.
• No Anghello-specific password: authentication is fully delegated to your directory. No Anghello-specific credentials or passwords are created or stored — the password attack surface disappears.
• Inherited MFA and Conditional Access: your Entra multi-factor authentication and Conditional Access policies automatically apply to Anghello sign-ins. Nothing more to configure.

Control and revocation

• You stay in control: you can revoke Anghello's access at any time from Enterprise applications, without contacting us.
• No app registration or secret sharing is required on your side.

Why OpenID Connect, and not SAML 2.0?

Anghello relies on OpenID Connect (OIDC), the modern identity federation standard. Given Anghello's model and scale, it covers all the security needs of an SSO integration:

• Roles and permissions are managed in Anghello, assigned when each user is invited (role + site or organization scope) — not derived from your directory. SAML's main added value — mapping IdP groups or attributes to application roles — is therefore not needed.
• The number of accounts per site is small (a few users per site). The heavyweight automated provisioning often associated with SAML (group sync, SCIM) would bring no benefit at this scale.
• OIDC already provides the same guarantees as SAML for this scope: federated authentication, centralized deprovisioning, and the inherited MFA and Conditional Access described above.

SAML 2.0 is therefore neither required nor offered today. If your context demands it — for example a third-party identity provider that only supports SAML, or a specific IAM policy requirement — contact us and we'll assess your need.

Frequently asked questions

An employee sees a "Need admin approval" message.
Your tenant's consent policy requires validation by an administrator. An eligible administrator simply needs to perform the consent action described above (Method A or B), once, to clear the message for all users.

What happens if we disable an account in Entra?
The employee will no longer be able to sign in to Anghello: since authentication is delegated to your directory, the deactivation takes effect at their next sign-in attempt. An already-open session expires at its normal end.

We already have Anghello accounts with passwords. Can they switch to SSO?
Yes, with no manual steps: at the first SSO sign-in, the existing account is automatically matched by its email address. The employee keeps their account, permissions, and history. To then guarantee that authentication goes exclusively through your directory, your Anghello administrator can enforce SSO on those accounts.

Can we restrict which employees have access?
Yes — through the enterprise application's user assignment in Entra, and through permission management on the Anghello side.

Updated on: 27/07/2026