Setting up single sign-on from the catalogue
The Set up button on a catalogue capability makes Qorionix the identity provider for another product. What the short form asks, what you must paste back, and where OIDC stops.
You want your staff to sign in to some other product — Slack, Zoom, Atlassian, Zendesk — with the Qorionix account they already have, so that suspending somebody here suspends them everywhere. You opened the integration catalogue, found the vendor, and then found a screen that talks about connectors and credentials, which is not what you were looking for. This article is about the button you actually wanted, which says Set up rather than Configure, and about the one thing it will not finish for you.
Before anything else, one distinction, because getting it the wrong way round is the most common reason people end up on the wrong screen entirely. Single sign-on has a direction.
- Outbound — this article
- Qorionix is the identity provider. Another product trusts us to say who somebody is. Your people click Sign in with Qorionix over there. This is what the catalogue's Set up button does.
- Inbound — not this article
- Somebody else's identity provider — your Microsoft Entra tenant, your Google Workspace — is trusted to say who somebody is, and your people sign in to Qorionix through it. That is a different set of screens under Identity, and Which single sign-on screen to use untangles them.
Finding the button
Open Integrations, find the vendor, and open its entry. In the panel headed What you can set up you will see one row per capability. The one you want is named after the protocol: SAML single sign-on or OIDC single sign-on. That row, and only that row, carries a Set up button.
It matters that the button is on the capability and not on the entry. A row like Slack offers three quite different things — sign-on, notifications and account provisioning — and they are in three different states. A single button at the bottom of the entry would have to guess which one you meant, and for a long time it guessed wrong: it opened the notification connector's bot-token form underneath a card advertising SAML sign-on. There is no entry-level button any more, on purpose.
Twenty-one applications ship with a template. Seventeen of them offer SAML — Atlassian Cloud, AWS IAM Identity Center, Box, Datadog, Dropbox Business, GitHub Enterprise Cloud, GitLab SaaS, Google Workspace, MongoDB Atlas, Nextcloud, Notion, Personio, Salesforce, Slack, Zendesk, Zoom, and a generic row for anything else that speaks SAML 2.0. Four offer OIDC: Cloudflare Zero Trust, Grafana Cloud, Nextcloud again, and a generic row. Nextcloud is the only application in both lists.
Why the form asks for so little
If you have set up SAML by hand before, you are braced for a long form: entity IDs, an assertion consumer URL, a subject format, an attribute statement, a digest algorithm, an assertion lifetime. This form asks for one or two things and then stops. Slack asks for your workspace subdomain. Cloudflare asks for your team name. Box and Dropbox Business ask for nothing at all.
That is deliberate, and the screen says so in its own words:
Qorionix becomes the identity provider for this application. Everything the protocol needs is already in the template — you only supply the values that identify your own tenant.
A template here is a small authored file, one per application, recording how that specific vendor wants to be talked to. It is validated when the platform starts, so a template that is wrong fails on our side rather than in your production sign-in. Splitting the work this way leaves you only the questions nobody could have answered in advance.
| Value | Who provides it | Why |
|---|---|---|
| Assertion consumer URL | The template, built from your answer | Slack's is always https://<your-workspace>.slack.com/sso/saml. Asking you to type it invites a typo in the one field that decides where signed assertions are sent. |
| Audience / SP entity ID | The template | Fixed per vendor. Slack's is literally https://slack.com for every customer in the world. |
| Subject format and attributes | The template | Slack keys accounts on a persistent identifier rather than an email address, so that renaming somebody does not orphan their account. Getting this wrong is discovered on the day somebody changes their surname. |
| Signature and assertion lifetime | The template | SHA-256 and five minutes. Not a per-tenant decision, and not one we want typed into a box. |
| Your workspace, team or tenant name | You | The only thing that genuinely differs between two customers of the same product. |
| The name it appears under | You | Defaults to the vendor's name. Change it if you have two of something. |
The form shows what it is going to send, under What the token carries, with the note Set by the template to match what this application expects. It is not editable here. If the attribute list there does not match what the application's own documentation asks for, stop and raise it with support rather than working around it — a template mismatch is our defect, not yours.
Doing it
Fill in the one or two values, then press Preview
Preview resolves the template on the server and shows the exact assertion consumer URL and audience that would be created. Nothing is saved and no signed assertion exists yet — the panel says Nothing has been saved. This is what would be created. Read the URL. If your subdomain has a typo in it, this is where you find out, rather than at the first failed sign-in.
Press Create application
This writes the application, resolves the template one final time, stores the resolved values rather than recomputing them at each login, and — for SAML — makes sure your organisation has a signing certificate before the first login rather than during it. Storing the resolved values is a safety property, not an optimisation: a later edit to a template cannot silently repoint a live application's assertion consumer URL.
Paste the values into the other product
The form does not close with a tick. It ends on a panel of values with copy buttons beside them, because an application nobody finished configuring on the far side is a sign-in that fails at the worst possible moment.
The four values you have to carry across
Qorionix is ready to issue assertions. Sign-in will not work until you paste these values into the application's own admin console.
| Label on screen | What it is |
|---|---|
| Sign-on URL (IdP) | Where the application sends its authentication requests. Most vendor consoles call this field Sign-in URL, IdP SSO URL or Identity provider single sign-on URL. |
| Issuer / Entity ID (IdP) | The name Qorionix goes by inside the assertion. Usually labelled Issuer, IdP entity ID or Identity provider issuer on the other side. |
| Metadata URL | One URL containing the other two plus the signing certificate. If the application accepts a metadata URL, use it — it is the difference between a certificate rotation being invisible and being an outage. |
| Assertion consumer URL (application) | This one goes the other way: it is what we will use, shown so that you can check it against the application's own setting. Confirm they match. |
Underneath, where the template has them, sits a short numbered list headed In the application's console — the vendor-specific steps, in that vendor's own menu vocabulary. Slack's sends you to Settings & permissions → Authentication → SAML → Configure and warns you not to switch the subject over to an email address.
OIDC does less here than SAML, and you should know where it stops
Setting up an OIDC application from the catalogue creates a record and confirms that your answers resolve against the template. It does not mint a client ID or a client secret, and without those the other product cannot authenticate to us. The completion panel says so, briefly:
This registers the application as an OIDC relying party. Its client credentials are managed under Identity, OIDC clients.
So for those four rows the catalogue step is preparation, not completion. The working path is Identity → OIDC clients, which issues the credentials and lets you pick the same template again to fill in the redirect URIs. Registering an application for sign-in is that screen. If you go there first you can skip the catalogue step entirely, and we would suggest you do.
SAML has no equivalent gap. A SAML application created from the catalogue is live the moment the far side is configured.
The list of applications you cannot see yet
The name field is explained as How this application appears in your SSO list. There is no SSO list in the console. The platform keeps one, and there are endpoints that read it and delete from it, but no screen has been built on top of them.
When it refuses, and what the refusal means
- A red message under a field
- Your value did not match the shape the template expects. Slack's subdomain, for example, must be the bare word —
acme, notacme.slack.comand nothttps://acme.slack.com. The help text under each field carries a worked example for exactly this reason. - Give this application a name.
- The name box was cleared. It defaults to the vendor's name; put something back.
- this application requires signed AuthnRequests, so at least one service provider certificate must be supplied
- A small number of applications insist on signing their own requests to us, and the template knows which. Supplying that certificate is not possible from this form, although the API accepts it. Contact support and we will complete the registration rather than leave you to guess.
- application templates failed to load
- Not your problem and not fixable from your side. The template catalogue did not start. Nothing you type will help; the Set up button starts working again on its own.
- An amber banner above the form
- The capability is beta, and the banner carries the specific caveat rather than a generic warning. Nextcloud's SAML surface is the one entry currently in that state.
The line on the form that people skip
Creating this does not enable sign-in until the application is configured too.
It is there because the most common support conversation about single sign-on is not about a malformed assertion. It is about an administrator who finished on our side, saw a success panel, and reasonably assumed that was all of it. Half of this job happens in somebody else's admin console, and nothing in ours can tell you whether you have done it.
What to do next
- Paste the four values into the other product's SSO settings, preferring its metadata URL field if it offers one.
- Sign in yourself from a private window before telling anybody else it is ready, and keep one local administrator account on that product that does not depend on Qorionix.
- Decide who gets the application — registering it assigns it to nobody. See App assignments.
- If you are unsure whether you should have used this screen at all, Which single sign-on screen to use covers the six that look alike.