User authentication via local accounts

By default, when a user signs up on Astry (whether following an invitation to join an Organization or through a new sign-up without invitation), a so-called local account is created. This simply means that the information needed to log in is managed by our systems (however, passwords are never stored on our systems — see the Data Protection section).

User authentication via Enterprise SSO

Owners of an Organization also have the option to connect Astry to their company's SSO (Single Sign-On) (provided they have a publicly accessible SSO that supports the standard SAML v2 or OIDC (OpenID Connect) protocols). In this case, when users try to log in to their Astry account, they are redirected to the company's SSO (the information needed to log in is then, by design, never stored on Astry's systems).

This system allows, among other things:

offering users unique accounts (or credentials) across a set of services
fine-grained configuration of password administration rules (length, characters, rotations, ...)
configuring MFA (Multi-Factor Authentication) directly on the company's SSO

Configuring SSO

SSO is configured from the main Organization tab, then Authentication:

Choose an endpoint name, unique across all Astry organizations (for example the name of your organization; the _ and space characters are not allowed).
Configure your identity provider, then import its SAML v2 metadata file (in XML format) into Astry.
Astry then gives you a login URL, to share with the members of your organization. They can also sign in from the Astry login page, using Connect through SSO, by entering the endpoint name.

Step-by-step guides are built into the page for the most common identity providers: ADFS, Keycloak and Microsoft Office 365 / Entra ID. In particular, they give the values to enter on the identity provider side (Astry's identifier and reply URL, as the service provider).

Once SSO is configured, Owners can invite users to join the organization, specifying that they will authenticate through SSO (see Users and profiles).

Note: SSO does not provision accounts automatically: users must first be invited to join the organization. Likewise, it does not manage users' roles and permissions, which remain administered in Astry.

Protecting service calls via API keys

The integrations we offer for triggering incidents rely on an API key mechanism. Specifically, an API key must be created via the Astry tool (only Owners of an Organization can perform this action), and is then used by integrations to communicate with Astry.

These API keys take the form of a pseudo-random string of characters, and are specific to each integration type. You can have up to 5 different API keys per integration type, allowing you to isolate functional or technical scopes if you wish.

Note: If an API key is compromised, you can rotate keys without service interruption (by using your set of 5 keys to generate a new one, then decommissioning the compromised key afterward).