Ten przewodnik łączy ownCloud Infinite Scale (oCIS) z Keycloak za pomocą OpenID Connect (OIDC), warstwy tożsamości zbudowanej na OAuth 2.0. Keycloak uwierzytelnia użytkowników; oCIS ufa podpisanym tożsamościom i informacjom dostępowym udostępnianym przez Keycloak. Logowanie przez przeglądarkę korzysta z przekierowań HTTPS, a oCIS musi również dotrzeć do punktów końcowych Keycloak, służących do wykrywania i podpisywania kluczy.
Stan na 6 października 2026 r. w dokumentacji administracyjnej ownCloud te ustawienia są opisane w systemie Infinite Scale 9.0. Oficjalny przykład wdrożenia Keycloak stanowi przydatny punkt wyjścia, ale jego plik Compose i eksport domeny mogą ulec zmianie. Przypnij kompatybilne wersje obrazów i sprawdź pliki, które wdrażasz, zamiast bezmyślnie kopiować przykład bez kontroli wersji.
Przygotuj publiczny adres HTTPS dla oCIS, taki jak https://cloud.example.com, oraz publiczny adres HTTPS dla Keycloak, taki jak https://sso.example.com. Obie nazwy muszą być poprawnie rozpoznawane przez przeglądarki użytkowników. Serwer oCIS musi również mieć dostęp do metadanych OIDC i publicznych kluczy podpisu Keycloak. Jeśli serwer proxy odwrotnego obsługuje którąkolwiek z usług, skonfiguruj spójnie jego publiczną nazwę hosta i przekazywane nagłówki.
W Keycloak wystawcą OIDC jest zazwyczaj adres URL domeny, a nie adres URL konsoli administracyjnej ani adres URL dokumentu odkrycia. W przypadku domeny o nazwie teammoże to wyglądać tak https://sso.example.com/realms/team: . Starsze instalacje lub wdrożenia z prefiksem ścieżki mogą się różnić, dlatego nie należy konstruować wartości z pamięci. Otwórz dokument odkrycia domeny w https://sso.example.com/realms/team/.well-known/openid-configurationi skopiuj dokładnie wartość jego issuerwłaściwości.
Z serwera, który ma dostęp do Keycloak, możesz sprawdzić dokument za pomocą:
curl -fsS https://sso.example.com/realms/team/.well-known/openid-configurationSprawdź, czy zwrócony wystawca używa tego samego schematu, hosta, ścieżki i nazwy domeny, które skonfigurujesz w oCIS. OpenID Connect dokładnie weryfikuje tożsamość wystawcy; niezgodność nazwy hosta proxy odwrotnego lub dodatkowy ukośnik mogą uniemożliwić logowanie.
Klient to rejestracja aplikacji, której Keycloak używa do decydowania, która usługa może żądać logowania. Utwórz lub dostosuj klienta OpenID Connect w domenie używanej dla oCIS. Użyj identyfikatora klienta, takiego jak web, lub wartości niestandardowej i upewnij się, że jest ona zgodna z WEB_OIDC_CLIENT_IDwartością w oCIS. Oficjalny przykład ownCloud używa go webjako domyślnego.
W przypadku klienta przeglądarkowego należy użyć standardowego przepływu kodu autoryzacji i konfiguracji klienta publicznego zgodnej z oficjalną przykładową domeną. Wprowadź dokładne wzorce przekierowania HTTPS i przekierowania po wylogowaniu wymagane przez wdrożenie. Wąski wzorzec nazwy hosta, taki jak [brakuje nazwy hosta], https://cloud.example.com/*jest łatwiejszy do zweryfikowania niż szeroki symbol wieloznaczny na każdym hoście. Dodaj tylko źródła internetowe potrzebne wdrożeniu. Nie twórz tajnego klucza klienta dla publicznego klienta przeglądarkowego, a następnie nie osadzaj go w konfiguracji front-endu.
Deklaracje OIDC to atrybuty tożsamości przenoszone w tokenie lub zwracane przez punkt końcowy user-info. Należy starannie dobrać deklarację nazwy użytkownika. Domyślnie proxy ownCloud rozpoznaje preferred_usernameużytkownika, a przykład Keycloak konfiguruje klienta internetowego ze standardowymi zakresami profilu i adresu e-mail. Sprawdź, czy Twoja domena faktycznie zwraca używane deklaracje; dostępność deklaracji zależy od zakresów klienta i maperów protokołów.
W przypadku istniejących kont skonfigurowane oświadczenie musi być mapowane na odpowiadający mu stabilny atrybut użytkownika ownCloud. Zmiana nazwy użytkownika lub adresu e-mail może spowodować problemy z dopasowaniem konta, jeśli zostanie ono użyte jako stały identyfikator. Oświadczenie subjest gwarantowane jako unikalne i stabilne dla każdego dostawcy tożsamości, ale może nie być zgodne z wcześniej istniejącą nazwą użytkownika. Przetestuj mapowanie konta z kontem bez uprawnień administratora przed udzieleniem dostępu wszystkim użytkownikom.
Ustaw następujące wartości w środowisku dla wdrożenia oCIS. Przykład zakłada protokół HTTPS i domenę Keycloak w /realms/team. Użyj własnych adresów URL. Ten blok w stylu YAML ma charakter poglądowy; Docker Compose, Kubernetes, systemd i inne metody wdrażania wyrażają zmienne środowiskowe w różny sposób.
OCIS_URL: https://cloud.example.com
OCIS_OIDC_ISSUER: https://sso.example.com/realms/team
PROXY_OIDC_REWRITE_WELLKNOWN: "true"
WEB_OIDC_CLIENT_ID: web
PROXY_USER_OIDC_CLAIM: preferred_username
OCIS_EXCLUDE_RUN_SERVICES: idpOCIS_OIDC_ISSUERWybiera zewnętrznego dostawcę tożsamości. PROXY_OIDC_REWRITE_WELLKNOWN=truePowoduje, że serwer proxy przepisuje punkt końcowy wykrywania OpenID Connect do skonfigurowanego wystawcy; ownCloud dokumentuje to jako konieczne, aby jego klienci stacjonarni i mobilni mogli wykryć dostawcę. WEB_OIDC_CLIENT_IDMusi być zgodny z klientem Keycloak. Wykluczenie idpjest zgodne z przykładem Keycloak ownCloud, więc wbudowany dostawca nie jest uruchamiany jako aktywny dostawca logowania.
Jeśli chcesz, aby oCIS tworzył konta przy pierwszym pomyślnym logowaniu, ustaw PROXY_AUTOPROVISION_ACCOUNTS=truei skonfiguruj usługę Graph z włączonym zapisem użytkownika. Ustaw PROXY_USER_OIDC_CLAIMi PROXY_AUTOPROVISION_CLAIM_USERNAMEna to samo oświadczenie; dla atrybutu username, dokumenty ownCloud PROXY_USER_CS3_CLAIM=usernamedla tego przepływu. Automatyczne provisionowanie jest opcjonalne i powinno być testowane niezależnie od uwierzytelniania. Nie włączaj tej opcji, chyba że przychodzące oświadczenia są unikalne i mapowane zgodnie z przeznaczeniem.
Infinite Scale korzysta z polityki bezpieczeństwa treści (CSP) do kontrolowania, z którymi zewnętrznymi źródłami może się kontaktować jego klient internetowy. Dokumentacja ownCloud informuje, że zewnętrzny dostawca tożsamości, taki jak Keycloak, wymaga odpowiedniej definicji CSP. Jeśli przycisk logowania pojawia się, ale przeglądarka blokuje żądanie, sprawdź konsolę przeglądarki pod kątem błędów CSP. Skonfiguruj politykę za pośrednictwem PROXY_CSP_CONFIG_FILE_LOCATIONi zezwalaj tylko na źródło Keycloak oraz dyrektywy wymagane przez wdrożenie. Po zmianie pliku uruchom ponownie serwer proxy lub wdrożenie. Nie rozwiązuj problemu z połączeniem, zezwalając na każde źródło.
Zastosuj zmiany środowiskowe i uruchom ponownie wdrożenie oCIS, używając metody, której używasz do zarządzania nim. Nie ma uniwersalnego polecenia restartu: projekt Compose, obciążenie Kubernetes i usługa systemd mają różne ustawienia. Następnie sprawdź każde ogniwo w łańcuchu:
issuer, authorization_endpoint, token_endpointi jwks_uri.
| Objaw | Pierwsza kontrola |
|---|---|
| Niezgodność wystawcy lub nieprawidłowy token | Porównaj OCIS_OIDC_ISSUERznak po znaku z wartością dokumentu odkrycia issuer. |
| Błąd przekierowania URI w Keycloak | Sprawdź, czy prawidłowe przekierowania i adresy URL po wylogowaniu klienta są zgodne z rzeczywistym publicznym adresem URL ownCloud, w tym protokołem HTTPS i ścieżką. |
| Logowanie działa w przeglądarce, ale nie na komputerze stacjonarnym ani w kliencie mobilnym | Potwierdź PROXY_OIDC_REWRITE_WELLKNOWN=truei sprawdź odpowiedź wykrywania dostarczoną pod adresem URL ownCloud. |
| Konsola przeglądarki zgłasza zablokowane żądania | Przejrzyj CSP i zezwól na pochodzenie Keycloak za pomocą wymaganych dyrektyw. |
| Użytkownik loguje się, ale widzi błąd konta lub duplikat | Sprawdź deklarację nazwy użytkownika, jej wartość w tokenie lub odpowiedzi z informacjami o użytkowniku oraz mapowanie na istniejące konto. |
| Żądania TLS lub wykrywania nie powiodły się z serwera | Sprawdź DNS, routing odwrotnego serwera proxy, zaufanie łańcucha certyfikatów i czy host oCIS może dotrzeć do Keycloak. |
latestznaczniku zmiennym.Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
