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
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).