Bezparoles SSO ar Notakey: konfigurācijas ceļvedis soli pa solim

Pēc šī ceļveža izlasīšanas jūsu lietotāji lietotnē pieteiksies ar apstiprinājumu tālrunī: ieraksta lietotājvārdu vai noskenē QR kodu un apstiprina Notakey lietotnē. Pieteikšanās lapā paroles vairs nav. Parole gan nekur nepazūd, bet tai paliek tieši viens obligāts uzdevums — to prasa vienreiz, ierīces reģistrācijas brīdī, lai izveidotu lietotāja atslēgu. Viss, kas notiek pēc tam, ir jūsu politikas izvēle, un šis ceļvedis parāda, kur tieši katra politika tiek iestatīta.

Katrs Notakey serviss — arī tie, ko jau izmantojat VPN, Windows vai Wi-Fi divfaktoru autentifikācijai — var darboties arī kā OpenID Connect (OIDC) nodrošinātājs. Tam nav vajadzīgs atsevišķs produkts: vadības panelī servisam ieslēdziet OIDC, reģistrējiet lietotni, kas to izmantos kā klients, un norādiet tai Notakey ģenerētos galapunktus (endpoints). Nekādu SAML sertifikātu, nekāda atsevišķa identitātes nodrošinātāja servera, kas jāuztur.

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

(Klasiskām uzņēmumu lietotnēm, kas atbalsta tikai SAML — Google Workspace, AWS —, vajadzīgs Notakey atsevišķais SAML identitātes nodrošinātājs; kur to atrast, teikts pēdējā sadaļā.)

Kā parole šeit patiesībā strādā

Par to vērts runāt precīzi, jo vārds “bezparoles” bieži tiek lietots pavirši:

• Vienīgā obligātā parole ir reģistrācijas (onboarding) parole. Tā iestatīta vadības panelī vai pārmantota no Active Directory, un tiek pārbaudīta vienreiz — kad lietotājs reģistrē savu ierīci un tālruņa drošajā aparatūrā tiek izveidota viņa atslēga.
• Ikdienas pieteikšanās parole nav vajadzīga. Lietotājs ieraksta lietotājvārdu vai noskenē QR kodu — pieteikšanās lapu var iestatīt tā, ka tajā ir tikai QR kods skenēšanai, bez neviena lauka, kurā ko ierakstīt. Identitāti apliecina parakstītais apstiprinājums lietotnē.
• Viss pārējais ir iestatījums, nevis fiksēts noteikums. Vienai lietotnei var pieprasīt papildu apstiprinājumu lietotnē, citai — paroli, trešajai — abus. Paroli var prasīt arī atkārtoti ik pa laikam, lai cilvēki to pavisam neaizmirst. Viss šis atrodas vienā konfigurācijas ekrānā, kas aprakstīts 5. solī.

1. solis — izvēlieties servisu

Ja lietotāji, kas izmantos pieslēdzamo lietotni, jau sakrīt ar esoša servisa lietotājiem, izmantojiet to. Ja šai lietotnei vajadzīga sava, no visa pārējā neatkarīga paroles politika, izveidojiet jaunu servisu (Services → Manage → New). Izšķirošais faktors: 5. solī iestatītā politika attiecas uz visu servisu, nevis atsevišķu klientu.

2. solis — ieslēdziet OpenID Connect

Atveriet servisu, tad OpenID Connect configuration → Configure un atzīmējiet Enabled. Pārējo pagaidām atstājiet noklusējumā — Require password un Require mfa jūs apzināti iestatīsiet 5. solī, nevis nejauši šeit. Saglabājiet.

3. solis — nokopējiet galapunktus

Atgriezieties sadaļā OpenID Connect configuration un noklikšķiniet Show. Notakey jau ir ģenerējis discovery dokumentu un aiz tā slēptos atsevišķos galapunktus:

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

Lielākajai daļai OIDC atbalstošas programmatūras pietiek ar šo vienu URL — ielīmējiet to laukā “auto discovery” vai “issuer”, un lietotne pati atrod authorization, token, userinfo un JWKS galapunktus. <access-id> ir tas pats ID, kas redzams servisa paša lapā.

4. solis — reģistrējiet lietotni kā klientu

Servisa sadaļā OpenID Connect configuration → Clients → New client. Notakey jums uzreiz ģenerē Client ID un nejaušu Secret.

Pirms saglabāšanas der zināt divas lietas. Pirmā: lauks Secret ir maskēts, un, tiklīdz pametīsiet lapu, Notakey to vairs neparādīs — nokopējiet uzreiz, vai arī iezīmējiet lauku un ielīmējiet savu izvēlētu noslēpumu, kas strādā tikpat labi un ir vieglāk izsekojams. Otrā: laukam Redirect URIs jāsakrīt burtu burtā ar URL, ko lietotne nosūta atpakaļ pieteikšanās laikā — pietiek ar vienu slīpsvītru beigās, kuru lietotne nesūta, lai viss saplīstu (skatiet nianses sadaļu zemāk).

Aizpildiet:

• Description — jebkas, kas palīdzēs to vēlāk atpazīt.
• Secret — nokopējiet ģenerēto vai pārrakstiet ar savu.
• Redirect URIs — lietotnes OAuth callback URL. Ja lietotne sasniedzama vairākās adresēs, atdaliet tās ar komatu.
• Logout URI — uz kurieni pārsūtīt pārlūku pēc izrakstīšanās. Nav obligāts.

Kad esat reģistrējis pāris lietotnes, servisa klientu saraksts izskatās šādi:

5. solis — norādiet lietotnei Notakey kā autentifikācijas avotu

Konkrētie soļi atšķiras atkarībā no lietotnes, taču shēma vienmēr ir tā pati: issuer vai discovery URL, klienta ID, klienta noslēpums. Divi piemēri no reāliem pašpārvaldītiem rīkiem:

Gitea tam piedāvā gatavu CLI komandu — bez tīmekļa formas, bez pārstartēšanas:

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 pieteikšanās lapā uzreiz parādās poga “Sign in with notakey” — līdzās esošajai paroles formai, neko neizņemot.

Proxmox VE to traktē kā autentifikācijas realm — papildu esošajiem, nevis to vietā:

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 šeit ir discovery URL bez /.well-known/openid-configuration gala — Proxmox šo daļu pievieno pats. --autocreate 1 pirmajā veiksmīgajā pieteikšanās reizē izveido atbilstošu Proxmox lietotāju bez jebkādām tiesībām, kamēr jūs tās skaidri nepiešķirat — piekļuve nejauši netiks izdalīta.

6. solis — iestatiet paroles politiku

Šeit “administratora izvēle” kļūst konkrēta — atkal sadaļā OpenID Connect configuration → Configure:

• Require password izslēgts, Require mfa ieslēgts: bezparoles plūsma, kas aprakstīta ceļveža sākumā. Pieteikšanās ir lietotājvārds (vai QR) plus apstiprinājums tālrunī, un nekas vairāk.
• Require password ieslēgts, Password cache atstāts uz 0: parole tiek prasīta katru reizi papildus apstiprinājumam — klasisks divfaktoru variants.
• Require password ieslēgts, bet Password cache iestatīts sekundēs (piemēram, 2592000 — 30 dienas): ikdienā bezparoles, bet, kad šis periods beidzies, parole tiek prasīta atkal — vienīgi tāpēc, lai to pavisam neaizmirstu. Mfa cache strādā tāpat arī apstiprinājuma solim, ja kādreiz gribat kešot arī to.

Tā kā šis iestatījums attiecas uz visu servisu, lietotnei, kurai vajadzīga cita politika nekā pārējām, jāatvēl savs serviss — atgriežamies pie 1. solī aprakstītās izvēles.

Kad kaut kas nestrādā

• Kļūda redirect_uri mismatch gandrīz vienmēr nozīmē slīpsvītru beigās: viena lietotne sūta https://app.example.com, cita — https://app.example.com/, un Notakey salīdzina virknes burtiski. Pārbaudiet nginx vai lietotnes piekļuves žurnālos, kāda redirect_uri= vērtība tika nosūtīta burtiski, un reģistrējiet tieši to.
• Ja discovery URL atgriež 404, pārbaudiet, vai Enabled patiešām tika saglabāts 2. solī — visbiežākā kļūda ir konfigurācijas lapa, kas izskatās pareizi, bet nekad netika iesniegta.
• Servisa žurnāls Authentication activities rāda katru mēģinājumu, kas sasniedzis Notakey. Ja mēģinājums tur nemaz neparādās, lietotne pat nav nokļuvusi līdz authorization galapunktam — vispirms pārbaudiet klienta ID un discovery URL.

Ko šis ceļvedis apzināti neaptver

Klasiskā SAML 2.0 integrācija lietotnēm, kas atbalsta tikai SAML — Google Workspace, AWS un līdzīgas — notiek caur Notakey atsevišķo SAML identitātes nodrošinātāju, nevis iepriekš aprakstīto OIDC ceļu. Ārpus šī ceļveža paliek arī LDAP/Active Directory kā lietotāju repozitorijs, vairāku klientu (multi-tenant) uzstādījumi un pielāgots noformējums. Viss tas atrodams CLI un API atsaucē ar pilnām parametru tabulām; šis ceļvedis ir ātrākais ceļš no nulles līdz strādājošai, bezparoles pieteikšanās.

Paskatieties, pirms ķeraties pie ieviešanas

Ātrākais veids, kā novērtēt pieteikšanās pieredzi, ir izmēģināt apstiprināšanas plūsmu pašiem: izmēģiniet tiešsaistes demo un aptuveni divās minūtēs parakstiet pieprasījumu no sava tālruņa, vai pieprasiet demo, un mēs jūsu lietotnes un paroles politiku pārvērtīsim izmēģinājuma projektā jūsu pašu infrastruktūrā.