An overview of single sign-on integration with Arpio
Arpio's single sign-on feature lets you use external identity providers to authenticate your users, so they don't have to use separate email and password credentials to login to Arpio. You can use identity provider services hosted in the cloud, like Okta, Azure Active Directory, and Google Workspace. You can also use identity providers hosted in your own organization's networks, including in private datacenters.
When you configure an external identity provider, Arpio acts as one of its service providers.
Your identity provider handles user authentication, enforcing your organization's policies for things like multi-factor authentication (MFA) and session duration, and passes a cryptographically signed message about the authentication result to the Arpio service. Arpio checks that the message's signature is valid, that it comes from a trusted identity provider, and that the authentication succeeded, before allowing the user to access Arpio resources. When the user's authenticated session expires, the user is redirected back to the identity provider to re-authenticate.
Supported Identity Providers
Arpio supports SAML 2.0 identity providers. There are many identity provider implementations, but it's easy to configure most of them to send the response attributes Arpio needs. Arpio's support team can work with you to get your identity provider configured correctly.
Adding Identity Providers
You can add identity providers in the Arpio console. You'll need the provider's SAML 2.0 metadata before you begin. See our article about adding SAML 2.0 identity providers for instructions.
After you add an identity provider, you can start inviting users from your organization to access your Arpio account. Arpio uses email addresses to identify single sign-on users, so make sure to invite users with the email address that matches the value the identity provider sends to Arpio.
Removing Identity Providers
You can remove identity providers in the Arpio console. When you remove an identity provider, all active sessions for that provider are immediately invalidated. Users who had previously authenticated with the provider that was removed must authenticate again to use Arpio.
Arpio supports both service provider-initiated and identity provider-initiated authentication flows. You don't have to configure anything in Arpio to support these flows, they work for all identity providers.
An identity provider-initiated flow is when a user logs into the identity provider (like Okta) first, and then clicks a button or link configured to take them to a specific Arpio console URL. Since the user authenticated to the identity provider in the first step, Arpio receives the signed authentication result when the link is clicked and grants the user access to the appropriate resources without requiring additional information, completing the flow.
You can configure your identity provider's button or link to take users to any Arpio URL you choose. You can use the URL of one of your Arpio applications, one of your Arpio accounts, or the root URL of the Arpio console. When an authenticated user accesses the console root URL, Arpio automatically redirects the user to their Arpio account if they are associated with only one account, or displays a list of accounts if they have access to more than one.
A service provider-initiated flow starts when a user accesses the Arpio console directly, using a web browser bookmark or by typing in the URL, and the Arpio service detects that the user is unauthenticated. Arpio examines the requested URL to determine which Arpio account is associated with the protected resource, and when that account has a configured identity provider, redirects the user to that identity provider. After the user finishes authenticating, the identity provider redirects them back to the protected resource they originally requested, and the flow is complete.
Using many Identity Providers with one Arpio Account
You can configure one Arpio account to have multiple identity providers. If you do this, identity provider-initiated authentication flows are preferred. If you use service provider-initiated authentication flows instead, Arpio chooses the first external identity provider (sorted alphabetically) when an unauthenticated user attempts to access a protected resource.
Using one Identity Provider with many Arpio Accounts
You can configure the same identity provider with many Arpio accounts. When you do this, both authentication flows work equally well.
When Arpio receives a valid signed authentication response message from an identity provider, it looks at all the Arpio accounts configured to use that identity provider, and grants access to a protected resource only if the resource's associated account contains a verified user whose identity provider and email address matches the subject identifier in the authentication response.
When a user has been granted access to multiple Arpio accounts through one identity provider, an account chooser is shown when the user visits the root URL of the Arpio console.
Using many Identity Providers with many Arpio Accounts
You can configure the same identity provider with many Arpio accounts, and also configure additional identity providers in some or all of those accounts. For the accounts with multiple identity providers, identity provider-initiated flows are preferred for the reason in the section above.
Disabling Email and Password (Native) Authentication
After you enable single sign-on, your existing Arpio users can still authenticate directly to the Arpio service using their email address and password. If you want to disable native (email and password) authentication after configuring single sign-on, contact Arpio support.