Gå til indhold
Dokumentation
SSO

SSO

Vis som Markdown

Med single sign-on (SSO) logger personerne i dit projekt ind i Status200 gennem din organisations identitetsudbyder (IdP) via SAML 2.0 eller OpenID Connect. Du styrer adgang, adgangskoder og multifaktorgodkendelse ét sted, og du kan kræve SSO for alle i projektet.

Bemærk
Udgave: SSO, herunder "Require SSO for login", er en del af alle Status200-udgaver: selvhostede installationer får det i Community Edition uden at skulle bruge en licens. På Status200 Cloud er det tilgængeligt fra planen Scale og opefter. Se Enterprise Edition for, hvad hver udgave indeholder.

Opsæt en SAML-udbyderOpret den i Status200, og giv din IdP to URL'er.Vejledninger til identitetsudbydereKeycloak, Microsoft Entra ID og Okta, trin for trin.OpenID ConnectLog ind via en OIDC-app i stedet.Kræv SSOGør SSO til den eneste vej ind i projektet.

Sådan fungerer SAML-login

En SAML-udbyder forbinder ét projekt med én applikation i din identitetsudbyder. Den, der logger ind, vælger projektet på Status200s side Log ind med SSO, logger ind hos din IdP og kommer tilbage logget ind.

sequenceDiagram actor U as Person participant O as Status200 participant I as Identitetsudbyder U->>O: Log ind med SSO,<br/>vælg projektet O->>I: SAML-anmodning<br/>til log på-URL'en I->>U: Loginside U->>I: Loginoplysninger og MFA I->>O: Signeret assertion<br/>til Reply URL Note over O: Kontrollerer signaturen<br/>og udstederen,<br/>læser e-mailen fra Name ID O->>U: Logget ind i projektet

SAML-login trin for trin

Status200 læser kun få ting fra den assertion, din IdP sender:

Fra assertionenHvad Status200 gør med det
SignaturKontrollerer den med udbyderens Offentligt certifikat. Svaret skal være signeret og må ikke være krypteret.
IssuerSkal svare præcist til udbyderens Udsteder.
AudienceSkal være udbyderens Identifier (Entity ID). Et svar, som din IdP lavede til en anden applikation, afvises.
Recipient og DestinationSkal være udbyderens Reply URL, den adresse, svaret blev sendt til.
NotBefore og NotOnOrAfterSvaret accepteres kun, så længe de tillader det, og senest 10 minutter efter, at det blev udstedt, med 3 minutters spillerum for ure, der ikke går ens.
Name IDPersonens e-mailadresse. Den skal være en gyldig e-mailadresse.
NavneattributterPersonens navn, som bruges, når Status200 opretter kontoen: et visningsnavn (displayName eller http://schemas.microsoft.com/identity/claims/displayname) eller et for- og efternavn (firstName og lastName eller claimene givenname og surname, som Microsoft Entra ID sender som standard). Valgfri.
http://schemas.microsoft.com/identity/claims/objectidentifierPersonens objekt-ID, som Microsoft Entra ID sender som standard. Det første login via udbyderen knytter kontoen til det, og et senere login, der angiver kontoens e-mailadresse med et andet objekt-ID, afvises. Valgfri.

Hvert svar logger kun ind én gang. Sendes det igen, for eksempel når du går tilbage i browseren efter at have logget ind, afvises det: log ind igen.

Personer, der logger ind for første gang, kommer med i udbyderens Teams, og de afgør, hvad personen kan gøre: se Roller og teams for SSO-brugere.

Bemærk

På Status200 Cloud logger Status200 ikke en person ind, første gang vedkommende logger ind i projektet med en af projektets SAML- eller OIDC-udbydere; i stedet sender Status200 et link pr. e-mail. Personen åbner linket, bekræfter, at projektets single sign-on må logge vedkommende ind, og fortsætter med at logge ind. Linket gælder i 24 timer. Det sker én gang pr. projekt og igen, hvis personen forlader projektet og vender tilbage. Selvhostede installationer logger personer ind med det samme.

På Status200 Cloud optager en person, der kommer med i projektet via SSO, en plads, præcis som en person, du inviterer. Hvis din plan har et fast antal pladser, og de alle er optaget, kan nye personer ikke komme med via SSO, før en plads bliver ledig.

Opsætning af SSO

Du skal have tilladelse til at tilføje SSO-udbydere — Project Owner, Project Admin eller Create Project SSO — og på Status200 Cloud planen Scale. Se vejledningerne til identitetsudbydere for din identitetsudbyders side.

  1. Gå til projektindstillinger

    • Åbn dit Status200-projekt
    • Gå til Projektindstillinger > Sikkerhed > SSO

  2. Opret SSO-konfigurationen

    • Klik på Tilføj SAML-udbyder
    • Indtast et Navn til SSO-konfigurationen (f.eks. "Keycloak SAML" eller "Okta SAML")
    • Indtast Log på-URL fra din identitetsudbyder
    • Indtast Udsteder (Entity ID) fra din identitetsudbyder
    • Indsæt Offentligt certifikat fra din identitetsudbyder
    • I trinnet Login starter Teams med dit projekts medlemsteam: personer, der logger ind for første gang, kommer med i disse teams. Kun teams, du selv kunne invitere nogen til, accepteres: et team, der giver mere adgang, end du har, nævnes under Teams
    • Resten er allerede udfyldt under Flere felter: Signaturmetode (RSA-SHA256), Digest-metode (SHA256) og en beskrivelse ("Sign in with" og navnet). Ændr dem kun, hvis din identitetsudbyder kræver det

  3. Hent Status200s SSO-metadata

    • Når du gemmer, åbnes dialogen SSO Configuration. Du kan åbne den igen med knappen Vis SSO-konfiguration
    • Kopiér Identifier (Entity ID), f.eks. https://status200.ru/<project-id>/<provider-id> — den skal bruges i din IdP-konfiguration
    • Kopiér Reply URL (Assertion Consumer Service URL), f.eks. https://status200.ru/identity/idp-login/<project-id>/<provider-id> — den skal bruges i din IdP-konfiguration
    • En ny udbyder starter slået fra. Når din IdP har disse to værdier, skal du redigere udbyderen og slå Aktiveret til

  4. Test udbyderen

    • Åbn linket i kortet Test Single Sign On (SSO), og vælg udbyderen på den side, der åbnes. Du sendes til din identitetsudbyders loginside og tilbage til Status200, logget ind
    • Når det virker, kan du kræve SSO for projektet

Vejledninger til identitetsudbydere

Vælg din identitetsudbyder. Hver vejledning henter IdP'ens værdier, opretter udbyderen i Status200 og giver derefter IdP'en Status200s Identifier (Entity ID) og Reply URL.

Keycloak

Keycloak er en populær open source-løsning til identitets- og adgangsstyring. Du skal bruge en kørende Keycloak-instans med et realm og administratoradgang til både Keycloak og Status200.

  1. Saml dit realms værdier

    • Log på-URL: https://<your-keycloak-domain>/auth/realms/<your-realm>/protocol/saml
    • Udsteder: https://<your-keycloak-domain>/auth/realms/<your-realm>
    • Certifikat: realmets signeringscertifikat. Åbn https://<your-keycloak-domain>/auth/realms/<your-realm>/protocol/saml/descriptor og kopiér værdien X509Certificate, eller åbn Realm settings > Keys og klik på Certificate ved RS256-nøglen

    Keycloak 17 og nyere leverer disse URL'er uden præfikset /auth. Sæt certifikatet mellem sine egne linjer, sådan her:

    -----BEGIN CERTIFICATE-----
MIICnzCCAYcCBgFyPZ8QFzANBgkqhkiG.......
-----END CERTIFICATE-----

  2. Opret udbyderen i Status200

    Gå til Projektindstillinger > Sikkerhed > SSO, klik på Tilføj SAML-udbyder, og udfyld:

    • Navn: et beskrivende navn (f.eks. my-project-oneuptime)
    • Log på-URL og Udsteder: værdierne ovenfor
    • Offentligt certifikat: certifikatet mellem sine egne linjer BEGIN CERTIFICATE og END CERTIFICATE
    • Signaturmetode og Digest-metode: allerede angivet under Flere felter (RSA-SHA256 og SHA256)

    Gem, og kopiér Identifier (Entity ID) og Reply URL (Assertion Consumer Service URL) fra dialogen, der åbnes.

  3. Opret Keycloak-klienten

    Åbn Clients i dit realm i Keycloak, og opret en klient, eller rediger en eksisterende:

    • Client Protocol (klienttype): saml
    • Client ID: Identifier (Entity ID) fra Status200
    • Root URL og Valid Redirect URIs: din Status200-URL
    • Assertion Consumer Service POST Binding URL: Reply URL (Assertion Consumer Service URL) fra Status200

  4. Juster klientindstillingerne

    • Sæt Name ID Format til email, og slå Force Name ID Format til, så Keycloak altid sender e-mailen som Name ID
    • Slå Client signature required (under Signing keys config) fra på klientens fane Keys: Status200 signerer ikke sine anmodninger

  5. Slå udbyderen til, og test den

    Rediger udbyderen i Status200, og slå Aktiveret til; åbn derefter linket i kortet Test Single Sign On (SSO), og vælg udbyderen. Du bør blive sendt til Keycloaks loginside og tilbage til Status200.

Microsoft Entra ID

Microsoft Entra ID (tidligere Azure AD / Active Directory) er Microsofts cloudbaserede identitetstjeneste. Du skal bruge en lejer, der understøtter virksomhedsapplikationer med SAML-SSO, og administratoradgang til både Entra ID og Status200. Findes Status200 i Microsoft Entra-applikationsgalleriet, så tilføj appen derfra på Status200 Cloud: den leveres med de claims, Status200 læser, og mønstrene for Status200s URL'er.

  1. Opret en virksomhedsapplikation i Entra ID

    • Log ind i Microsoft Entra admin center
    • Gå til Identity > Applications > Enterprise applications, og klik på + New application
    • Fra galleriet: søg efter Status200, vælg den, og klik på Create
    • Ellers: klik på + Create your own application, indtast et navn (f.eks. "Status200"), vælg Integrate any other application you don't find in the gallery (Non-gallery), og klik på Create

  2. Kopiér Entra ID's SAML-værdier

    • Gå til Single sign-on i applikationen, og vælg SAML
    • Download Certificate (Base64) under SAML Certificates, åbn filen i en teksteditor, og kopiér indholdet
    • Kopiér Login URL og Microsoft Entra Identifier (Azure AD Identifier i ældre lejere) under Set up Status200

  3. Opret udbyderen i Status200

    Gå til Projektindstillinger > Sikkerhed > SSO, klik på Tilføj SAML-udbyder, og udfyld:

    • Navn: et beskrivende navn (f.eks. Azure AD SAML)
    • Log på-URL: Login URL
    • Udsteder: Microsoft Entra Identifier
    • Offentligt certifikat: Base64-certifikatet, inklusive linjerne BEGIN CERTIFICATE og END CERTIFICATE
    • Signaturmetode og Digest-metode: allerede angivet under Flere felter (RSA-SHA256 og SHA256)

    Gem, og kopiér Identifier (Entity ID) og Reply URL (Assertion Consumer Service URL) fra dialogen, der åbnes.

  4. Giv Entra ID Status200s URL'er

    Klik på Edit under Basic SAML Configuration, og angiv:

    • Identifier (Entity ID): Identifier (Entity ID) fra Status200
    • Reply URL (Assertion Consumer Service URL): Reply URL fra Status200

    Klik på Save.

  5. Send e-mailen som Name ID

    Klik på Edit under Attributes & Claims. Applikationen fra galleriet har allerede disse indstillinger: kontrollér dem.

    • Sæt Unique User Identifier (Name ID) til brugerens e-mailadresse: user.mail, eller user.userprincipalname, hvor det er e-mailadressen
    • Sæt Name identifier format til Email address
    • Behold Entra ID's standardclaims: nye konti får personens navn fra givenname og surname, og kontoen knyttes til personens objekt-ID, objectidentifier. Tilføj eventuelt et claim med navnet http://schemas.microsoft.com/identity/claims/displayname og kildeattributten user.displayname, så nye konti i stedet får visningsnavnet. Status200 ignorerer de øvrige claims

  6. Tildel brugere og grupper

    Klik på + Add user/group under applikationens Users and groups, vælg de brugere og grupper, der skal have SSO-adgang, og klik på Assign.

  7. Slå udbyderen til, og test den

    Rediger udbyderen i Status200, og slå Aktiveret til; åbn derefter linket i kortet Test Single Sign On (SSO), og vælg udbyderen. Du bør blive sendt til Microsofts loginside og tilbage til Status200.

Okta

Okta er en udbredt identitetsplatform med SAML-SSO. Du skal bruge en Okta-organisation med administratoradgang og administratoradgang til Status200. Findes Status200 i Okta Integration Network, så tilføj appen derfra på Status200 Cloud: den logger personer ind fra Status200s side Log ind med SSO og fra deres Okta-dashboard, giver dem en konto ved deres første login og beder om to ID'er i stedet for Status200s URL'er.

  1. Føj Status200 til Okta

    • Gå til Applications > Applications i Okta Admin Console
    • Fra Okta Integration Network: klik på Browse App Catalog, søg efter Status200, og klik på Add Integration. Okta beder om Status200 Project ID og Status200 SSO Provider ID, før Status200 kan vise dem: indtast 0 i begge indtil videre; du erstatter dem i trin 4. Klik på Done, og fortsæt med trin 2
    • Ellers: klik på Create App Integration, vælg SAML 2.0, og klik på Next, indtast "Status200" som App name, og klik på Next
    • Okta beder om Status200s URL'er, før den viser sine egne. Indtast indtil videre din Status200-adresse (for eksempel https://status200.ru) som Single sign-on URL og som Audience URI (SP Entity ID): du erstatter begge i trin 4
    • Sæt Name ID format til EmailAddress og Application username til Email
    • Klik på Next, vælg I'm an Okta customer adding an internal app, og klik på Finish

  2. Kopiér Oktas SAML-værdier

    Find det aktive certifikat under SAML Signing Certificates på applikationens fane Sign On:

    • Klik på Actions > View IdP metadata, og kopiér Log på-URL (Identity Provider Single Sign-On URL) og Udsteder (Identity Provider Issuer)
    • Klik på Actions > Download certificate, åbn filen .cert i en teksteditor, og kopiér indholdet

  3. Opret udbyderen i Status200

    Gå til Projektindstillinger > Sikkerhed > SSO, klik på Tilføj SAML-udbyder, og udfyld:

    • Navn: et beskrivende navn (f.eks. Okta SAML)
    • Log på-URL og Udsteder: Oktas værdier
    • Offentligt certifikat: certifikatet, inklusive linjerne BEGIN CERTIFICATE og END CERTIFICATE
    • Signaturmetode og Digest-metode: allerede angivet under Flere felter (RSA-SHA256 og SHA256)

    Gem, og kopiér Identifier (Entity ID) og Reply URL (Assertion Consumer Service URL) fra dialogen, der åbnes.

  4. Giv Okta Status200s URL'er

    For applikationen fra Okta Integration Network skal du klikke på Edit under App Settings på fanen General og angive:

    • Status200 Project ID og Status200 SSO Provider ID: de to ID'er i Identifier (Entity ID) fra Status200, https://status200.ru/<project-id>/<provider-id>

    Klik på Save, og kontrollér, at Application username format er Email på fanen Sign On.

    For din egen applikation skal du klikke på Edit under SAML Settings på fanen General og derefter på Next og angive:

    • Single sign-on URL: Reply URL (Assertion Consumer Service URL) fra Status200
    • Audience URI (SP Entity ID): Identifier (Entity ID) fra Status200

    Tilføj eventuelt attribute statements med navnene firstName, med værdien user.firstName, og lastName, med værdien user.lastName, så nye konti får personens navn. Klik på Next og derefter på Finish.

  5. Tildel personer

    Klik på Assign > Assign to People eller Assign to Groups på fanen Assignments, vælg, hvem der får SSO-adgang, klik på Assign for hver, og derefter på Done.

  6. Slå udbyderen til, og test den

    Rediger udbyderen i Status200, og slå Aktiveret til; åbn derefter linket i kortet Test Single Sign On (SSO), og vælg udbyderen. Du bør blive sendt til Oktas loginside og tilbage til Status200.

Andre

Status200s SSO bruger SAML 2.0 og fungerer med enhver kompatibel identitetsudbyder:

  1. Hent din identitetsudbyders Log på-URL (dens SSO-endepunkt), Udsteder (dens Entity ID) og Offentligt certifikat (dens X.509-signeringscertifikat). Hvis din IdP først viser dem, når der findes en applikation, så opret applikationen med din Status200-adresse som midlertidige URL'er.
  2. Opret udbyderen i Status200 med disse værdier, og kopiér Identifier (Entity ID) og Reply URL (Assertion Consumer Service URL) fra dialogen SSO Configuration (eller via Vis SSO-konfiguration).
  3. Sæt Assertion Consumer Service URL / Reply URL og Entity ID / Audience URI til Status200s værdier i din identitetsudbyders SAML-applikation, og sæt Name ID Format til e-mailadresse.
  4. Signaturmetode (RSA-SHA256) og Digest-metode (SHA256) er allerede angivet under Flere felter; ændr dem kun, hvis din identitetsudbyder signerer anderledes
  5. Slå Aktiveret til for udbyderen, og test den med linket i kortet Test Single Sign On (SSO).

OpenID Connect (OIDC)

Et projekt kan også logge ind via en OpenID Connect-udbyder som Google Workspace, Okta, Microsoft Entra ID, Auth0 eller Keycloak. Du skal have tilladelse til at tilføje OIDC-udbydere (Project Owner, Project Admin eller Create Project OIDC) og på Status200 Cloud planen Scale.

  1. Registrer en app (en OIDC-klient) hos din identitetsudbyder, der må bruge authorization code-flowet med PKCE, og kopiér dens Udsteder-URL, Klient-ID og Klienthemmelighed.
  2. Gå til Projektindstillinger > Sikkerhed > SSO i Status200. Klik på Tilføj OIDC-udbyder under SAML-udbyderne.
  3. Indtast et Navn (det, personer ser på loginsiden), Udsteder-URL, Klient-ID og Klienthemmelighed. Du kan også indsætte udbyderens discovery-URL i Udsteder-URL i stedet.
  4. I trinnet Login starter Teams med dit projekts medlemsteam: personer, der logger ind for første gang, kommer med i disse teams. Resten er allerede udfyldt under Flere felter: Discovery-URL (udstederen efterfulgt af /.well-known/openid-configuration), Omfang (openid email profile), claim-navnene email og name og en beskrivelse ("Sign in with" og navnet). Ændr dem kun, hvis din udbyder kræver det. Kun teams, du selv kunne invitere nogen til, accepteres: et team, der giver mere adgang, end du har, nævnes under Teams.
  5. Gem. Dialogen OIDC Configuration åbnes med Redirect URI: tilføj den til din apps tilladte redirect-URI'er. En ny udbyder starter slået fra, så rediger den bagefter, og slå Aktiveret til.
  6. Åbn linket i kortet Test Single Sign On (SSO), og vælg udbyderen for at logge ind via den, før du kræver SSO for projektet.

Roller og teams for SSO-brugere

Status200 overtager ikke roller eller grupper fra din identitetsudbyder. Hvad en person kan gøre, afhænger af de teams, vedkommende er med i: en udbyder tilføjer nye personer til sine Teams, og du administrerer teams og deres tilladelser i Status200, som beskrevet i Brugere, teams og tilladelser. Brug SCIM til at holde teammedlemskaber i takt med din identitetsudbyder.

En udbyders teams afgør, hvad de personer, der logger ind med den, kan gøre, så en udbyder gemmes kun med teams, som den, der gemmer den, kunne invitere nogen til. Hver gemning kontrollerer dem igen: en udbyder, hvis teams giver mere adgang, end du har, kan kun ændres af en person, hvis adgang dækker dem, for eksempel en projektejer. Udbydere, der blev gemt før denne kontrol, bliver ved med at logge personer ind i deres teams. Alle, der må redigere en udbyder, kan stadig slå den fra, så den kan stoppes med det samme.

Kræv SSO for dit projekt

En opsat udbyder forhindrer ikke nogen i at logge ind med en adgangskode. For at gøre SSO til den eneste vej ind i projektet skal du bruge kontakten Kræv SSO til login under Projektindstillinger > Sikkerhed > SSO, under dine udbydere:

  1. Test først din udbyder med linket i kortet Test Single Sign On (SSO).
  2. Slå Kræv SSO til login til. Status200 spørger, før noget gemmes: fra da af skal alle i projektet, også dig, logge ind med SSO for at åbne det, og alle, der er logget ind med en adgangskode, er udelukket fra projektet, indtil de logger ind med SSO.
  3. Klik på Kræv SSO for at bekræfte. Kontakten gemmer med det samme; der er ingen separat knap til at gemme.

For at slå Kræv SSO til login til skal der være en udbyder, der logger personer ind i projektet: en af projektets egne SAML- eller OIDC-udbydere, der er slået til, eller en global udbyder, der er slået til og logger personer ind i projektet. Uden en sådan afviser Status200 og beder dig først slå en udbyder til for projektet og teste den. Vælger du en udbyder, som projektet kræver, skal det være en af disse, og det samme spørges om, når du senere kræver en anden udbyder.

En gemning, der sender Kræv SSO til login som slået til, mens det allerede er slået til, eller som nævner den udbyder, projektet allerede kræver, kontrolleres på samme måde — API'et, Terraform og andre værktøjer sender ofte alle indstillinger ved hver gemning. Så længe projektet ikke har en udbyder, der logger personer ind, eller den krævede udbyder er blevet slået fra siden, afvises en sådan gemning derfor med de samme ord, uanset hvad den ellers ændrer: slå først en udbyder til, kræv en anden, eller slå Kræv SSO til login fra.

Et nyt projekt følger samme regel. Det har endnu ingen egen udbyder, så at oprette det med Kræv SSO til login allerede slået til — det kan kun en master-admin — kræver en global udbyder, der er slået til og logger personer ind i alle projekter, og uden en sådan afvises det med de samme ord. Opret projektet, opsæt og test dets udbyder, og slå derefter kontakten til.

Så længe hele serveren kræver SSO (Admin > Indstillinger > Godkendelse > Kræv SSO til login), kræver oprettelse af ethvert projekt også en sådan global udbyder, ellers kunne ingen, heller ikke den, der opretter projektet, åbne det. Uden en sådan afvises oprettelsen af et projekt, og meddelelsen beder en serveradministrator slå en til. Master-admins kan stadig oprette projekter.

At slå Kræv SSO til login fra gemmes, så snart du slår kontakten om, og lukker medlemmer ind med deres adgangskode med det samme — medmindre nogen slår den til igen i præcis det øjeblik; så kan en appserver være op til et minut om at følge med. Projektejere, projektadministratorer og medlemmer med tilladelsen Edit Project kan ændre den; alle andre ser kontakten låst sammen med den tilladelse, de ville have brug for.

Bemærk

På Status200 Cloud kræver det planen Scale at kræve SSO, mens det virker på alle planer at slå det fra. Under Scale viser Projektindstillinger > Sikkerhed > SSO planens opgraderingstilbud; et projekt, som en Scale-prøveperiode efterlod med krav om SSO, finder også Kræv SSO til login der, under tilbuddet, så det kan slås fra. At slå det til igen kræver Scale.

Slå en udbyder fra eller slet den

Hvad du ændrerPersoner, der loggede ind med udbyderen
Slå den fra eller slet denLogger ind med SSO igen ved deres næste anmodning, hvor SSO er påkrævet
Et nyt certifikat eller klienthemmelighed, andre URL'er, et nyt navn eller andre teamsForbliver logget ind
Slå den tilKan logge ind med den med det samme

At slå en SAML- eller OIDC-udbyder fra eller slette den afslutter de logins, den har givet. I et projekt, der kræver SSO, selv eller fordi hele serveren gør det:

  • Alle, der loggede ind med den, skal logge ind med SSO igen ved deres næste anmodning, og de sider, de har åbne, holder straks op med at modtage liveopdateringer.
  • En MCP-klient, som nogen forbandt efter at have logget ind med den, holder op med at virke i projektet. Forbind den igen efter at have logget ind med SSO.
  • At slå udbyderen til igen bringer ikke disse logins tilbage: personerne logger ind med den igen.

At ændre alt andet ved en udbyder holder alle logget ind: et nyt certifikat eller klienthemmelighed, andre URL'er, et nyt navn eller andre teams. Deres logins blev kontrolleret, da de blev givet, og næste login bruger de nye indstillinger.

Så længe projektet kræver SSO, holder Status200 en vej ind åben: du kan ikke slå den sidste udbyder, som personer kan logge ind i projektet med — globale udbydere, der logger personer ind i det, medregnet — eller den udbyder, projektet kræver, fra eller slette den. Slå først Kræv SSO til login fra.

At slå en udbyder til lader personer logge ind med den med det samme.

Når hele serveren kræver SSO (Admin > Indstillinger > Godkendelse > Kræv SSO til login), beholder hvert projekt en vej ind på samme måde, også et projekt, der ikke selv kræver SSO: slå først en anden udbyder til for det.

Globale udbydere følger samme regel: en ændring af en global udbyder eller dens tilknyttede projekter, der ville efterlade et projekt, der kræver SSO, uden udbyder, afvises og nævner projektet. Se Global SSO.

Hvor hverken projektet eller serveren kræver SSO, stopper det nye logins med udbyderen at slå den fra. Personer, der allerede er logget ind, forbliver logget ind, ligesom personer, der loggede ind med en adgangskode.

Udbydere under planen Scale

En SAML- eller OIDC-udbyder, som et projekt stadig har, bliver ved med at logge personer ind, efter at en Scale-prøveperiode slutter, eller planen nedgraderes. Derfor viser siden SSO under Scale projektets udbydere under opgraderingstilbuddet (SAML-udbydere, der stadig er sat op, OIDC-udbydere, der stadig er sat op):

  • Slå fra stopper en udbyder med det samme. Status200 spørger først.
  • Slet fjerner den.

At tilføje en udbyder, ændre en eller slå den til igen kræver Scale. Hvem der må hvad, er det samme som med Scale: at slå en udbyder fra kræver tilladelse til at redigere den, at slette den tilladelse til at slette den.

Så længe projektet stadig kræver SSO, viser siden SSO også Kræv SSO til login: slå det fra, før du slår den sidste udbyder fra. Indtil da kan den sidste udbyder, som personer kan logge ind med, hverken slås fra eller slettes, så ingen bliver udelukket fra projektet.

En statussides sider SSO og OIDC viser dens egne udbydere på samme måde. Så længe statussiden stadig kræver SSO, viser begge sider også Kræv SSO til login: slå det fra, før du slår dens udbydere fra, ellers kan dens private brugere slet ikke logge ind.

Fejlfinding

"SSO Config not found"

Udbyderen er slået fra, eller linket gælder en udbyder, der ikke længere findes. En ny udbyder starter slået fra: rediger den, og slå Aktiveret til.

"No teams added."

Personen er endnu ikke med i projektet, og udbyderen har ingen Teams at føje vedkommende til. Rediger udbyderen, og vælg mindst ét team, for eksempel dit projekts medlemsteam.

"Issuer URL does not match"

Issuer i din IdP's assertion er ikke udbyderens Udsteder. Kopiér den igen fra din IdP — Keycloak-realmets URL, Microsoft Entra Identifier eller Oktas Identity Provider Issuer — så de to stemmer præcist overens.

"SAML Audience does not match"

Svarets audience er ikke denne udbyders Identifier (Entity ID): din IdP lavede svaret til en anden applikation. Sæt applikationens entity ID i din IdP til Identifier (Entity ID) fra Vis SSO-konfiguration – Client ID i Keycloak, Identifier (Entity ID) i Entra ID, Audience URI (SP Entity ID) i Okta. En IdP, der er sat op med kun Status200s adresse som entity ID, for eksempel https://status200.ru, virker fortsat.

"SAML Recipient does not match"

Svarets recipient er ikke denne udbyders Reply URL: svaret blev sendt til en anden adresse. Sæt applikationens reply URL i din IdP til Reply URL (Assertion Consumer Service URL) fra Vis SSO-konfiguration – Assertion Consumer Service POST Binding URL i Keycloak, Reply URL (Assertion Consumer Service URL) i Entra ID, Single sign-on URL i Okta. "SAML Destination does not match" har samme årsag og samme løsning.

"SAML response has expired"

Svaret nåede frem til Status200 senere, end din IdP tillader, eller mere end 10 minutter efter, at det blev udstedt: log ind igen. Hvis det bliver ved med at ske, går uret i din IdP eller på Status200-serveren forkert; Status200 tillader, at de er 3 minutter fra hinanden. "SAML response is not valid yet" er samme problem den anden vej.

"SAML response was already used"

Hvert svar fra din IdP logger kun ind én gang. Går du tilbage i browseren efter at have logget ind, eller genindlæser du den side, din IdP sendte dig igennem, sendes det samme svar igen: log ind igen, fra Status200 eller fra din IdP.

"This account is linked to someone else."

Microsoft Entra ID loggede en person ind med e-mailadressen på en konto, der via denne udbyder er knyttet til et andet objekt-ID: en anden person har nu adressen i Entra ID, eller personens Entra ID-konto er blevet oprettet igen. Status200 afviser loginforsøget, så den, der får adressen næste gang, ikke kan bruge kontoen. Hvis kontoen tilhører personen, så fjern vedkommende fra projektet, og tilføj vedkommende igen: ved næste login knyttes kontoen til personens nye objekt-ID.

Login mislykkes med en signatur- eller certifikatfejl

Indsæt IdP'ens aktuelle signeringscertifikat i Offentligt certifikat, inklusive linjerne BEGIN CERTIFICATE og END CERTIFICATE. For Entra ID skal du downloade certifikatet i formatet Base64, ikke det rå; for Okta det aktive signeringscertifikat; for Keycloak certifikatet fra det rigtige realm.

"Encrypted SAML Responses are not supported"

Status200 dekrypterer ikke assertions. Slå kryptering af assertions fra for applikationen i din IdP, så den sender en ukrypteret, signeret assertion.

"SAML response did not include a valid email address"

Status200 læser e-mailadressen fra Name ID. Sæt Name ID til brugerens e-mail: Name ID Format email med Force Name ID Format i Keycloak, Unique User Identifier (Name ID) i Entra ID, eller Name ID format EmailAddress og Application username Email i Okta. Adressen skal svare til personens Status200-konto.

Entra ID: AADSTS700016

Identifier (Entity ID) i Entra ID svarer ikke til Status200s. Kopiér den igen fra Vis SSO-konfiguration; de to værdier skal være identiske.

Okta: 404 eller en audience, der ikke passer

Single sign-on URL i Okta skal være præcis Status200s Reply URL, og Audience URI præcis Status200s Identifier (Entity ID). Kontrollér, at begge har erstattet de midlertidige værdier.

Brugeren er ikke tildelt applikationen

Entra ID og Okta logger kun personer ind, der er tildelt applikationen. Tildel brugeren eller en gruppe, vedkommende er med i.

Keycloak: omdirigeringsløkke

Kontrollér, at Valid Redirect URIs og Assertion Consumer Service POST Binding URL er angivet som ovenfor, på klienten i det rigtige realm.

Næste trin

Global SSOÉn identitetsudbyder til alle projekter på en selvhostet instans.SCIMLad din identitetsudbyder tilføje og fjerne personer automatisk.Brugere, teams og tilladelserHvad de teams, nye personer kommer med i, giver dem lov til.