Users can sign into Avallone using Single Sign-On.
How SSO works in Avallone
Single Sign-On lets your team access Avallone using your organization's existing identity provider (IdP) — for example Microsoft Entra ID (Azure AD), Okta, Google Workspace, and other SAML 2.0-compatible identity providers. Instead of managing a separate Avallone password, users sign in with the same corporate credentials they already use across other tools.
Avallone's SSO is built on SAML 2.0, an industry-standard protocol supported by all major identity providers.
Avallone acts as the Service Provider (SP), while your identity provider acts as the Identity Provider (IdP).
How signing in works
1. A user opens the Avallone sign-in page dedicated for your organization.
2. They choose to sign in via your company's identity provider.
3. They are redirected to your IdP, where your security policies apply — including MFA if enabled.
4. Once the IdP confirms the user's identity, they are redirected back to Avallone and signed in.
Avallone does not store your IdP password. Authentication happens entirely within your IdP; Avallone simply validates the confirmation it receives over SAML.
What administrators can control
- Connect your identity provider by supplying its SAML metadata.
- Require SSO for all users, disabling username-and-password login so access always goes through your IdP.
- Force re-authentication when needed, so users must actively confirm their identity rather than relying on an existing session.
- Run multiple IdP connections and enable, disable, or update them independently.
Authentication vs. Authorization
SSO is responsible for authentication — confirming who a user is. Authorization (what a user can access inside Avallone) is controlled separately through Avallone's role- and group-based access control model.
Permissions are assigned through roles and access groups within the platform. These assignments determine which modules, data, and administrative functions a user can access.
There is no automatic role mapping between your identity provider and Avallone (for example via SAML attributes). Permission assignments are managed inside the platform, keeping access control consistent and independent of your identity provider configuration.
User provisioning
Before a user can sign in via SSO, they must first be created in Avallone by an administrator or someone with User Management access.
Avallone can support automated user provisioning via SCIM, but it may not be enabled by default for all tenants.
If you are evaluating automated lifecycle management (create, update, deactivate) and would like SCIM provisioning enabled for your tenant, contact Avallone support to confirm availability and rollout status.
Avallone does not support SAML-based role mapping. Once a user exists in Avallone, they can authenticate using SSO and will receive the permissions assigned to them within Avallone.
Security
- Transport security: Avallone's SSO endpoints are served over HTTPS (TLS).
- Assertion security: Avallone validates SAML responses using your IdP's signing certificate to help protect against tampering.
- Access control: Because authentication happens in your IdP, your organization's access policies (such as MFA and sign-in restrictions) remain enforced by the IdP.
Configuring SSO (tenant setup)
This article focuses on how SSO works and the related security model. For step-by-step setup instructions (including required SAML values like Entity ID / ACS URL and IdP metadata), follow the SSO configuration guide.