Пре неколико месеци имплементирао сам ОпенИД Цоннецт сервер за управљање приступом стотинама наших интерних апликација. Од сопствених развоја, погодних у мањем обиму, прешли смо на општеприхваћени стандард. Приступ преко централне услуге умногоме поједностављује монотоне операције, смањује трошкове имплементације ауторизација, омогућава вам да пронађете многа готова решења и да се не мучите када развијате нова. У овом чланку ћу говорити о овој транзицији и неравнинама које смо успели да попунимо.
Давно... Како је све почело
Пре неколико година, када је било превише интерних апликација за ручну контролу, написали смо апликацију за контролу приступа унутар компаније. Била је то једноставна Раилс апликација која се повезивала са базом података са информацијама о запосленима, где је конфигурисан приступ разним функционалностима. Истовремено смо подигли и први ССО који се заснивао на верификацији токена са стране клијента и ауторизационог сервера, токен је пренет у шифрованом облику са неколико параметара и верификован на серверу за ауторизацију. Ово није била најпогоднија опција, пошто је свака интерна апликација морала да опише значајан слој логике, а базе података запослених су биле потпуно синхронизоване са сервером за ауторизацију.
После неког времена, одлучили смо да поједноставимо задатак централизоване ауторизације. ССО је пренет у биланс. Уз помоћ ОпенРести-а, у Луа је додат шаблон који проверава токене, зна на коју апликацију захтев иде и може да провери да ли тамо постоји приступ. Овај приступ је у великој мери поједноставио задатак контроле приступа интерним апликацијама – у коду сваке апликације више није било потребно описивати додатну логику. Као резултат тога, затворили смо саобраћај екстерно, а сама апликација није знала ништа о ауторизацији.
Међутим, један проблем је остао нерешен. Шта је са апликацијама којима су потребне информације о запосленима? Било је могуће написати АПИ за услугу ауторизације, али би онда морали да додате додатну логику за сваку такву апликацију. Поред тога, желели смо да се ослободимо зависности од једне од наших самописних апликација, оријентисаних у будућности за превод у ОпенСоурце, на нашем интерном серверу за ауторизацију. О томе ћемо неки други пут. Решење за оба проблема био је ОАутх.
према заједничким стандардима
ОАутх је разумљив, општеприхваћен стандард ауторизације, али пошто само његова функционалност није довољна, одмах су почели да разматрају ОпенИД Цоннецт (ОИДЦ). Сам ОИДЦ је трећа имплементација стандарда отворене аутентикације, који је прешао у додатак преко ОАутх 2.0 протокола (отворени протокол за ауторизацију). Ово решење затвара проблем недостатка података о крајњем кориснику, а омогућава и промену провајдера ауторизације.
Међутим, нисмо изабрали одређеног провајдера и одлучили смо да додамо интеграцију са ОИДЦ за наш постојећи сервер за ауторизацију. У прилог овој одлуци ишла је чињеница да је ОИДЦ веома флексибилан у погледу ауторизације крајњег корисника. Тако је било могуће имплементирати ОИДЦ подршку на вашем тренутном серверу за ауторизацију.
Наш начин имплементације сопственог ОИДЦ сервера
1) Довео податке у жељени облик
За интеграцију ОИДЦ-а потребно је тренутне корисничке податке довести у форму разумљиву стандарду. У ОИДЦ-у ово се зове потраживања. Захтеви су у суштини коначна поља у бази података корисника (име, е-маил, телефон итд.). Постоји , а све што није укључено у ову листу сматра се обичајем. Стога, прва тачка на коју треба да обратите пажњу ако желите да изаберете постојећег ОИДЦ провајдера је могућност погодног прилагођавања нових брендова.
Група обележја је комбинована у следећи подскуп – Обим. Приликом ауторизације тражи се приступ не одређеним маркама, већ обимима, чак и ако неки од брендова из опсега нису потребни.
2) Реализовани неопходни грантови
Следећи део интеграције ОИДЦ-а је избор и примена типова овлашћења, тзв. грантова. Даљи сценарио интеракције између изабране апликације и сервера за ауторизацију зависиће од изабраног гранта. Пример шеме за избор правог гранта је приказан на слици испод.
За нашу прву апликацију користили смо најчешћи грант, ауторизациони код. Његова разлика од других је у томе што је тростепена, тј. је на додатном тестирању. Прво корисник поднесе захтев за дозволу ауторизације, добије токен - Ауторизациони код, затим са овим токеном, као са картом за путовање, захтева приступни токен. Сва главна интеракција ове ауторизационе скрипте заснива се на преусмеравању између апликације и сервера за ауторизацију. Можете прочитати више о овом гранту .
ОАутх се придржава концепта да приступни токени добијени након ауторизације треба да буду привремени и да се мењају пожељно сваких 10 минута у просеку. Давање кода ауторизације је верификација у три корака путем преусмеравања, сваких 10 минута да се окрене такав корак, искрено, није најпријатнији задатак за очи. За решавање овог проблема постоји још један грант - Рефресх Токен, који смо такође користили у нашој земљи. Овде је све лакше. Током верификације са другог гранта, поред главног токена за приступ, издаје се још један – Рефресх Токен, који се може користити само једном и његов животни век је обично много дужи. Са овим токеном за освежавање, када се заврши ТТЛ (време за живот) главног токена за приступ, захтев за новим токеном приступа ће доћи до крајње тачке другог одобрења. Коришћени Рефресх Токен се одмах ресетује на нулу. Ова провера је у два корака и може се обавити у позадини, неприметно за корисника.
3) Подесите прилагођене формате за излаз података
Након што су одабрани грантови имплементирани, ауторизација проради, вреди напоменути добијање података о крајњем кориснику. ОИДЦ има засебну крајњу тачку за ово, где можете да захтевате корисничке податке са својим тренутним токеном за приступ и ако је ажуриран. А ако се подаци корисника не мењају тако често, а потребно је да пратите актуелне много пута, можете доћи до таквог решења као што су ЈВТ токени. Ови токени су такође подржани стандардом. Сам ЈВТ токен се састоји од три дела: заглавља (информације о токену), корисног учитавања (сви неопходни подаци) и потписа (потпис, токен потписује сервер и касније можете проверити извор његовог потписа).
У ОИДЦ имплементацији, ЈВТ токен се зове ид_токен. Може се захтевати заједно са нормалним токеном за приступ и све што је преостало је да проверите потпис. Сервер за ауторизацију има засебну крајњу тачку за ово са гомилом јавних кључева у формату . А кад смо већ код овога, вреди напоменути да постоји још једна крајња тачка, која се заснива на стандарду одражава тренутну конфигурацију ОИДЦ сервера. Садржи све адресе крајњих тачака (укључујући адресу прстена јавних кључева који се користи за потписивање), подржане брендове и опсеге, коришћене алгоритме за шифровање, подржане грантове итд.
На пример на Гуглу:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}Дакле, користећи ид_токен, можете пренети све потребне ознаке на носивост токена и не контактирати сервер за ауторизацију сваки пут да бисте захтевали корисничке податке. Недостатак оваквог приступа је што промена корисничких података са сервера не долази одмах, већ заједно са новим токеном за приступ.
Резултати имплементације
Дакле, након имплементације сопственог ОИДЦ сервера и конфигурисања конекција са њим на страни апликације, решили смо проблем преноса информација о корисницима.
Пошто је ОИДЦ отворени стандард, имамо могућност избора постојећег провајдера или имплементације сервера. Испробали смо Кеицлоак, који се показао веома погодним за конфигурисање, након подешавања и промене конфигурације везе на страни апликације, спреман је за рад. На страни апликације, остаје само да промените конфигурације везе.
Говорећи о постојећим решењима
У оквиру наше организације, као први ОИДЦ сервер, склопили смо сопствену имплементацију, која је по потреби допуњавана. Након детаљног прегледа других готових решења, можемо рећи да је ово спорна тачка. У прилог одлуке о имплементацији сопственог сервера изнета је забринутост од стране провајдера у недостатку потребне функционалности, као и у присуству старог система у којем су постојала различита прилагођена овлашћења за неке сервисе и доста података о запосленима је већ ускладиштено. Међутим, у готовим имплементацијама постоје погодности за интеграцију. На пример, Кеицлоак има сопствени систем за управљање корисницима и подаци се чувају директно у њему и неће бити тешко престићи своје кориснике тамо. Да бисте то урадили, Кеицлоак има АПИ који ће вам омогућити да у потпуности извршите све потребне радње преноса.
Још један пример сертификоване, интересантне, по мом мишљењу, имплементације је Ори Хидра. Занимљиво је јер се састоји од различитих компоненти. Да бисте се интегрисали, мораћете да повежете своју услугу управљања корисницима са њиховом услугом ауторизације и проширите је по потреби.
Кеицлоак и Ори Хидра нису једина готова решења. Најбоље је изабрати имплементацију сертификовану од стране ОпенИД Фоундатион. Ова решења обично имају значку ОпенИД Цертифицатион.
Такође не заборавите на постојеће плаћене провајдере ако не желите да задржите свој ОИДЦ сервер. Данас постоји много добрих опција.
Шта је следеће
У блиској будућности ћемо на другачији начин затворити саобраћај ка интерним сервисима. Планирамо да пренесемо наш тренутни ССО на балансер користећи ОпенРести на проки заснован на ОАутх-у. Овде већ постоји много готових решења, на пример:
Додатни материјали
– добар сервис за валидацију ЈВТ токена
- листа сертификованих имплементација ОИДЦ-а
Извор: ввв.хабр.цом