У чэрвені мы ўбудавалі пласт ідэнтыфікацыі ў застасункі, якія генеруе OwlMeans.
Бачнай часткай быў экран уваходу. За ім стаялі ўліковыя запісы, сесіі, дазволы і падзел паміж тымі, хто карыстаецца нашай платформай, і тымі, хто карыстаецца застасункам кліента.
Я хацеў, каб гэтыя рашэнні з самага пачатку былі часткай архітэктуры застасунку.
Уліковыя запісы і ўваход
Паспяховы ўваход паведамляе застасунку, хто прыйшоў. А вось што гэтаму чалавеку можна чытаць ці змяняць, ён не вырашае.
Кліенту можа спатрэбіцца карыстальнік, які бачыць свае запісы, аператар, які разбірае чаргу, і адміністратар, які кіруе доступам. Гэта розныя абавязкі, нават калі экраны выглядаюць падобна.
Пратакол ідэнтыфікацыі апісаны ў тлумачэнні OpenID Foundation пра OpenID Connect. Але што каму дазволена, усё роўна вызначаюць бізнес-правілы застасунку.
У чэрвені мы падключылі працэс уваходу да згенераванага застасунку і далі агульны спосаб апісваць доступ. Так астатні код атрымаў адзіную аснову, на якую можна абапірацца.
Аднак палітыку доступу за кожнага кліента гэта не вызначыла.
Для канчатковых карыстальнікаў застасунку мы выкарысталі аднаразовыя ўліковыя даныя, якія прыходзяць на электронную пошту. Так згенераваны застасунак абышоўся без асобнага працэсу кіравання паролямі.
Я не назваў бы ўваход праз пошту гарантыяй бяспекі ўвогуле і не стаў бы ставіць яго ў адзін шэраг з больш надзейнымі спосабамі аўтэнтыфікацыі.
Як ліст даходзіць да чалавека, як аднаўляецца ўліковы запіс, як паводзяцца сесіі — усё гэта яшчэ трэба прадумаць. А таксама тое, як чалавек становіцца ўдзельнікам арганізацыі кліента.
Гэтыя дэталі лёгка ўпусціць, калі ўся прыёмка зводзіцца да таго, што форма ўваходу адпраўляецца.
Межы доступу
Мадэль дазволаў я хацеў уберагчы ад рашэнняў, прынятых на хаду і раскіданых па ўсім кодзе.
Экран можа мець патрабаванне да доступу, але і аперацыя за ім павінна мець патрабаванне, якое сістэма сапраўды правярае. Схаваная кнопка — яшчэ не правіла аўтарызацыі.
OWASP у сваёй шпаргалцы па аўтарызацыі раіць вызначыць межы доступу, па змаўчанні адмаўляць у доступе і правяраць дазволы пры апрацоўцы запытаў. А яшчэ — тэставаць гэтыя правілы.
У структуры нашых застасункаў патрабаванне аб’яўляецца праз пагадненні фрэймворка пра доступ. Бізнес-код павінен паслядоўна прытрымлівацца гэтых пагадненняў, а не выдумляць сваё тлумачэнне ў кожным апрацоўшчыку.
Для звычайнага працоўнага інструмента я тэставаў бы рэальныя адрозненні. Карыстальнік можа праглядаць свой запіс. Аператар можа апрацоўваць прызначаную яму заяўку. Ні той, ні другі не павінен атрымліваць правы адміністратара проста таму, што ўвайшоў.
Такія паводзіны трэба закладваць у патрабаванні да прадукту і ў тэсты. Адна толькі назва пратакола гэтага не гарантуе.
OwlMeans мае свае ўліковыя запісы. Застасунак, створаны з яго дапамогай, мае сваіх канчатковых карыстальнікаў. Развесці гэтыя дзве рэчы было часткай працы над ідэнтыфікацыяй.
Межы кліента, праекта і рэсурсу важныя, бо асоба можа быць пацверджаная, а пэўнае дзеянне ўсё адно не ўваходзіць у яе паўнамоцтвы. Аднаго ідэнтыфікатара карыстальніка не хапае, каб апісаць усе гэтыя межы.
Вытворчай версіі таксама патрэбныя налады ўваходу, задуманыя менавіта для яе. Не варта лічыць, што ўліковыя запісы і адрасы перанакіравання з папярэдняга прагляду і ёсць налады вытворчай версіі.
На практыцы пытанне ў тым, ці пройдзе патрэбны чалавек задуманы працоўны працэс і ці атрымае адмову той, хто знаходзіцца па-за гэтымі межамі.
OIDC і пастаўка
OIDC дае застасунку стандартны інтэрфейс ідэнтыфікацыі. Але з гэтага не вынікае, што даступная любая карпаратыўная інтэграцыя ідэнтыфікацыі, што кожную мяжу паміж арандатарамі пратэставалі або што на анкету пакупніка пра бяспеку ўжо адказалі.
У ранейшай версіі гэтага артыкула ўсё гучала так, быццам гэта адбываецца само сабой.
Інтэграцыя па-ранейшаму залежыць ад правайдара і налад. Ролі кліента і правілы яго арганізацыі ўсё яшчэ трэба апісаць. Праверка згенераванага застасунку застаецца часткай пастаўкі.
Я лепш апішу тое, што ў нас ёсць, чым буду намякаць на сертыфікацыю толькі таму, што мы выбралі пратакол.
У жніўні інтэграваная сістэма ідэнтыфікацыі стала адзінай рэалізацыяй IAM Платформы. Чэрвеньская размова пра знешні бэкэнд, які можна пераключаць, цяпер мае толькі гістарычны сэнс.
Цяперашняя праца над доступам таксама аддзяляе ўжо рэалізаваныя механізмы кантролю ад удакладненняў, якія яшчэ ў распрацоўцы. Дакументацыя і код сведчаць пра сам механізм. Даказаць, што бяспечны кожны застасунак, створаны з яго дапамогай, яны не могуць.
Актуальнае кіраўніцтва па аўтэнтыфікацыі апісвае складнікі фрэймворка. А схему доступу застасунку трэба правяраць у кантэксце таго прадукту, які ствараецца.
Калі ідэнтыфікацыя ўбудаваная, гэтую частку сістэмы падтрымліваем мы. Кліентам усё роўна трэба апісаць людзей, рэсурсы і дзеянні, якіх патрабуе іх прадукт. Мы маем агульны спосаб выразіць гэтыя правілы. Правяраць іх — па-ранейшаму частка працы.
Перагледжана 15 кастрычніка 2026 г. Гісторыя чэрвеньскай рэалізацыі захаваная, а ранейшыя параўнанні цэн і занадта шырокія абяцанні наконт карпаратыўнага выкарыстання і бяспекі выпраўленыя.