Authentication

We currently support three ways to authenticate your users. We implement our IAM through a well-respected party: Ory.

1. Social sign-in

The easy and safe way to enter our systems: We currently support one-click onboarding with Microsoft and GitHub accounts. We require you to validate your email address to ensure we can actively inform you of any security concerns. We validate your email address by requiring you to click a confirmation link sent to your inbox during the onboarding process.

Pros:

  • Very easy to start: one click.
  • You don’t need a password: you rely on an existing account from respected parties like Microsoft, GitHub.

Cons:

  • You need an account with either Microsoft or GitHub.
  • Coupling your work account could be blocked by your IT department. Contact them to request whitelisting of our OIDC application or Enterprise SSO (see 2).
  • The less restrictive nature of social sign-in can potentially lead to security challenges:
    • To mitigate risks with trusting email claims we always verify the email address at onboarding.
    • Users may find ways to couple their identity to private accounts, which makes it harder to automatically block them when they leave your company: please have a company process to update your user-management when people are joining or leaving.

2. Enterprise SSO

Bigger companies often want a direct integration with their own identity provider (IdP): we support this option through OIDC. We use the well-respected Ory B2B implementation. We can identify users belonging to your organization based on their email domain (e.g., @yourcompany.com) and direct them to your identity provider.

Contact our sales or support team to discuss the way forward. If your Identity Provider is Microsoft Entra then we already have a technical document that describe the things that we need to help you.

Pros:

  • Only allow users that authenticate through an identity provider which is controlled by your organization. (e.g., your own Azure Entra ID, Google Workspace, etc.). This blocks other ways to authenticate, which is often desired by bigger companies.
  • Users leaving your company automatically can’t log in to Viya anymore.
  • We only allow your specific identity provider: other means are not accepted.
  • Future: authorization can be configured through claim mappings. Placing a user in a group in your identity provider will give certain rights in Viya.

Cons:

  • Your IT department needs to perform some configuration (it’s not hard!).
  • Your users require an email address that ends with one (or more) non-generic domains (e.g., all users must have an email address ending in @yourcompany.com).

3. Password

If the other methods are not suitable, you can configure a username and password. Your username is your email address, we always require you to validate the email address.

Pros:

  • Simple to understand and set up for individual users.
  • No involvement of your IT department.
  • No SSO domain provider needed.

Cons:

  • It’s an older mechanism that is generally not the safest way due to risks like weak passwords, password reuse, and phishing.
  • You need to remember your password.
  • You must have a company process to update your user-management when people are joining or leaving (otherwise they will keep their access).