Skip to main content
This page is admin-only. Find this section within the sidebar under the Configuration group.
Cielara supports three sign-in methods:
MethodDescription
Email and passwordThe default. Users sign in with a password set during registration or invitation.
GoogleSingle sign-on with a Google Workspace account, using OAuth.
SAMLSingle 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.
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.
Personal Google accounts can never sign in, even if the email address is on an allowed domain. Cielara requires a Google Workspace account.
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.
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.
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.
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

MessageCause
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.
Your sign-in session expired.The sign-in took longer than 10 minutes, or the link was already used. Try again.