Skip to main content

​
SAML SSO with JumpCloud

JumpCloud federates through an SSO application. There is no KnoxCall entry in JumpCloud’s catalogue, so you create a Custom SAML App — which needs the same four URLs and one certificate as every other provider here. Before you start
  • KnoxCall: an Enterprise plan, the owner or admin role, and at least one domain verified for single sign-on — a domain you verified for sending mail is a different proof and does not admit a login.
  • JumpCloud: an administrator who can create SSO applications.
Configured KnoxCall before 8 September 2026? Re-upload our SP metadata, or re-enter the values below, before you go further. KnoxCall now signs AuthnRequests (RSA-SHA256), publishes an encryption key so an IdP can encrypt assertions to us, and publishes a Single Logout endpoint. A JumpCloud application built from the older document has no signature certificate of ours on file, cannot be given our encryption certificate, and has no SLO endpoint of ours to call — none of which is visible from KnoxCall’s side. See the call-out on the overview page for the whole story.

​
1. Create the application

JumpCloud admin console → SSO Applications → Get Started / + Add New Application → Custom Application → Manage Single Sign-On (SSO) → Configure SSO with SAML. Give it a display name (for example KnoxCall) and continue to the SSO tab.

​
2. Service provider details

Replace acme with your workspace slug. The authoritative copy of every value is your own metadata document at https://acme.knoxcall.com/saml/acme/metadata — it is public, so fetch it in a browser and read the values off it rather than assembling them by hand. JumpCloud will also accept the document itself under Upload Metadata, which fills these fields in for you. KnoxCall’s SP entity ID is its metadata URL. That is what the metadata document says; do not shorten it to the origin, or JumpCloud’s audience will not match the one KnoxCall enforces and every assertion will be rejected. The NameID should be a stable identifier. JumpCloud’s guide says “By default, the SAMLSubject’s NameID is email, but can be changed to any of the attributes in the dropdown list, including a custom attribute.” An email changes when a person is renamed, which gives them a second KnoxCall account, because KnoxCall recognises people by their NameID (choosing the NameID). Choose a custom attribute whose value stays the same when a person is renamed — an employee number you already keep, for example — and fill it in for everyone who will sign in. If you cannot, email still works: sign-ins succeed, the connection shows its NameID notice, and a rename will create a second account. Keep the NameID Format on the email-address format above, which is the one KnoxCall’s sign-in request names. Once step 5 is done, run a sign-in from the connection’s Test tab in KnoxCall and read the NameID in the verdict to confirm what JumpCloud actually sends. These are the default connection’s values — the connection every workspace starts with, and the one the /saml/<workspace>/… alias resolves to. If JumpCloud is a second identity provider for this workspace, it gets its own connection with its own handle, and its values are /sso/<workspace>/<handle>/{metadata,acs,login,slo} — for a handle of jumpcloud, https://acme.knoxcall.com/sso/acme/jumpcloud/acs and its three siblings. Open that connection under Settings → Single sign-on and its Certificates tab lists all five, each with a copy button. See more than one identity provider.
Setting Login URL to the KnoxCall login endpoint makes the JumpCloud User Portal tile an ordinary SP-initiated sign-in, which works with IdP-initiated login switched off. Leave it blank and the tile produces an unsolicited assertion instead, which KnoxCall refuses with saml_idp_initiated_disabled unless you have deliberately opted in — see IdP-initiated sign-in.

​
3. User attributes

Under User Attribute Mapping, add two: Both service-provider names are on KnoxCall’s default list, so nothing has to be named on the KnoxCall side to read them. The email attribute is required: with a stable NameID from step 2, it is the only place KnoxCall finds the person’s address — and admission is decided by that address’s domain.

​
4. Group attributes (optional)

Only needed if you want group membership to decide whether a new person lands as member or readonly. Tick Group Attributes and set the Group Attribute Name to memberOf — one of the names KnoxCall checks without being told to. JumpCloud then emits the names of the user groups that are bound to this application. Only groups assigned to this application appear in the claim, which is the behaviour you want: the claim describes access to KnoxCall rather than the whole directory. Whatever JumpCloud emits — group names — is what you type as the keys of the group map on the KnoxCall connection. The map’s values are bounded: a group mapped to anything but member or readonly is refused at save time, because “…an IdP group may only map to member or readonly…” — those two and no others. Owner and admin are granted by a human on the team page and by nothing else.

​
5. Take the JumpCloud values back to KnoxCall

Two routes: import JumpCloud’s metadata, or type the values by hand. The import is the one that cannot be mis-transcribed.

​
Import the federation metadata

The application’s SSO tab exports JumpCloud’s IdP metadata as an XML file — one document carrying the entity ID, the IdP URL and the signing certificate. Paste its contents:
The call previews by default and writes nothing until you send it again with "apply": true. What the preview reports, what an import never touches, and every refusal it can answer with are on the overview. Like the metadata you uploaded to JumpCloud, it is a snapshot — export and import it again when JumpCloud rolls the application’s certificate.

​
Or type the values

Still on the application’s SSO tab, download the IdP Certificate, and note the IdP URL JumpCloud has assigned (it looks like https://sso.jumpcloud.com/saml2/<app>). In KnoxCall, Settings → Single sign-on → your connection: Saving needs a re-authentication in the last five minutes; that is expected, and it is the same bar as changing a password.

​
6. Assign users, then test

User Groups on the application → bind the groups who should have KnoxCall, and save. JumpCloud refuses sign-in to anyone unbound before KnoxCall ever sees a request. Test with one account: open https://acme.knoxcall.com/saml/acme/login, sign in, and check the person lands in the workspace with the role you expected. If it fails, the login page names the cause — every message and code is in troubleshooting.

​
Encrypted assertions (optional)

Where your JumpCloud application offers assertion encryption, upload the certificate from the use="encryption" KeyDescriptor in KnoxCall’s metadata document. It is the same certificate as the signing one, published twice on purpose, because an IdP reads one descriptor for each job. KnoxCall accepts encrypted and plain assertions alike and both take exactly the same path, so this is your call, not ours — and an application configured before 8 September 2026 will not offer the option at all until our metadata is re-uploaded.

​
Single Logout (optional)

Where your JumpCloud application exposes a logout endpoint, the two directions are configured separately:
  • JumpCloud → KnoxCall. Give JumpCloud KnoxCall’s SLO URL, https://acme.knoxcall.com/saml/acme/slo, and the certificate from the use="signing" KeyDescriptor so it can verify the messages KnoxCall signs. A LogoutRequest naming the person’s NameID ends the sessions this workspace’s IdP authenticated.
  • KnoxCall → JumpCloud. Put JumpCloud’s own SLO endpoint into the KnoxCall connection’s IdP single-logout URL. It must be https; KnoxCall refuses anything else at save time, because a LogoutRequest carries the person’s email address as its NameID and the browser is redirected to that URL.
Leave the KnoxCall field empty if your application has no such endpoint. Empty means “this connection does not do SP-initiated Single Logout” and it never falls back to the sign-in URL. Either way, signing out of KnoxCall always ends the KnoxCall session — never conditionally on the IdP leg. The full behaviour is in Single Logout.

​
Rotating the JumpCloud certificate

JumpCloud’s application certificate expires. Rotate add-first:
  1. Generate the new certificate in JumpCloud, leaving the current one in use.
  2. Copy the new certificate into the KnoxCall connection. Pasting a certificate adds it — a connection can hold several active certificates and an assertion signed by any of them verifies.
  3. Switch JumpCloud over to signing with the new key.
  4. Retire the old certificate in KnoxCall.
Doing it in that order means there is no instant at which the certificate JumpCloud is signing with is not one KnoxCall trusts. Retiring the only active certificate is refused: “This is the connection’s only active IdP certificate. Add the new certificate first, then retire this one.”