Ștergeți în siguranță avertismentul ownCloud Apache .htaccess
Setați AllowOverride All doar pentru rădăcina web a ownCloud, validați vhost-ul Apache activ și reîncărcați în siguranță pentru a restaura regulile .htaccess.
Adesea, utilizatorii ajung pe o pagină de conectare Keycloak, se autentifică și apoi revin la ecranul de conectare ownCloud Infinite Scale sau văd o eroare de tip „utilizator necunoscut”. Cauzele obișnuite sunt un emitent de realm care nu corespunde, un client web copiat dintr-o altă versiune exemplu sau o revendicare de identitate care nu corespunde unui cont oCIS. Configurați Keycloak ca furnizor extern OpenID Connect (OIDC) al oCIS, aliniați aceste trei valori și verificați dacă browserul și clienții pot accesa furnizorul prin HTTPS.
Această demonstrație folosește gazde fictive: cloud.example.compentru oCIS și sso.example.compentru Keycloak. Configurația face referire la documentația ownCloud Infinite Scale 8.2; comparați numele cu documentația pentru versiunea instalată înainte de a le aplica. Aceasta este pentru Infinite Scale (oCIS), nu pentru ownCloud Server 10.
Un furnizor de identitate (IdP) autentifică utilizatorii pentru un alt serviciu. OpenID Connect este protocolul de conectare care permite oCIS să aibă încredere în informațiile de conectare și identitate ale Keycloak. O realm este setul separat de utilizatori, clienți și setări al Keycloak. Alegeți realm-ul care va deservi oCIS, apoi identificați adresa URL a emitentului: pentru exemplul realm ocis, este https://sso.example.com/realms/ocis.
Înainte de a edita oCIS, deschideți https://sso.example.com/realms/ocis/.well-known/openid-configurationîntr-un browser. Acest document de descoperire OpenID Connect descrie punctele finale ale furnizorului. Confirmați că issuervaloarea sa se potrivește exact cu adresa URL a realmului, inclusiv schema, gazda, scrierea cu majuscule și calea. Emitentul nu trebuie să fie pagina de administrare sau adresa URL de descoperire mai lungă. Certificatul TLS al furnizorului trebuie să fie considerat de încredere de către browserele utilizatorilor și de către serverul/containerul oCIS.

Dacă adresa URL de descoperire nu se încarcă, rezolvați mai întâi problemele legate de DNS, rutare reverse-proxy, firewall sau certificat. Un răspuns reușit al browserului nu dovedește că containerul oCIS poate ajunge la Keycloak; verificați și accesul la rețea din rețeaua de implementare a serverului. Regulile de descoperire OpenID Connect impun emitentului returnat să identifice același furnizor. Consultați specificația OpenID Connect Discovery .
Folosește exemplul de implementare ownCloud Keycloak întreținut ca punct de plecare și potrivește fișierul său realm cu versiunea oCIS. Nu amesteca versiunile: exemplul de compunere curent folosește ID-ul clientului web web, în timp ce notele de configurare mai vechi spun [ ocis-webnumele de utilizator]. Keycloak și oCIS trebuie să utilizeze același ID de client.
În Keycloak, deschideți realmul și clientul web selectate. Potriviți fluxul de conectare și ID-ul clientului cu exemplul ownCloud. Setați URI-uri de redirecționare valide la adresele exacte de apel invers necesare realmului respectiv, utilizând gazda HTTPS publică. Setați originile web doar așa cum este necesar în șablon. Caracterul wildcard de mai jos este ilustrativ, nu o recomandare de producție: modelele largi de redirecționare pot permite destinații neintenționate. Etichetele variază în funcție de versiunea Keycloak.

Mențineți stabil numele public de gazdă al Keycloak. Dacă TLS se termină la un proxy invers, configurați numele său public de gazdă și anteturile proxy de încredere, altfel redirecționările pot utiliza o schemă sau o gazdă greșită; urmați instrucțiunile pentru proxy-ul invers Keycloak . Înlocuiți acreditările de administrator demo înainte de a expune Keycloak.
Adăugați aceste variabile la serviciul oCIS în configurația de implementare, păstrând celelalte setări și secrete. Exemplul utilizează adrese URL fictive și ID-ul client actual ca exemplu:
OCIS_URL=https://cloud.example.com
OCIS_OIDC_ISSUER=https://sso.example.com/realms/ocis
WEB_OIDC_CLIENT_ID=web
PROXY_OIDC_REWRITE_WELLKNOWN=true
OCIS_EXCLUDE_RUN_SERVICES=idp
OCIS_URLeste adresa publică oCIS; emitentul și ID-ul clientului trebuie să corespundă exact cu Keycloak. Rescrierea activează calea de descoperire utilizată de clienții desktop, Android și iOS. Excluderea idpoprește furnizorul încorporat în implementările IdP externe; omiteți-o dacă configurația utilizează intenționat acel serviciu.

Aplicați modificările prin procesul normal de repornire al implementării. Cu Docker Compose, rulați docker compose up -ddin directorul compose pentru a recrea serviciile modificate, apoi revizuiți jurnalele oCIS. Utilizați certificate TLS de încredere în producție. Exemplul ownCloud marchează INSECURE=trueca opțiune locală de auto-certificat; eliminați-o sau setați-o la fals pe un server cu acces la internet. ownCloud spune, de asemenea, să nu se utilizeze PROXY_OIDC_INSECUREîn producție.
O revendicare este un câmp de identitate OIDC, cum ar fi sub, preferred_username, sau email. oCIS o folosește pentru a găsi un cont. Pentru utilizatorii existenți, mapați-o la atributul pe care îl folosesc deja - nume de utilizator, e-mail sau ID utilizator. O nepotrivire poate produce mesajul „utilizator negăsit” după ce Keycloak acceptă autentificarea.
Pentru a crea conturi la prima autentificare, setați-le PROXY_AUTOPROVISION_ACCOUNTS=truedoar atunci când este necesar și după activarea scrierilor în backend-ul utilizatorului oCIS Graph. Identificatorul trebuie să fie unic, stabil și să nu fie reatribuit niciodată. ownCloud se identifică subca fiind potrivit; utilizați adresa de e-mail sau numele de utilizator preferat numai dacă nu se poate schimba. Mențineți aliniate cererile de creare și căutare:
PROXY_AUTOPROVISION_ACCOUNTS=true
PROXY_AUTOPROVISION_CLAIM_USERNAME=sub
PROXY_USER_OIDC_CLAIM=sub
PROXY_USER_CS3_CLAIM=username
Confirmați că Keycloak returnează revendicarea aleasă în token sau în răspunsul userinfo. Cu aprovizionarea automată dezactivată, nu se creează un utilizator nou la conectare; cu un backend Graph doar pentru citire, aprovizionarea poate eșua. Adăugați maparea grupurilor sau rolurilor numai după ce conectarea funcționează. Consultați documentația ownCloud 8.2 pentru proxy și aprovizionarea automată înainte de a activa accesul la scriere sau de a modifica mapările de identitate.
Deschideți oCIS într-o fereastră privată a browserului și conectați-vă. Ar trebui să ajungeți în zona Keycloak, să vă autentificați și să reveniți la aceeași gazdă oCIS ca și contul așteptat. Testați mai întâi un cont existent. Dacă este activată furnizarea, testați un utilizator nou aprobat și confirmați că este creat o singură dată cu numele de utilizator dorit. Deconectați-vă și repetați conectarea.

Pentru descoperirea pe desktop sau mobil, deschideți https://cloud.example.com/.well-known/openid-configuration; rescrierea ar trebui să expună informațiile despre furnizorul Keycloak. O buclă de conectare indică o nepotrivire a gazdei de redirecționare sau a schemei. Un utilizator respins după o conectare reușită indică o revendicare lipsă sau o nepotrivire între PROXY_USER_OIDC_CLAIMși PROXY_USER_CS3_CLAIM.
Setați AllowOverride All doar pentru rădăcina web a ownCloud, validați vhost-ul Apache activ și reîncărcați în siguranță pentru a restaura regulile .htaccess.
Activați aplicația Enterprise Auditing a ownCloud, direcționați evenimentele admin_audit către un fișier jurnal protejat și confirmați că acțiunile reale ale utilizatorilor sunt înregistrate.
Aliniați emitentul realm-ului Keycloak, clientul web și revendicările utilizatorului pentru a permite ownCloud Infinite Scale să conecteze utilizatorii în mod fiabil pe clienții web și mobili.
Transferă fișierele deținute și partajările de ieșire cu comanda occ din ownCloud, înțelege ce rămâne în urmă și verifică accesul înainte de a șterge contul vechi.
Află când necesită atenție indexurile bazei de date ownCloud 10, cum să aplici în siguranță actualizările schemei acceptate și când optimizarea interogărilor sau o modificare a bazei de date reprezintă cea mai bună soluție.
Conectați o partajare de rețea Windows sau Samba la ownCloud prin intermediul spațiului de stocare extern, verificați acreditările și depanați în siguranță folderele inaccesibile.
Eliminați fiecare versiune de fișier ownCloud Server Classic stocată pentru un cont sau pentru toți utilizatorii și faceți diferența între o eliminare completă și o expirare bazată pe retenție.
Urmăriți un refuz al conexiunii mobile ownCloud verificând adresa URL a serverului, rețeaua telefonică, endpoint-ul HTTPS și jurnalele serverului în ordinea corectă.
Înlocuiți rularea joburilor la cerere cu un cronometru systemd care rulează comanda occ system:cron acceptată de ownCloud la fiecare 15 minute.
Urmăriți cererea WebDAV prin Apache, Nginx sau un proxy invers, apoi confirmați că sincronizarea ownCloud funcționează cu un test PROPFIND autentificat.