Logowanie jednokrotne dla instalacji on-premise

Ta strona jest przeznaczona dla operatorów instalacji MonoChat on-premise. Wyjaśnia, jak umożliwić pracownikom logowanie przez dostawcę tożsamości (IdP) Twojej firmy za pomocą OpenID Connect (OIDC), na przykład Microsoft Entra ID, Okta, Keycloak, AD FS lub Google Workspace.

Logowanie jednokrotne konfiguruje się dla całej instalacji w ustawieniach serwera, a nie dla poszczególnych organizacji. Konto MonoChat może należeć do kilku organizacji, a logowanie następuje przed wybraniem jednej z nich. Zalogowanie daje konto, a nie dostęp: osoba widzi organizację dopiero wtedy, gdy ta organizacja ją zaprosi i nada jej rolę.

Jak działa logowanie

Gdy ktoś kliknie przycisk SSO na stronie logowania, MonoChat otwiera stronę logowania Twojego IdP w wyskakującym oknie. Gdy osoba się tam zaloguje, IdP odsyła przeglądarkę do MonoChat z jednorazowym kodem. Serwer MonoChat wymienia kod na token ID i sprawdza go przed zalogowaniem osoby:

• Punkty końcowe i klucze podpisujące IdP są odczytywane przy każdym logowaniu z jego dokumentu discovery, <issuer>/.well-known/openid-configuration.
• Logowanie korzysta z przepływu authorization code z PKCE (S256), parametrem state i nonce. Żądanie logowania jest ważne 10 minut i można go użyć raz.
• Token ID musi być podpisany jednym z kluczy IdP i zawierać Twojego wystawcę (iss), Twój identyfikator klienta (aud), nonce żądania oraz czas wygaśnięcia (exp), który jeszcze nie minął.
• Token ID musi zawierać adres e-mail osoby (email). Logowanie jest odrzucane, gdy IdP podaje, że adres nie jest zweryfikowany (email_verified: false).

1. Zarejestruj MonoChat u dostawcy tożsamości

Utwórz w swoim IdP aplikację (klienta) dla MonoChat z tymi wartościami:

Ustawienie w IdP	Wartość
Typ aplikacji	Aplikacja webowa z sekretem klienta (klient poufny)
URI przekierowania logowania	https://<your MonoChat domain>/api/oauth/oidc/redirect
Typ grantu	Authorization code
Zakresy (scopes)	openid email profile
Uwierzytelnianie klienta w punkcie końcowym tokenu	Sekret klienta wysyłany przez uwierzytelnianie HTTP Basic (client_secret_basic)

Upewnij się, że token ID zawiera claim email. Zanotuj identyfikator klienta, sekret klienta i wystawcę. Wystawca to wartość issuer w dokumencie discovery IdP. Typowe formy:

Dostawca tożsamości	Wystawca (issuer)
Microsoft Entra ID	https://login.microsoftonline.com/<tenant id>/v2.0
Okta	https://<your Okta domain>/oauth2/default lub https://<your Okta domain>
Keycloak	https://<your Keycloak host>/realms/<realm>
AD FS (2016 lub nowszy)	https://<your AD FS host>/adfs
Google Workspace	https://accounts.google.com

Otwórz <issuer>/.well-known/openid-configuration w przeglądarce i skopiuj wartość issuer dokładnie, łącznie z końcowym /, jeśli występuje. MonoChat nikogo nie zaloguje, gdy te wartości się różnią.

2. Dodaj ustawienia

Dodaj bloki oidc do ustawień serwera i uruchom ponownie MonoChat. Blok publiczny trafia pod public.oauth, a blok tajny pod oauth:

{
  "oauth": {
    "oidc": {
      "clientSecret": "<client secret>",
      "autoCreateAccounts": true,
      "allowedEmailDomains": ["company.com"]
    }
  },
  "public": {
    "oauth": {
      "oidc": {
        "issuer": "https://login.microsoftonline.com/<tenant id>/v2.0",
        "clientId": "<client id>",
        "redirectPath": "/api/oauth/oidc/redirect",
        "scope": "openid email profile",
        "buttonLabel": "Sign in with Company SSO"
      }
    }
  }
}

Ustawienie	Co robi
public.oauth.oidc.issuer	Wystawca z kroku 1
public.oauth.oidc.clientId	Identyfikator klienta z kroku 1
public.oauth.oidc.redirectPath	Ścieżka URI przekierowania z kroku 1
public.oauth.oidc.scope	Zakresy, o które prosi MonoChat
public.oauth.oidc.buttonLabel	Tekst przycisku logowania. Puste pole pokazuje „Zaloguj się przez SSO” w języku osoby
oauth.oidc.clientSecret	Sekret klienta. Pozostaje na serwerze
oauth.oidc.autoCreateAccounts	true tworzy konto MonoChat przy pierwszym logowaniu SSO danej osoby, nawet gdy rejestracja jest możliwa tylko z zaproszenia (public.disableSignup)
oauth.oidc.allowedEmailDomains	Przez SSO mogą się logować tylko osoby z adresem e-mail w jednej z tych domen. Pomiń, aby zezwolić na każdą domenę

Przycisk SSO pojawi się wtedy na stronie logowania.

Kto może się zalogować

• Nowe osoby. Przy autoCreateAccounts: true pierwsze logowanie SSO danej osoby tworzy jej konto. Bez tego konto powstaje tylko wtedy, gdy public.disableSignup jest wyłączone lub osoba loguje się z zaproszenia.
• Osoby, które mają już konto z tym samym adresem e-mail. Przy oauth.autoMerge: true pierwsze logowanie SSO łączy SSO z istniejącym kontem, ale tylko wtedy, gdy token ID podaje, że adres jest zweryfikowany (email_verified: true). W pozostałych przypadkach, a bez autoMerge zawsze, MonoChat prosi osobę o jednorazowe zalogowanie się hasłem i wtedy łączy SSO z kontem; przyjęcie zaproszenia do organizacji również łączy SSO z kontem. Microsoft Entra ID i AD FS nie wysyłają email_verified, więc przy nich pozostaw logowanie hasłem dozwolone, dopóki wszyscy nie połączą SSO, albo zaproś te osoby ponownie.
• Dozwolone domeny. Przy allowedEmailDomains adres z każdej innej domeny jest odrzucany. W Google Workspace (wystawca https://accounts.google.com) MonoChat sprawdza claim hd, czyli domenę Workspace konta, zamiast adresu e-mail, ponieważ prywatne konto Google może używać adresu z dowolnej domeny.

Ustaw SSO jako jedyną metodę logowania

1. Ustaw public.auth.methods na ["oidc"]. Strona logowania pokazuje wtedy tylko przycisk SSO, a serwer odrzuca logowanie hasłem i przez konta społecznościowe.
2. Użytkownicy root super (z rolą root super w organizacji głównej) nadal mogą logować się hasłem pod adresem /auth/signin?fallback=1, więc instalacja nigdy nie zostanie zablokowana, gdy IdP nie działa.
3. Aby nowe konta SSO nie zakładały własnych organizacji, ustaw public.disableTenantCreation na true. Wtedy tylko osoby z odpowiednią rolą w organizacji mogą tworzyć organizacje pod nią.

Sieć

• Zadbaj, aby /api/oauth/oidc/authorize i Twój redirectPath były dostępne dla osób, które się logują. Oba otwierają się w ich przeglądarce.
• Serwer MonoChat musi mieć dostęp przez HTTPS do dokumentu discovery, punktu końcowego tokenu i zestawu kluczy (jwks_uri) Twojego IdP.

Ograniczenia

• Aplikacja mobilna MonoChat nie obsługuje jeszcze SSO. Jeśli ustawisz SSO jako jedyną metodę logowania, agenci nie zalogują się do aplikacji mobilnej.
• Wylogowanie z MonoChat nie wylogowuje osoby z IdP, a wylogowanie z IdP nie wylogowuje jej jeszcze z MonoChat.

Sprawdź konfigurację

1. Otwórz stronę logowania i kliknij przycisk SSO. Zaloguj się w IdP; wyskakujące okno zamknie się, a Ty zostaniesz zalogowany do MonoChat.
2. Zaloguj się jako osoba, która nie ma jeszcze konta MonoChat, i sprawdź, że konto zostało utworzone (lub odrzucone, jeśli nie włączono autoCreateAccounts).
3. Jeśli ustawiono allowedEmailDomains, spróbuj z osobą z innej domeny i sprawdź, że logowanie zostało odrzucone.
4. Jeśli ustawiono public.auth.methods, sprawdź, że logowanie hasłem jest odrzucane, a użytkownik root super nadal może zalogować się pod adresem /auth/signin?fallback=1.