Управление на потребителя с AWS Cognito - (1/3) Първоначална настройка

Пълният AWS Web Boilerplate - Урок 1А

Основно съдържание Съдържание Щракнете тук Част A: Първоначална настройка Част B: Основна функционалност Част C: Последни стъпки към пълното изпълнение

Изтеглете Github тук.

Въведение

Настройването на удостоверяването на потребителя може да отнеме векове, но това е съществен крайъгълен камък на всяко производствено приложение. Има опции като AuthO и PassportJS, но те или имат криви на усърдно обучение, изискват непрекъсната поддръжка или са уязвими към грешки на програмиста, тъй като изискват самонастройка. Ако само имаше облачна, персонализирана, сигурна и силно мащабируема услуга за управление на потребители.

Представяме ви Amazon Cognito и Federated Identities. Cognito е решението AWS за управление на потребителски профили, а Federated Identities помага да се проследяват вашите потребители в множество входни данни. Интегриран в екосистемата на AWS, AWS Cognito отваря свят на възможности за усъвършенствано разработване отпред, тъй като ролите Cognito + IAM ви дават селективен сигурен достъп до други услуги на AWS. Искате ли да разрешите достъп на S3 Bucket само до определени потребители, подписани? Просто свържете вход за Cognito с IAM роля, която има достъп до кофата и сега кофата ви е защитена! Най-доброто от всичко е, че безплатният слой ви дава 50 000 активни потребители месечно, така че няма да се притеснявате да платите повече, докато не сте готови за бум.

Този шаблон е уеб приложение на React-Redux, което има пълните функции на предварително интегрираните AWS Cognito и Federated Identities. Използвайте този шаблон, ако имате приложение, което искате да бъде разработено с готова за удостоверяване услуга от самото начало. Всъщност това е мощен стартов панел за следващата ви страхотна идея.

Отидете на AWS Cognito на AWS конзолата, за да започнете!

Първоначална настройка - Cognito

Ще настройваме AWS Cognito, което е потребителски пул за вход (като влизане с имейл). Cognito НЕ Е мениджър за вход за какъвто и да е вид вход (като Facebook и Gmail), само за потребителски вход.

Нека първо направим потребителски пул, като кликнете върху „Управление на вашите потребителски пулове“. Потребителският пул е група потребители, които изпълняват същото обозначение. Ако правите клонинг на Uber, бихте направили 2 потребителски пула - един за шофьори и един за ездачи. Засега нека направим само един нов потребителски пул, наречен „App_Users“. Екранът за настройка трябва да изглежда така:

Ще преминем през този процес стъпка по стъпка, така че въведете името на пула на „App_Users“ и щракнете върху „Стъпка през настройките“. Следващата стъпка е „Атрибути“, където дефинираме атрибутите, които ще имат нашите „App_Users“.

Сега искаме да имаме само имейл, парола и “agentName”. Имейлът е нашият уникален идентификатор за потребител, а паролата е задължително поле (поради което не го виждате в списъка със стандартни атрибути). Искаме потребителите да могат да имат кодово име, така че нека да настроим „agentName“ е персонализиран атрибут. Използваме само “agentName”, за да покажем как да добавяме персонализирани атрибути. Превъртете надолу и ще видите опцията за добавяне на персонализирани атрибути.

Към датата на писане на този урок не можете да се връщате назад и да променяте персонализираните атрибути (въпреки че AWS изглежда е в състояние), така че не забравяйте да го направите правилно за първи път! Ако трябва да промените атрибутите, ще трябва да създадете нов потребителски пул. Надяваме се, че AWS поправя този проблем скоро. Както и да е, преминете към правилата на акаунта!

Така че тук можем да видим, че нашите пароли могат да бъдат принудени да изискват определени символи. Очевидно изискването на комбинация от различни типове символи би било по-сигурно, но потребителите често не харесват това. За средно положение нека просто изискваме паролата да е с дължина 8+ знака и да включва поне 1 номер. Също така искаме потребителите да могат да се регистрират. Останалите части не са толкова важни, така че нека преминем към следващата стъпка: проверки.

Тази част е страхотна, можем лесно да интегрираме многофакторно удостоверяване (MFA). Това означава, че потребителите трябва да се регистрират с имейл, както и с друга форма за удостоверяване, като телефонен номер. На този телефонен номер ще бъде изпратен ПИН и потребителят ще го използва, за да потвърди акаунта си. Няма да използваме MFA в този урок, а само проверка по имейл. Задайте MFA на „off“ и проверете само „Email“ като метод за проверка. Можем да оставим попълнената „AppUsers-SMS-Role“ (роля на IAM), тъй като няма да я използваме, но може да я използваме в бъдеще. Cognito използва тази роля на IAM, за да бъде упълномощен да изпраща SMS текстови съобщения, използвани в MFA. Тъй като не използваме MFA, можем да преминем към: Персонализиране на съобщенията.

Когато потребителите получават имейли за потвърждение на акаунта си, можем да посочим какво влиза в този имейл. Тук направихме персонализиран имейл и програмно поставен в ПИН за потвърждение, представен като {####}. За съжаление не можем да предадем други променливи, като например връзка за потвърждение. За да постигнем това, ще трябва да използваме комбинация от AWS Lambda и AWS SES.

Превъртете надолу страницата в стъпката за персонализиране на съобщенията и ние можем да добавим собствени адреси по подразбиране FROM и REPLY-TO За да направим това, трябва да потвърдим имейл в AWS SES, който е лесен и супер бърз за настройка. В нов раздел отидете на началната страница на конзолата на AWS, като щракнете върху оранжевия куб в горната лява ръка. В началната страница на конзолата потърсете SES (Simple Email Service). Щракнете, за да отидете на страницата SES, след това щракнете върху връзката Адреси за електронна поща в лявото меню.

След това кликнете върху „Проверка на нов адрес“ и въведете имейла, който искате да потвърдите.

Сега влезте в имейла си и отворете имейла от AWS. Щракнете върху връзката в имейла, за да потвърдите и ще бъдете пренасочени отново към страницата AWS SES. Успешно потвърдихте имейл! Това беше лесно.

Сега това е готово, нека се върнем обратно към AWS Cognito и преминем към: Етикети.

Не е задължително да добавяте тагове към потребителски пул, но определено е полезно за управление на много AWS услуги. Нека просто добавим маркер за „AppName“ и да го зададем на стойност „MyApp“. Вече можем да преминем към: Устройства.

Можем да изберем да запомним устройствата на нашия потребител. Обикновено избирам „Винаги“, защото запомнянето на потребителски устройства е едновременно безплатно и не изисква кодиране от наша страна. Информацията също е полезна, така че защо не? Следваща стъпка: Приложения.

Искаме определени приложения да имат достъп до нашия потребителски пул. Тези приложения не присъстват никъде другаде в екосистемата на AWS, което означава, че когато създаваме „приложение“, това е идентификатор само за Cognito. Приложенията са полезни, тъй като можем да имаме няколко приложения с достъп до един и същ потребителски пул (представете си приложение за клониране на Uber и безплатно приложение за шофиране). Ще зададем маркера за опресняване на 30 дни, което означава, че всеки опит за влизане ще връща токен за опресняване, който можем да използваме за удостоверяване, вместо да влизаме всеки път. Премахваме кликването върху „Генериране на тайна на клиента“, защото възнамеряваме да влезем в нашия потребителски пул от предния, вместо от задния край (ergo, не можем да пазим тайни от предния край, защото това е несигурно). Щракнете върху „Създаване на приложение“ и след това върху „Следваща стъпка“, за да преминете към: Тригери.

Можем да задействаме различни действия в процеса на удостоверяване и настройка на потребителя. Спомняте ли си как казахме, че можем да създаваме по-сложни имейли за потвърждение на акаунта, използвайки AWS Lambda и AWS SES? Тук бихме настроили това. За обхвата на този урок няма да използваме никакви тригери AWS Lambda. Нека да преминем към последната стъпка: Преглед.

Тук преглеждаме всички конфигурации за настройка, които сме направили. Ако сте сигурни за тази информация, щракнете върху „Създаване на пул“ и нашият потребителски пул Cognito ще бъде генериран!

Обърнете внимание на идентификатора us-east-1_6i5p2Fwaoна басейна в раздела с подробности за басейна.

И идентификационния номер 5jr0qvudipsikhk2n1ltcq684bна клиента на приложението в раздела Приложения. Ще ни трябват и двете в нашето приложение от страна на клиента.

Сега, когато е настроено Cognito, можем да настроим обединени идентификатори за множество доставчици на вход. В този урок ние не обхващаме спецификата на FB Login, тъй като той не е в обхвата на тази серия уроци. Интегрирането на FB Login обаче е супер лесно и ще покажем как се прави в долния раздел.

Първоначална настройка - Федерални идентичности

След това искаме да настроим „Федерални идентичности“. Ако имаме приложение, което позволява множество доставчици на вход (Amazon Cognito, Facebook, Gmail..и т.н.) на един и същ потребител, бихме използвали Federated Identities за централизиране на всички тези влизания. В този урок ще използваме както нашето влизане в Amazon Cognito, така и потенциално влизане във Facebook. Отидете на Federated Identities и започнете процеса за създаване на нов пул за идентичност. Дайте му подходящо име.

Сега разширете раздела „Доставчици за удостоверяване“ и ще видите екрана по-долу. Под Cognito ще добавим току-що създадения от нас потребителски пул Cognito. Копирайте и поставете идентификатора на потребителския пул и идентификационния номер на клиент на приложение, за които сме отбелязали по-рано.

И ако искахме влизане във Facebook за същия пул за идентичност на потребителите, можем да отидем в раздела Facebook и просто да въведем нашия Facebook App ID. Това е всичко на конзолата AWS!

Запазете пула за идентичност и ще бъдете пренасочени към екрана по-долу, където са създадени роли на IAM, за да представят обединения пул за идентичност. Неудостоверената роля на IAM е за невлезли потребители, а удостоверената версия е за влезли потребители. Можем да дадем разрешение на тези роли на IAM за достъп до други ресурси на AWS като сегменти S3 и подобни. Ето как постигаме по-голяма сигурност чрез интегриране на нашето приложение в цялата екосистема на AWS. Продължете да завършвате създаването на този Identity Pool.

Сега трябва да видите екрана по-долу след успешно създаване на пула за идентичност. Сега трябва да отбележите само едно нещо, което е идентификационният номер на идентификационния басейн (т.е. us-east-1:65bd1e7d-546c-4f8c-b1bc-9e3e571cfaa7), който ще използваме по-късно в нашия код. Страхотен!

Излезте от всичко и се върнете към главния екран на AWS Cognito. Ако влезем в секцията Cognito или в Federated Identities, виждаме, че имаме настроени 2 необходими пула. AWS Cognito и AWS Federated Identities са готови за работа!

Това е всичко за настройка! С тези 2 пула можем да интегрираме останалата част от нашия код в пълната услуга за удостоверяване на Amazon и да постигнем управление на потребителите от най-високо ниво. Това беше много по-лесно от персонализирания OAuth + Passport.js! Ако харесвате това, което сте виждали досега, продължете да четете! Не забравяйте, че след като научите това веднъж, в бъдеще ще бъде супер лесно, така че определено си струва да инвестирате време. Ще се видим в следващия раздел!

Основно съдържание Съдържание Щракнете тук Част A: Първоначална настройка Част B: Основна функционалност Част C: Последни стъпки до пълно обезпечаване Тези методи бяха частично използвани при внедряването на renthero.ca