Beslaptažodis SSO su Notakey: konfigūracijos vadovas žingsnis po žingsnio

Perskaitę šį vadovą įdiegsite tokią sistemą: naudotojas prisijungia prie programos patvirtindamas telefonu — įveda naudotojo vardą arba nuskaito QR kodą, tada patvirtina Notakey programėlėje. Prisijungimo lange slaptažodžio nėra. Jis niekur nedingsta, tačiau turi lygiai vieną privalomą užduotį: jo paprašoma vieną kartą, registruojant įrenginį, kad būtų sugeneruotas naudotojo raktas. Viskas, kas vyksta vėliau, priklauso nuo jūsų pasirinktos politikos nuostatų — ir šis vadovas parodo, kur tiksliai kiekviena iš jų nustatoma.

Kiekviena Notakey paslauga — ta pati, kurią jau naudojate VPN, „Windows“ ar „Wi-Fi“ 2FA — vienu metu gali veikti ir kaip OpenID Connect tiekėjas. Tam nereikia atskiro produkto: valdymo skydelyje įjungiate OIDC konkrečiai paslaugai, užregistruojate programą kaip klientą ir nukreipiate ją į Notakey pateikiamus galutinius taškus. Jokių SAML sertifikatų, jokio atskiro tapatybės tiekėjo serverio, kurį reikėtų administruoti.

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

(Klasikinėms, tik SAML palaikančioms įmonių programoms — „Google Workspace“, AWS — reikia atskiro Notakey SAML tapatybės tiekėjo; kur jį rasti, žr. paskutiniame skyriuje.)

Kaip čia iš tikrųjų veikia slaptažodis

Verta būti tiksliems, nes žodis „beslaptažodis“ dažnai vartojamas be jokio konkretumo:

• Vienintelis privalomas slaptažodis — registracijos metu. Jis nustatomas valdymo skydelyje arba paimamas iš Active Directory, patikrinamas vieną kartą, kai naudotojas registruoja įrenginį, o tuo metu telefono saugioje aparatinėje įrangoje sugeneruojamas jo raktas.
• Kasdieniame prisijungime jo nebėra. Naudotojas įveda naudotojo vardą arba nuskaito QR kodą; prisijungimo langą galima susiaurinti iki vien tik skenavimo — jokio lauko, kur ką nors reikėtų įvesti. Tapatybę patvirtina pasirašytas patvirtinimas programėlėje.
• Visa kita — nustatymas, o ne taisyklė. Viena programa gali reikalauti papildomo patvirtinimo programėlėje, kita — slaptažodžio, trečia — abiejų kartu. Slaptažodžio taip pat galima paprašyti pakartotinai kas tam tikrą laiką, kad žmonės jo visai nepamirštų. Visa tai valdoma viename konfigūracijos ekrane, aprašytame 5 žingsnyje.

1 žingsnis — pasirinkite paslaugą

Naudokite esamą Notakey paslaugą, jei jos naudotojai jau sutampa su prijungiama programa, arba sukurkite naują (Services → Manage → New), jei norite, kad ši programa turėtų savo, nuo visko kito nepriklausomą slaptažodžio politiką. Lemiamas dalykas: 5 žingsnyje nustatoma politika taikoma visai paslaugai, o ne atskiram klientui.

2 žingsnis — įjunkite OpenID Connect

Atidarykite paslaugą, tada eikite į OpenID Connect configuration → Configure ir pažymėkite Enabled. Likusius laukus kol kas palikite numatytuosius — parametrus Require password ir Require mfa sąmoningai nustatysite 5 žingsnyje, o ne atsitiktinai čia. Išsaugokite.

3 žingsnis — nusikopijuokite galutinius taškus

Grįžę į OpenID Connect configuration, spustelėkite Show. Notakey jau sugeneravo discovery dokumentą ir už jo slypinčius atskirus galutinius taškus:

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

Daugumai OIDC palaikančios programinės įrangos pakanka vien šio URL — įklijuokite jį į lauką „auto discovery“ arba „issuer“, ir programa pati susiras authorization, token, userinfo ir JWKS galutinius taškus. <access-id> — tas pats ID, kuris matomas paslaugos puslapyje.

4 žingsnis — užregistruokite programą kaip klientą

Paslaugos viduje eikite į OpenID Connect configuration → Clients → New client. Notakey sugeneruoja Client ID ir atsitiktinį Secret.

Prieš išsaugant verta žinoti du dalykus. Pirma, Secret laukas yra paslėptas, ir išėjus iš puslapio Notakey jo daugiau nebeparodys — todėl nukopijuokite dabar, arba, dar paprasčiau, pažymėkite lauką ir įklijuokite savo pasirinktą slaptą reikšmę, kurią bus lengviau atsekti vėliau. Antra, laukas Redirect URIs turi sutapti raidė į raidę su URL, kurį programa grąžina prisijungimo metu — pakanka vieno pasviro brūkšnio skirtumo gale, kurio programa nesiunčia, kad viskas nustotų veikti (žr. spąstus žemiau).

Užpildykite:

• Description — bet kas, kas vėliau padės ją atpažinti.
• Secret — nukopijuokite sugeneruotą arba perrašykite savo.
• Redirect URIs — programos OAuth callback URL. Jei programa pasiekiama keliais adresais, išvardykite juos atskirdami kableliais.
• Logout URI — kur nukreipti naršyklę atsijungus. Neprivaloma.

Užregistravus kelias programas, paslaugos klientų sąrašas atrodo taip:

5 žingsnis — nukreipkite programą į Notakey

Tikslūs žingsniai priklauso nuo konkrečios programos, tačiau schema visada ta pati: issuer arba discovery URL, client ID, client secret. Štai du pavyzdžiai iš realių savarankiškai talpinamų įrankių:

Gitea tam turi paruoštą CLI komandą — jokios web formos, jokio paleidimo iš naujo:

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 prisijungimo lange iškart atsiranda mygtukas „Sign in with notakey“ šalia jau esamos slaptažodžio formos — niekas nepašalinama.

Proxmox VE tai traktuoja kaip autentifikacijos sritį (realm), papildomą prie jau esamų sričių:

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

Čia --issuer-url yra discovery URL be galūnės /.well-known/openid-configuration — Proxmox ją prisijungia pats. --autocreate 1 po pirmo sėkmingo prisijungimo sukuria atitinkamą Proxmox naudotoją be jokių teisių, kol jų aiškiai nesuteiksite patys — prieigos atsitiktinai ji neišdalins.

6 žingsnis — nustatykite slaptažodžio politiką

Čia „administratoriaus pasirinkimas“ tampa konkretus — grįžkite į OpenID Connect configuration → Configure:

• Require password nepažymėtas, Require mfa pažymėtas: tai šio vadovo pradžioje aprašytas beslaptažodis scenarijus. Prisijungimą sudaro naudotojo vardas (arba QR kodas) ir patvirtinimas telefonu, ir nieko daugiau.
• Require password pažymėtas, Password cache paliktas 0: slaptažodžio prašoma kaskart, papildomai prie patvirtinimo — klasikinis dviejų veiksnių variantas.
• Require password pažymėtas, o Password cache nustatytas sekundėmis (pavyzdžiui, 2592000 — 30 dienų): kasdien beslaptažodis režimas, o slaptažodžio vėl paklausiama pasibaigus nurodytam laikotarpiui — tiesiog tam, kad jis nebūtų visai pamirštas. Mfa cache veikia lygiai taip pat, tik patvirtinimo žingsniui, jei kada nors norėsite kešuoti ir jį.

Kadangi šis nustatymas galioja visai paslaugai, programa, kuriai reikia kitokios politikos nei kaimyninėms, turi turėti savo atskirą paslaugą — grįžtame prie 1 žingsnio pasirinkimo.

Kai kas nors neveikia

• redirect_uri mismatch klaida beveik visada reiškia pasviro brūkšnio skirtumą gale: vienos programos siunčia https://app.example.com, kitos — https://app.example.com/, o Notakey lygina eilutes tiksliai. Nginx ar programos prieigos žurnaluose susiraskite tikslią programos išsiųstą reikšmę redirect_uri= ir užregistruokite būtent ją.
• Jei discovery URL grąžina 404, patikrinkite, ar 2 žingsnyje tikrai buvo išsaugotas Enabled — dažniausia klaida yra konfigūracijos puslapis, kuris atrodo teisingas, bet niekada nebuvo pateiktas.
• Paslaugos žurnalas Authentication activities rodo kiekvieną bandymą, pasiekusį Notakey. Jei bandymo ten visai nėra, programa net nepasiekė authorization galutinio taško — pirmiausia tikrinkite client ID ir discovery URL.

Kas šiame vadove sąmoningai neaprašyta

Klasikinė SAML 2.0 integracija programoms, kurios kalba tik SAML kalba — „Google Workspace“, AWS ir panašioms — vyksta per atskirą Notakey SAML tapatybės tiekėją, ne aukščiau aprašytu OIDC keliu. Už šio vadovo ribų taip pat lieka LDAP/Active Directory kaip naudotojų saugykla, kelių nuomininkų (multi-tenant) diegimai ir individualus prekės ženklo pritaikymas. Visa tai su pilnomis parametrų lentelėmis rasite CLI ir API dokumentacijoje; šis vadovas — greičiausias kelias nuo nulio iki veikiančio beslaptažodžio prisijungimo.

Pamatykite prieš diegdami

Greičiausias būdas įvertinti prisijungimo patirtį — patį patvirtinimo procesą išbandyti savo kailiu: išbandykite tiesioginę demonstraciją ir pasirašykite užklausą telefonu maždaug per dvi minutes, arba užsisakykite demonstraciją, ir mes priderinsime jūsų programas bei slaptažodžio politiką prie bandomojo diegimo jūsų pačių infrastruktūroje.