> ## Documentation Index > Fetch the complete documentation index at: https://docs.cielara.ai/llms.txt > Use this file to discover all available pages before exploring further. # Authentication > Configure sign-in methods and set up Google or SAML single sign-on. > [!NOTE] > > This page is admin-only. Find this section within the sidebar under the Configuration group. Cielara supports three sign-in methods:
Method Description
**Email and password** The default. Users sign in with a password set during registration or invitation.
**Google** Single sign-on with a Google Workspace account, using OAuth.
**SAML** Single sign-on with any SAML 2.0 identity provider such as Okta, Microsoft Entra ID, OneLogin, or Keycloak.
Go to **Admin > Authentication** in the sidebar. The page shows a card for **Google** and a card for **SAML**, each labelled **Enabled** or **Not enabled**. Click a card to configure that method. > [!NOTE] > > Only one SSO method can be active at a time. If SAML is already enabled, the **Enable Google sign-in** toggle is greyed out until you disable SAML, and vice versa. ## Before you begin * Your deployment must be reachable over HTTPS. SAML sign-in is refused over plain HTTP. * Make sure at least one admin has a password set. Admins keep password sign-in as a fallback even while SSO is active, and this is the breakglass method to enter the environment in case the identity provider method fails. You are responsible to configure this for before you enable SSO. Cielara is not held responsible of being locked out. ## Set up Google SSO **1. Open the Google configuration page** Go to **Admin > Authentication** and click the **Google** card. **2. Copy the redirect URI** At the top of the page, the **Authorized redirect URI** box shows the exact value Google needs. Click the copy icon. The value must match byte for byte. Example: `https://your-cielara-domain/api/iam/oidc/google/callback`. **3. Configure the OAuth consent screen in Google** In the Google Cloud Console, open **APIs & Services > OAuth consent screen** and set **User type** to **Internal**. This restricts sign-in to your own organization. **4. Create an OAuth client** Still in the Google Cloud Console, go to **Credentials** and create an OAuth client of type **Web application**. Paste the redirect URI you copied into **Authorized redirect URIs**, then save. Google shows you a **Client ID** and a **Client secret**. Copy both. **5. Fill in the form in Cielara** Back on the Google page in Cielara: * **Client ID**: Copy and paste this from Google. Example: `xxxxxxxx.apps.googleusercontent.com`. * **Client Secret**: Copy and paste from Google. If a secret is already stored, leave this field blank. * **Workspace domain(s)**: Type a domain such as `example.com` and press Enter. Repeat for each domain. Only these Workspace domains can sign in. * **Allowed groups (optional)**: Google group email addresses such as `engineering@example.com`. When set, a user must belong to at least one of these groups. Leave empty to allow everyone in the domains above. **6. Enable and save** Turn on **Allow signup** if you want accounts created automatically on first sign-in, then turn on **Enable Google sign-in** and click **Save**. Pressing Enter does not save the form. You have to click **Save**. > [!WARNING] > > Personal Google accounts can never sign in, even if the email address is on an allowed domain. Cielara requires a Google Workspace account. > [!NOTE] > > Using **Allowed groups** requires the Cloud Identity API to be enabled on your Google Cloud project, and sign-in then requests a read-only groups scope. Membership through nested groups is only resolved on Workspace editions with Cloud Identity Premium; other editions match direct membership only. ## Set up SAML SSO **1. Open the SAML configuration page** Go to **Admin > Authentication** and click the **SAML** card. **2. Copy the service provider details** The panel at the top of the page shows two values with copy buttons: * **SP Entity ID**: `https://your-cielara-domain/api/iam/saml/metadata` * **ACS URL**: `https://your-cielara-domain/api/iam/saml/acs`, sometimes called the reply URL or assertion consumer service URL. **3. Create a SAML application in your identity provider** Create a SAML 2.0 app and register the SP Entity ID and ACS URL you just copied. Cielara accepts assertions on the HTTP-POST binding. Then collect from your IdP: the **entity ID**, the **SSO URL**, and the **signing certificate**. Alternatively, take the metadata URL or metadata XML file, which contain all three. **4. Fill in the form in Cielara** * **Display name**: a label for this provider, for example `Okta`. * **IdP metadata URL (optional)**: if you set this, any IdP field you leave blank below is filled in from the metadata when you save. The URL must be publicly reachable over HTTPS; for an internal-only IdP, upload the XML instead. * **Upload metadata XML**: an alternative to the URL. Uploading clears the four IdP fields below so the uploaded document wins. * **IdP Entity ID**: required. * **SSO URL**: required, and must be an HTTPS URL. * **Single Logout URL (optional)**: when set, signing out of Cielara also ends the IdP session. * **IdP signing certificate (X.509)**: required. Paste the PEM text or click **Upload certificate**. * **Email attribute (optional)**: the assertion attribute carrying the email address, if your IdP does not provide this field, use NameID. * **Allowed organizations (optional)**: comma- or space-separated organization names. A user must be in at least one. Quote values containing spaces or commas, for example `"CN=Engineering,OU=Groups"`. Leave empty to allow everyone. * **Organization attribute (optional)**: the assertion attribute carrying organizations, if your IdP doesn't send `org` or `organization`. **5. Enable and save** Turn on **Allow signup** if you want accounts created automatically on first sign-in, then turn on **Enable SAML sign-in** and click **Save**. > [!WARNING] > > Restricting by organization only works if your IdP actually sends a group or organization claim. Many send none by default, and a missing claim denies every sign-in. > > **Microsoft Entra ID**: in the enterprise app, go to **Single sign-on > Attributes & Claims**, add a **Groups** claim, and assign the group to the app. Set **Organization attribute** to the claim's full name (`http://schemas.microsoft.com/ws/2008/06/identity/claims/groups`), not the short "groups" label Entra displays. > > **Google Workspace**: in the SAML app, add a **Group membership** attribute under SAML attribute mapping, list the groups, and enter the same app attribute name as the **Organization attribute**. > [!WARNING] > > Changing the **IdP Entity ID** of a saved configuration unlinks every user from the old provider. They re-link on their next sign-in, but only if **Allow signup** is on. While off, changing the entity ID locks everyone out. > [!NOTE] > > An expired signing certificate saves without complaint but breaks every sign-in. If users start seeing a generic SSO failure, check the certificate expiry first. ## What changes for your users When an SSO method is active: * Users sign in by entering their email, clicking **Next**, and then **Continue with Google** or **Continue with SSO**. Accounts that can only use SSO skip straight to the identity provider. * Non-admins can no longer sign in with a password, even if they still have one. * Admins keep password sign-in as a fallback. * Password reset is unavailable for accounts that have only ever signed in through SSO. **Allow signup** controls provisioning and account linking together: * **On**: a user with no Cielara account gets one created on first sign-in, with the **User** role. An existing account whose email matches is linked to the SSO identity and keeps the password. * **Off**: only users who already have a linked SSO identity can sign in. Everyone else, including users who already have a Cielara account with a matching email, is refused with "No account exists for your email." ## Turning SSO off Turn off **Enable Google sign-in** or **Enable SAML sign-in** and click **Save**. SSO sign-in stops immediately and password sign-in is restored for everyone. Your configuration is kept, so you could get back in without re-entering anything. ## Troubleshooting sign-in errors
Message Cause
Your Google Workspace domain is not allowed for this organization. The account's domain isn't in **Workspace domain(s)**, or a personal Google account.
Your Google account is not in an allowed group. The user isn't in any group listed under **Allowed groups**.
Your account is not in an allowed organization. The SAML assertion carried no organization matching **Allowed organizations**, or carried none at all.
Your identity provider did not send an email address. Set **Email attribute** to the assertion attribute that carries the email.
Your identity provider response could not be verified. The assertion failed signature or audience validation, usually a certificate or SP Entity ID mismatch.
No account exists for your email. **Allow signup** is off and the user has no linked SSO identity.
Your account is inactive. The Cielara account has been deactivated. See [Users & Access](https://docs.cielara.ai/users-and-access.md).
Your sign-in session expired. The sign-in took longer than 10 minutes, or the link was already used. Try again.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.