Paroolivaba SSO Notakeyga: samm-sammuline seadistusjuhend

Selle juhendi lõpuks logivad teie kasutajad rakendusse sisse telefonikinnitusega: sisestavad kasutajanime või skannivad QR-koodi ning kinnitavad Notakey rakenduses. Sisselogimislehel parooli ei ole. Parool ise ei kao kuhugi, aga tal on täpselt üks kohustuslik ülesanne: seda küsitakse ühe ainsa korra, seadme registreerimisel, kasutaja võtme loomiseks. Kõik pärast seda on teie poliitikaotsus — ja see juhend näitab täpselt, kust iga poliitika üles leiate.

Iga Notakey teenus — needsamad, mida juba kasutate VPN-i, Windowsi või Wi-Fi kahefaktorilise autentimise jaoks — oskab toimida ka OpenID Connect’i pakkujana. Selleks pole vaja eraldi toodet: minge haldusliidesesse, lülitage teenusel OIDC sisse, registreerige seda kasutav rakendus kliendina ja suunake see Notakey antud lõpp-punktidele. Ei mingeid SAML-sertifikaate, ei mingit eraldi identiteedipakkuja serverit, mida käigus hoida.

your app ──OIDC──▶ Notakey service (OIDC provider)
                        │
                        ├──▶ user repository: onboarded devices in this service
                        └──▶ push ──▶ user's phone: read, approve

(Klassikalised, ainult SAML-i toetavad ettevõtterakendused — Google Workspace, AWS — vajavad hoopis Notakey eraldi SAML identiteedipakkujat; kust seda leida, vaadake viimasest osast.)

Kuidas parool siin tegelikult toimib

Tasub täpne olla, sest sõna „paroolivaba“ visatakse tihti õhku ilma lahti seletamata:

• Ainus kohustuslik parool on liitumisel. See on määratud haldusliideses või pärineb Active Directory’st ning seda kontrollitakse üks kord — kui kasutaja registreerib oma seadme ja telefoni turvakiibis luuakse tema võti.
• Igapäevasel sisselogimisel parooli pole. Kasutaja sisestab kasutajanime või skannib QR-koodi — sisselogimislehe võib taandada puhtalt skannimisele, ilma ühegi väljata, kuhu üldse midagi trükkida. Identiteeti tõendab allkirjastatud kinnitus rakenduses.
• Kõik ülejäänu on seadistus, mitte reegel. Üks rakendus võib nõuda täiendavat kinnitust rakenduses, teine parooli, kolmas mõlemat. Parooli võib ka aeg-ajalt uuesti küsida, et see täiesti meelest ei läheks. Kõik see on koos ühel seadistusekraanil, mida kirjeldab allpool 5. samm.

1. samm – valige teenus

Kasutage olemasolevat Notakey teenust, kui selle kasutajaskond juba kattub rakendusega, mida ühendate, või looge uus (Services → Manage → New), kui soovite sellele rakendusele oma, muust sõltumatut paroolipoliitikat. 5. sammu poliitika kehtib kogu teenusele, mitte üksikule kliendile — see ongi otsustav tegur, kumba valida.

2. samm – lülitage OpenID Connect sisse

Avage teenus, seejärel OpenID Connect configuration → Configure ja märkige Enabled. Jätke ülejäänu praegu vaikeväärtustele — Require password ja Require mfa seadistate teadlikult 5. sammus, mitte kogemata siin. Salvestage.

3. samm – kopeerige lõpp-punktid

Minge tagasi OpenID Connect configuration juurde ja klõpsake Show. Notakey on juba loonud discovery-dokumendi ja selle taga olevad üksikud lõpp-punktid:

https://<your-dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration

Enamikule OIDC-d toetavale tarkvarale piisab sellest ühest URL-ist: kleepige see „auto discovery“ või „issuer“ väljale ja rakendus laeb ise nii authorization-, token-, userinfo- kui JWKS-lõpp-punkti. <access-id> on sama ID, mis on näidatud teenuse enda lehel.

4. samm – registreerige rakendus kliendina

Teenuse all minge OpenID Connect configuration → Clients → New client. Notakey genereerib teile Client ID ja juhusliku Secreti.

Enne salvestamist tasub teada kahte asja. Secret-väli on maskeeritud ja kui liigute lehelt eemale, ei näita Notakey seda enam kordagi — kopeerige see kohe, või valige väli ja kleepige asemele oma valitud saladus, mis töötab täpselt sama hästi ja on hiljem lihtsam ära tunda. Ja Redirect URIs väli peab klapima tähemärgi täpsusega URL-iga, mille rakendus sisselogimisel tagasi saadab — juba ainuüksi puuduv kaldkriips lõpus piisab, et kõik katki läheb (vaata allpool olevat nüanssi).

Täitke:

• Description — mis iganes aitab teil seda hiljem ära tunda.
• Secret — kopeerige genereeritud väärtus või kirjutage see oma omaga üle.
• Redirect URIs — rakenduse OAuth tagasikutse URL. Kui rakendus on saadaval mitmel aadressil, eraldage need komadega.
• Logout URI — kuhu brauser pärast väljalogimist suunata. Valikuline.

Kui olete registreerinud paar rakendust, näeb teenuse klientide loend välja selline:

5. samm – suunake rakendus Notakeyle

Täpsed sammud sõltuvad rakendusest, aga kuju on alati sama: issuer- või discovery-URL, kliendi ID, kliendisaladus. Kaks läbitud näidet reaalsetest ise majutatud tööriistadest:

Giteal on selle jaoks olemas käsurea käsk — pole vaja veebivormi ega taaskäivitust:

gitea admin auth add-oauth \
  --name notakey \
  --provider openidConnect \
  --key <client-id> \
  --secret <client-secret> \
  --auto-discover-url https://<dashboard-host>/oidc/services/<access-id>/.well-known/openid-configuration \
  --scopes openid --scopes profile --scopes email

Gitea sisselogimislehele ilmub kohe nupp „Sign in with notakey“, olemasoleva paroolivormi kõrvale — midagi ei kao ära.

Proxmox VE käsitleb seda autentimisalana (realm), mis lisandub olemasolevatele, mitte ei asenda neid:

pveum realm add notakey --type openid \
  --issuer-url https://<dashboard-host>/oidc/services/<access-id> \
  --client-id <client-id> \
  --client-key <client-secret> \
  --username-claim sub \
  --scopes "openid email profile" \
  --autocreate 1

--issuer-url on siin discovery-URL, millelt on maha võetud /.well-known/openid-configuration saba — Proxmox lisab selle ise. --autocreate 1 loob esimesel õnnestunud sisselogimisel vastava Proxmoxi kasutaja, kellel pole algul mitte ühtegi õigust, enne kui te need selgesõnaliselt annate; kellelegi ei anta õigusi kogemata.

6. samm – seadistage paroolipoliitika

Siin muutub „administraatori valik“ konkreetseks, tagasi lehel OpenID Connect configuration → Configure:

• Require password märkimata ja Require mfa märgitud: see ongi juhendi alguses kirjeldatud paroolivaba voog. Sisselogimiseks piisab kasutajanimest (või QR-koodist) ja telefonikinnitusest, muud pole vaja.
• Require password märgitud ja Password cache väärtusega 0: parool küsitakse iga kord, lisaks kinnitusele — klassikaline kahefaktoriline.
• Require password märgitud koos Password cache väärtusega sekundites (näiteks 2592000 ehk 30 päeva): igapäevaselt paroolivaba, parooli küsitakse uuesti alles siis, kui see ajaaken on täis saanud — ainult selleks, et parool ei läheks päris meelest. Mfa cache töötab samamoodi kinnitussammu jaoks, kui soovite kunagi ka seda vahemällu jätta.

Kuna see seadistus kehtib kogu teenusele, kuulub rakendus, mis vajab teistsugust poliitikat kui naaberrakendused, oma teenusesse — tagasi

1. sammu valiku juurde.

Kui midagi ei tööta

• Viga redirect_uri mismatch tähendab peaaegu alati kaldkriipsu lõpus: mõni rakendus saadab https://app.example.com, mõni https://app.example.com/, ja Notakey võrdleb stringe täht-tähelt. Kontrollige oma nginxi või rakenduse pöördumiste logist, millise sõna-sõnalise redirect_uri= väärtuse rakendus tegelikult saatis, ja registreerige täpselt see.
• Kui discovery-URL annab 404, kontrollige üle, kas Enabled 2. sammus tegelikult salvestus — kõige levinum viga on seadistusleht, mis näeb õige välja, aga mida ei ole kunagi salvestatud.
• Teenuse alt leitav Authentication activities logi näitab iga katset, mis Notakeyni jõudis. Kui katset seal üldse ei ole, ei jõudnudki rakendus authorization-lõpp-punktini — kontrollige kõigepealt kliendi ID-d ja discovery-URL-i.

Mida see juhend teadlikult vahele jätab

Klassikalised SAML 2.0 integratsioonid rakendustele, mis oskavad ainult SAML-i — Google Workspace, AWS ja teised sarnased — käivad läbi Notakey eraldi SAML identiteedipakkuja, mitte ülalkirjeldatud OIDC tee kaudu. Samuti jäävad sellest juhendist välja LDAP/Active Directory kasutajaallikana, multi-tenant seadistused ja kohandatud kujundus. Kõik see on täielike parameetritabelitega kirjas CLI ja API viites; see juhend on aga kiireim tee nullist toimiva paroolivaba sisselogimiseni.

Vaadake seda enne, kui hakkate ehitama

Kiireim viis sisselogimiskogemuse üle otsustada on kinnitusvoog ise läbi teha: proovige elavat demo ja allkirjastage üks päring oma telefonist umbes kahe minutiga, või küsige demo ja me kaardistame teie rakendused ning paroolipoliitika pilootprojektiks teie enda taristul.