Hoppa till innehåll

Konfiguration: Autentisering och RBAC

Följ det sidspecifika arbetsflödet för Konfiguration: Autentisering och RBAC. Den här proceduren använder /api/next/auth/status · /api/next/auth/rbac · WebAuthn · 48 h · iOS/iPadOS 16+ · Android 9+ · Argon2id · TOTP.

Den här sidan gäller endast Konfiguration: Autentisering och RBAC (webb). Kanal- och datagränserna är: DiscVault · ghcr.io/helmerznl/discvault:latest; WebAuthn; en passkey är ett kryptografiskt nyckelpar: den privata nyckeln stannar på enheten eller i en betrodd uppgiftshanterare och DiscVault lagrar bara den offentliga nyckeln; DiscVault · ghcr.io/helmerznl/discvault:beta; WebAuthn; TOTP. Sidspecifika kontrollpunkter: /api/next/auth/status · /api/next/auth/rbac · WebAuthn · 48 h · iOS/iPadOS 16+ · Android 9+ · Argon2id · TOTP.

  • DiscVault · ghcr.io/helmerznl/discvault:latest
  • WebAuthn
  • en passkey är ett kryptografiskt nyckelpar: den privata nyckeln stannar på enheten eller i en betrodd uppgiftshanterare och DiscVault lagrar bara den offentliga nyckeln
  • DiscVault · ghcr.io/helmerznl/discvault:beta
  • WebAuthn
  • TOTP
  1. Kontrollera: en passkey är ett kryptografiskt nyckelpar: den privata nyckeln stannar på enheten eller i en betrodd uppgiftshanterare och DiscVault lagrar bara den offentliga nyckeln
  2. Jämför: passkeys är nätfiskeresistenta och unika för webbplatsen; inloggning använder enhetens upplåsning i stället för ett återanvändbart kontolösenord · en tidsbegränsad inbjudningskod startar registreringen men är inte ett återanvändbart kontolösenord; vanlig inloggning använder en passkey
  3. Verifiera: Windows kräver en aktuell webbläsare med passkey-stöd och Windows Hello med minst en PIN-kod; Windows 11 22H2 eller senare rekommenderas för inbyggd hantering
  4. Verifiera: macOS kräver Ventura 13 eller senare med iCloud-nyckelring, eller en annan uppgiftshanterare med passkey-stöd
  5. Verifiera: iPhone och iPad kräver iOS eller iPadOS 16+ med iCloud-nyckelring och tvåfaktorsautentisering; Android kräver version 9+ med en passkey-leverantör och skärmlås
  6. Skapa: registrera mer än en passkey, exempelvis på telefon och dator, och behåll en oberoende återställningsväg för ägaren innan en enhet byts ut eller tappas bort
  7. Öppna: Administration → Säkerhet → Aktivera autentisering
  8. Skapa: Administration → Användare → Skapa 48-timmarsinbjudan
  9. Konfigurera: Administration → Roller → Grundläggande / Avancerat
  10. Konfigurera: på en befintlig installation aktiveras lösenordsinloggning under Användare och roller och godkänns med en ny passkey-bekräftelse från ägare eller administratör · ägare och administratörer kan utfärda tillfälliga lösenord, kräva byte, ange MFA per användare och styra passkey-registrering
  11. Anteckna: återställningskoder är hashade, för engångsbruk och delas med passkey-återställning; backup saknar TOTP-hemligheter och återställningsmaterial, så MFA registreras igen · avstängning av Legacy Authentication kräver en aktiv ägar-passkey; en ägare med endast lokal IP måste först upprätta giltigt FQDN och ägar-passkey
  12. Testa: /api/next/auth/rbac
Terminal window
curl --fail http://localhost:6080/api/next/auth/status
curl --fail http://localhost:6080/api/next/auth/rbac
Terminal window
curl --fail http://localhost:6180/api/next/auth/status
curl --fail http://localhost:6180/api/next/auth/rbac

Godkänn resultatet för Konfiguration: Autentisering och RBAC endast när alla resultat nedan stämmer: ägarens passkey-inloggning fungerar, inbjudningsregistrering följer inställningen och testanvändaren har endast tilldelade behörigheter; passkeys är nätfiskeresistenta och unika för webbplatsen; inloggning använder enhetens upplåsning i stället för ett återanvändbart kontolösenord; en tidsbegränsad inbjudningskod startar registreringen men är inte ett återanvändbart kontolösenord; vanlig inloggning använder en passkey. Sidspecifika kontrollpunkter: /api/next/auth/status · /api/next/auth/rbac · WebAuthn · 48 h · iOS/iPadOS 16+ · Android 9+ · Argon2id · TOTP.

  • ägarens passkey-inloggning fungerar, inbjudningsregistrering följer inställningen och testanvändaren har endast tilldelade behörigheter
  • passkeys är nätfiskeresistenta och unika för webbplatsen; inloggning använder enhetens upplåsning i stället för ett återanvändbart kontolösenord
  • en tidsbegränsad inbjudningskod startar registreringen men är inte ett återanvändbart kontolösenord; vanlig inloggning använder en passkey

Konfiguration: Insticksprogram och metadata