Pentru a solicita autentificarea cu doi factori (2FA) pentru conectările la ownCloud Infinite Scale, configurați-o în furnizorul de identitate OpenID Connect (IDP) care autentifică utilizatorii. Pentru multe implementări, aceasta înseamnă activarea parolelor unice bazate pe timp (TOTP) în Keycloak, apoi solicitarea utilizatorilor să se înscrie înainte de a putea finaliza conectarea. Infinite Scale nu oferă un ecran de înscriere TOTP de uz general propriu. IDP-ul său încorporat este minim; ownCloud recomandă utilizarea unui furnizor extern OpenID Connect pentru nevoi de identitate mai ample, iar documentația sa indică Keycloak pentru 2FA.
Exemplu ipotetic: Northstar Design este o companie fictivă cu 40 de persoane, având ownCloud Infinite Scale deja conectată la o zonă Keycloak numită files. Personalul se conectează în prezent cu o parolă. Administratorul dorește ca aceștia să înscrie o aplicație de autentificare și să utilizeze un cod la următoarea autentificare. Acest exemplu este ilustrativ, nu un raport al unei instalări sau testări reale. Pașii de mai jos presupun că Keycloak este deja IDP-ul utilizat de Infinite Scale; dacă nu este, urmați mai întâi instrucțiunile oficiale de implementare pentru conectarea celor două servicii.
Imaginile de interfață din acest ghid sunt exemple conceptuale, nu capturi de ecran dintr-un sistem Northstar sau ownCloud live. Formularea și aspectul meniului pot diferi în funcție de versiunile Keycloak. Instrucțiunile au fost verificate în raport cu documentația ownCloud Infinite Scale 8.2 și Ghidul de administrare a serverului Keycloak 26.8 pe 6 octombrie 2026.
OpenID Connect (OIDC) este protocolul de conectare care permite Infinite Scale să se bazeze pe un IDP, în loc să autentifice fiecare parolă în sine. Keycloak solicită acreditările principale și, atunci când fluxul său de autentificare o necesită, un al doilea factor, cum ar fi TOTP. Infinite Scale primește apoi autentificarea OIDC rezultată. Un TOTP este un cod de scurtă durată generat dintr-un secret partajat și ora curentă; o aplicație de autentificare stochează secretul atunci când un utilizator scanează codul QR de înscriere.
Această separare contează. Setarea unei politici OTP în Keycloak schimbă modul în care Keycloak autentifică utilizatorii. Setarea unei opțiuni ownCloud MFA nu înscrie un telefon și nu creează o acreditare TOTP. În special, OCIS_MFA_ENABLEDopțiunea ownCloud este pentru autentificarea intensificată pe anumite rute protejate atunci când IDP-ul acceptă revendicarea OpenID Connect Authentication Context Class Reference (ACR). Nu este un comutator care adaugă o solicitare TOTP universală la fiecare conectare.
În exemplul Northstar, administratorul confirmă că clientul web este deja redirecționat către filesrealm-ul de la https://login.example.test/realms/files. Exemplul de implementare ownCloud utilizează setări precum OCIS_OIDC_ISSUER, WEB_OIDC_CLIENT_ID, și, în configurația Keycloak, PROXY_OIDC_REWRITE_WELLKNOWN. Acestea sunt valori de configurare a implementării, nu câmpuri pe care utilizatorii obișnuiți le modifică în interfața web Infinite Scale.
Dacă instanța dvs. utilizează în continuare IDP-ul încorporat, planificați separat integrarea Keycloak înainte de a impune OTP. Conectarea unui IDP extern implică mai mult decât introducerea unei adrese URL a emitentului: înregistrarea clientului, redirecționarea și configurarea originii web, revendicările de token-uri, HTTPS și clienții desktop sau mobili utilizați trebuie să fie de acord. Folosiți exemplul de implementare Keycloak întreținut de ownCloud ca punct de plecare pentru versiunea și topologia dvs. exacte.
Deschideți zona fișierelor în Consola de administrare Keycloak și accesați Autentificare , apoi Politică , apoi Politică OTP . Alegeți o politică bazată pe timp (TOTP) pentru aplicațiile de autentificare. Keycloak acceptă, de asemenea, HOTP bazat pe contor, dar TOTP este opțiunea obișnuită pentru aplicațiile de autentificare pentru telefoane, deoarece codurile se schimbă în timp.
Revizuiți politica înainte de implementare. Keycloak expune setări precum algoritmul hash, lungimea codului, fereastra de abatere a ceasului, perioada tokenului și dacă un cod poate fi reutilizat. Începeți cu valorile acceptate de autentificatoarele pe care le au utilizatorii dvs. O fereastră de ceas mai mare poate ajuta la abaterea ceasului, dar extinde și intervalul în care un cod poate fi acceptat. Mențineți ceasul serverului sincronizat și evitați lărgirea acestei ferestre ca înlocuitor pentru remedierea sincronizării timpului.
În Autentificare > Acțiuni necesare , asigurați-vă că opțiunea Configurare OTP este activată și marcați-o ca acțiune implicită. Documentația Keycloak precizează că se aplică o acțiune obligatorie implicită atunci când un utilizator nou se conectează pentru prima dată. Aceasta creează o cerință de înscriere; utilizatorul trebuie totuși să finalizeze configurarea înainte ca o acreditare TOTP să existe.
Verificați și fluxul de autentificare a browserului. În fluxul standard Keycloak al browserului, subfluxul 2FA condiționat solicită OTP atunci când utilizatorul respectiv are configurate acreditări OTP. Dacă utilizatorii nu sunt obligați să configureze OTP, aceștia pot continua fără o solicitare pentru al doilea factor. Păstrați parola normală sau pasul pentru primul factor și testați fluxul cu atenție înainte de a lega un flux personalizat. Modificările fluxului de autentificare afectează întregul domeniu și pot bloca accesul administratorilor dacă sunt configurate greșit.
O acțiune implicită nu este retroactivă pentru conturile care există deja. Pentru personalul actual al Northstar, administratorul deschide fiecare utilizator din domeniul Keycloak și adaugă Configurare OTP sub acțiunile necesare ale utilizatorului respectiv, apoi salvează modificarea. Keycloak documentează, de asemenea, o opțiune sub fila Acreditări a unui utilizator pentru a trimite un e-mail de resetare a acreditărilor care direcționează utilizatorul către configurarea OTP. Alegeți metoda care se potrivește procesului dvs. de gestionare a contului și verificați dacă utilizatorii pot primi e-mailul dacă îl utilizați.
Pentru un director mare, planificați un proces controlat în bloc folosind o interfață administrativă sau o automatizare Keycloak acceptată. Nu presupuneți că activarea acțiunii implicite a înscris pe toată lumea. Creați un utilizator de test și inspectați comportamentul așteptat la prima conectare înainte de a aplica politica pe scară largă.
Când Alex, un angajat fictiv al Northstar, se conectează din nou la ownCloud și este redirecționat către Keycloak, Keycloak îi cere lui Alex să configureze OTP-ul. Alex deschide o aplicație de autentificare, scanează codul QR afișat de Keycloak și introduce codul curent din aplicație pentru a confirma înscrierea. Codul QR conține secretul TOTP, așa că utilizatorii ar trebui să îl trateze ca pe o acreditare: nu îl trimiteți unui administrator prin e-mail, nu îl salvați într-un tichet partajat și nu îl scanați pe un dispozitiv neîncrezător.
Dacă aplicația nu poate scana codul, pagina de configurare Keycloak poate oferi cheia subiacentă ca introducere manuală. Utilizatorii ar trebui să stocheze cheia respectivă doar în autentificator. Aceștia ar trebui să finalizeze pasul de verificare înainte de a închide pagina de configurare. Un cod care nu trece de validare poate fi învechit, scris greșit sau generat de o aplicație cu o oră de ceas incorectă a dispozitivului.
Utilizatorii au nevoie de o modalitate de a recupera accesul dacă un telefon este pierdut, înlocuit sau șters. Keycloak 26.8 documentează Codurile de Autentificare pentru Recuperare ca o acreditare suplimentară care poate fi activată și adăugată ca alternativă în fluxul browserului. Dacă versiunea și domeniul Keycloak utilizează această funcție, activați-o și testați-o în mod deliberat. Utilizatorii ar trebui să stocheze codurile de recuperare într-un manager de parole aprobat sau într-o altă locație offline protejată și să trateze fiecare cod ca fiind sensibil. Nu le stocați în aceeași aplicație de telefon care deține secretul TOTP.
Dacă codurile de recuperare nu sunt activate în zona dvs. de realizare, documentați o procedură de recuperare condusă de administrator. Solicitați verificarea identității înainte de resetarea sau eliminarea unei acreditări OTP. Păstrați un cont de administrator break-glass sub un proces separat, strict controlat, astfel încât o problemă de înscriere a utilizatorului să nu devină o blocare la nivelul întregii zone de realizare.
După înscriere, deconectați-vă din contul de testare și conectați-vă din nou la adresa Infinite Scale normală. Confirmați că browserul ajunge la realmul Keycloak așteptat, acceptă parola contului, solicită codul bazat pe timp și returnează utilizatorul la ownCloud după autentificarea cu succes. Apoi, testați clienții desktop și mobili acceptați, linkurile partajate și orice instrumente operaționale care se bazează pe același furnizor de identitate.
Un test de browser reușit nu dovedește că fiecare client sau protocol folosește același flux. Fluxul de browser al Keycloak poate să nu acopere un flux separat de acordare directă, iar o sesiune Keycloak single sign-on (SSO) existentă poate satisface o conectare ulterioară la ownCloud fără a afișa o altă solicitare OTP. Aceasta este reutilizarea așteptată a sesiunii, nu dovada că factorul este încălcat. Dacă politica necesită un factor proaspăt mai des, revizuiți setările SSO și de nivel de autentificare ale Keycloak ca parte a unei politici de sesiune deliberate.
Unele implementări doresc un al doilea factor doar atunci când utilizatorii deschid o resursă sensibilă. Infinite Scale acceptă autentificarea pas cu pas la nivel de rută prin solicitări ACR OIDC. În documentația 8.2, OCIS_MFA_ENABLEDactivează aplicarea și OCIS_MFA_AUTH_LEVEL_NAMESdenumește nivelul ACR care semnifică MFA. IDP-ul trebuie să accepte autentificarea pas cu pas și să emită valoarea ACR corespunzătoare în token. Keycloak are configurație la nivel de autentificare și ACR pentru acest model, dar fluxul, nivelul solicitat și maparea token-urilor trebuie să corespundă cu valoarea configurată în Infinite Scale.
OCIS_MFA_ENABLED=true
OCIS_MFA_AUTH_LEVEL_NAMES=advancedAcest exemplu este doar un punct de plecare: utilizați-l advancednumai dacă Keycloak este configurat să returneze valoarea ACR după factorul necesar. Dacă se solicită o rută protejată fără nivelul necesar, Infinite Scale poate refuza accesul și returna un răspuns 403 cu un X-OCIS-MFA-Requiredantet. Step-up-ul la nivel de rută este diferit de solicitarea TOTP în timpul fiecărei noi autentificări Keycloak în browser.
| Simptom | Ce să verificați |
|---|---|
| Nu apare nicio solicitare OTP | Confirmați că înscrierea OTP a contului a fost finalizată, că fluxul browserului invocă pasul OTP pentru utilizatorii configurați și că o sesiune SSO preexistentă nu reutilizează autentificarea. |
| Unui utilizator nou nu i se cere să se înregistreze | Confirmați că opțiunea Configurare OTP este activată și marcată ca acțiune implicită în domeniul corect. Acțiunile implicite se aplică utilizatorilor noi; conturile existente necesită o acțiune obligatorie atribuită. |
| Codul este respins | Confirmați că utilizatorul a ales TOTP, nu HOTP, și verificați ceasurile dispozitivului și serverului. Rugați utilizatorul să aștepte următorul interval de cod și să introducă codul nou. |
| Conectarea de pe desktop, mobil sau automată eșuează | Verificați ce flux OIDC sau alt flux de autentificare utilizează clientul. Testați fiecare client acceptat și asigurați-vă că modificarea nu s-a bazat pe un flux exclusiv de browser pentru o conectare non-browser. |
| Utilizatorii sunt blocați după modificarea fluxului | Folosește procesul de recuperare documentat al administratorului și contul protejat break-glass. Verifică ultima modificare a fluxului realmului înainte de a modifica din nou fluxul implicit. |
Comparați 10 instrumente de scanare ping pentru descoperirea rapidă a rețelelor LAN, scanarea multi-platformă și gestionarea adreselor IP. Aflați ce vă poate spune o scanare (sweep).
Comparați șase instrumente de gestionare a rețelei pentru monitorizarea performanței, inclusiv acoperirea SNMP, maparea, alertele, modelele de implementare și compromisurile de costuri.
Aflați ce înseamnă QoS în rețele, cum marcajele DSCP și cozile de trafic prioritizează aplicațiile vocale, video și de business și ce nu poate remedia QoS.
Compară software-ul de server SFTP fiabil pentru Windows și Linux, inclusiv OpenSSH, Bitvise, SolarWinds și SFTPGo. Găsește soluția potrivită pentru nevoile tale de securitate și transfer de fișiere.
Construiți o monitorizare practică a rețelei cu o acoperire clară a dispozitivelor, indicatori de performanță utili, alerte acționabile și o comparație între SolarWinds NPM, PRTG și OpManager.
Comparați șapte instrumente de gestionare a adreselor IP pentru descoperirea subrețelelor, coordonarea DNS și DHCP, inventarul rețelei și IPAM open-source.
Comparați instrumentele de scanare a rețelei pentru descoperirea rapidă a dispozitivelor, scanări IP pe mai multe platforme și IPAM pentru întreprinderi, cu îndrumări privind potrivirea fiecărei opțiuni la rețeaua dvs.
Folosește opțiunea --traceroute din Nmap pentru a mapa salturi la o gazdă autorizată, a înțelege ieșirea saltului și a RTT-ului și a depana răspunsurile lipsă fără a suprascana.
Comparați șase instrumente de monitorizare Windows Server în funcție de colectarea datelor Windows, vizibilitatea aplicațiilor, modelul de implementare și licențierea pentru a găsi instrumentul potrivit.
Comparați șase instrumente de monitorizare a rețelei Linux pentru descoperirea dispozitivelor SNMP, grafice de interfață, metrici gazdă, verificări de servicii și fluxuri de trafic.
