Setup
In the console → Identity → SSO open the setup wizard: choose a display name, sign-in slug and sign-in methods. Your issuer is https://whycloud.ir/sso/<slug>; the overview lists every endpoint (discovery, authorize, token, userinfo, JWKS) with copy buttons.
Add an app
Under Apps click “New app” and pick the type: web (with a client secret), SPA or mobile (PKCE, no secret) or machine (client credentials). Enter exact redirect URIs and, optionally, allowed groups. The client secret is shown once; store it in the app’s secrets and rotate it from the app page if it leaks.
Users and groups
In Directory create or invite users, assign groups and disable when needed. Groups are emitted in the groups claim of the ID token so apps such as Grafana can map roles. WhyCloud console members can sign in without a separate user.
Google, Microsoft or any OIDC
Under Directory → Identity providers add an IdP: the provider’s issuer, client ID and secret and, optionally, an email-domain restriction. Register the displayed callback URL with the provider. Users are linked by verified email, and created automatically when auto-create is on.
Sync with Active Directory, LDAP and Keycloak
Under SSO users → Directory sync click “Connect a directory” and choose the type. For AD and LDAP give the server address (preferably ldaps://dc1.acme.local:636), a read-only service account and the base DN; the user filter and attribute mapping have sensible defaults (AD: sAMAccountName, mail, displayName, memberOf). For Keycloak create a confidential client with a service account and the view-users role. The Test step reads the directory without changing anything and shows sample users. Then set the schedule (15 minutes to daily), what happens to users no longer in the source (disable or delete) and whether passwords are checked at the source — then people sign in with their usual company password and no password is stored in WhyCloud. If a source suddenly returns no users, the sync is skipped so nobody is disabled by mistake.
Adding and removing users
Under SSO users create a user with “User” (the temporary password is shown once and changed at first sign-in) or import up to 2000 users with “CSV import” (columns username, email, name, groups). Click a user to change groups, mobile and status, issue a new temporary password, sign them out everywhere, disable or delete. Change synced users in the directory itself. WhyCloud console members are invited or removed under Members & access (IAM).
Two-step sign-in for every user
In the SSO settings set the policy to optional or required for everyone; it applies to manual users, users synced from AD/LDAP/Keycloak and people who sign in with Google or Microsoft. At the first sign-in the user scans a QR code with Google Authenticator, Microsoft Authenticator or any TOTP app. With SMS codes on, users with a mobile number can get a 5-digit code by SMS instead. You can also require two-step sign-in for a single user and reset it when a phone is lost.
Dedicated SSO server (on-premise)
Under SSO servers follow the wizard: pick a connected server, domain and version. SSO runs with its own PostgreSQL on your server with Docker and sign-ins happen entirely there. A switcher at the top of the SSO pages moves between cloud and each server; apps, users and IdPs are separate per deployment.
Backups, upgrades and billing
SSO servers have scheduled backups and restore; upgrades take a snapshot first and roll back automatically if the service does not come up healthy. Cloud SSO bills users who signed in during the last 30 days (hourly); dedicated servers bill per hour.