Site Tools


AWS Signle Sign On

Для выполнения операций в персональной зоне любого сайта требуется пройти классический AAA перед тем как получить возможность вносить какие-то изменения. Раньше ситуация была простой и неудобной, каждый кролик агроном, у каждого своя база клиентов, что впрочем, логично и у каждого своя система ААА, однако люди поумнее смекнули, что сие есть максимум неудобно и начали думать над централизованными системы авторизации и аутентификации. Поскольку моё слово не законч и читает меня полтора анонима я могу говорить здесь всё что угодно не разобравшись в материале, поэтому по моему личному мнению стильный и модный протокол OAuth2, который и был придуман в помощь страждущим единой точки отказа авторизации и аутентификации используется исключительно для двух А из трёх, Accounting уже осуществляется на стороне конечного сервиса. И вот, спустя несколько лет мы уже имели возможность авторизации на сайтах с помощью Google, Mail.ru1) и прочих facebook'ов. С одной стороны это конечно удобно, авторизовался в большом сервисе и пошёл шатать мелкие2), с другой стороны мелкий вполне себе следит за твоими перемещениями и это очередная итерация слежки за пользователями3)

Так или иначе сложно отрицать, что Single Sign On несёт пользу для конечного пользователя, поскольку позволяет сократить количество запоминаемых паролей4) и хранить хэш проля5) у условно безопасного провайдера, сливы БД которого происходят чуточку реже, нежели у других.

В нашей статье мы будем использовать как провайдера SSO досточтенный Google, а как систему, в которой мы будем авторизовываться, конечно же AWS. Общий смысл мероприятия - уменьшить для конечного Anykey или Ops6) количество телодвижений при увольнении кадров из предприятия.

Включение нового сервиса

Переходим в сервис Amazon Single Sign-On и создаём новый SSO для нашего аккаунта. В процессе будет сообщено, что это может занять несколько минут и в случае успеха появится кнопка перейти к настройкам. Нажав на эту кнопку попадаем на страничку с шагами для настройки SSO.

Здесь мы нажимаем на пункт 1 и в пункте Identity Source нажимаем Change 7)

На открывшей странице выбираем External provider и ниже появится ещё один блок с настройками, в котором полезно нажать на “Show individual metadata values”, после чего раскроется блок с настройками, которые понадобятся нам для настройки Google.

Теперь важный момент, для настройки со стороны Google у учётной записи должны быть права не ниже Super Admin. Заходим в админку и переходим Apps → Web and mobile apps, После этого нажимаем “Add custom SAML app”.

Вводим название нового приложения и переходим к следующему шагу

Здесь скачиваем настройки, которые нам понадобятся для AWS и переходим дальше

На следующем шаге нам понадобятся данные со стороны AWS. возвращаемся на вкладку, где мы настраивали SSO Provider для AWS и перекладываем оттуда в Google следующие поля:

AWS SSO ACS URL → ACS URL

AWS SSO issuer URL → Entitry ID

А так же ниже выбираем Name ID Format → Email, чтобы оно нас авторизовывало по Email.

Нажимаем продолжить и если мы хотим смапить ещё какие-то атрибуты - делаем это здесь

Теперь нажимаем Finish и нас перекидыват на страничку с созданным приложением.

Перед тем как идти дальше стоит сделать ещё одну увлекательную вещь. Перейти в User access и для нужного подразделения в админке гугла переключить возможность использования этого приложения в ON (по дефолту оно будет OFF)

Теперь осталось закончить регистрацию SSO на стороне AWS. Возвращаемся во вкладку с ним и загружаем скаченные ранее данные нажав на кнопку Idp SAML metadata и Review.

Нас спросят точно ли мы уверены, что хотим сменить способ SSO и предупредят о последствиях, в поле нужно ввести ACCEPT и нажать кнопку Change identity source

На этом смена должна завершиться и далее можно переходить к добавлению пользователей и групп.

Доступ через SSO

Данная часть настройки доступов отличается от IAM, тут немного другие термины и объекты.

Группы

Служат исключительно для группировки пользователей, больше никакой смысловой нагрузки не несут.

Пользователи

Пользователи создаются вручную, причём надо учитывать, что Username должен быть тем же, что мы указывали в настройках Name ID Format в Google. В нашем случае мы выбирали Email, значит и тут должен быть email, дальше поля тривиальны

Если у нас есть группы можем навесить сразу группу

На этом создание пользователей заканчивается.

Связывание SSO пользователей и AWS

А теперь нужно сделать так, чтобы внешние пользователи могли быть сопоставлены с внутренними AWS объектами и терминами. Переходим на AWS Accounts и если у нас ещё нет ни одного Permission sets (в IAM мы бы делали это группами) - создаём его. Суть проста - берём полиси и цепляем их к Permission set, ничего сложного. У меня вот уже есть

Ну и теперь мы готовы связать наших пользователей с сущностями в AWS. Переходим на вкладку AWS Organizations, выбираем нужную организацию и нажимаем Assign users

Я для удобства прикрепил к организации сразу группу

На следующем шаге прикрепляем созданный Permission set

И готово, теперь мы можем с помощью учётной записи test@plds.lv в Google авторизоваться в AWS Management Console.

Дополнительно можно настроить удобный адрес для авторизации пользователей через SSO. Нужно перейти в Settings и внизу есть блок

По умолчанию там будут странные цифры или что-то вроде того, но можно поменять на красивую мнемоническую запись.

Важный момент - стоит понимать, что старая ссылка, которая console.aws.amazon.com не даст авторизоваться через SSO. Это два разных сервиса.

SSO и Programatic access

Вы спросите меня а где же ключи для доступа через API, чтобы делать всякие штуки через консоль и я вам отвечу - здесь всё работает немного иначе. В отличии от перманентных API ключей в IAM SSO использует временные связки ключей. Для этого в первую очередь следует обновить aws-cli до версии не ниже 2.0.0, поскольку более ранние версие не поддерживают авторизацию по sso. Далее нужно запустить

aws configure sso

и пройти простенький визард. В процессе откроется браузер, нужно будет авторизоваться в Google и нажать кнопку Approve, после чего вернуться в консоль и успешно пользоваться aws-cli в течении времени жизни токена (можно настроить в Settings SSO)

1)
для жителей СНГ
2)
условно конечно
3)
мы же помним, что в интернете нет ничего бесплатного, да, и за всё, чем мы “бесплатно” пользуемся мы платим либо персональными данными, пушо как минимум мобильный телефон стал нормой для многих сервисов, либо просмотром рекламы, впрочем вы сами умные и сами всё понимаете
4)
если пользователь конечно не использует один пароль для всего, что чаще всего и случается
5)
я очень надеюсь, что тот же гугл хранит пароли используя сильные алгоритмы хеширования с солью и прочем фаршем
6)
в зависимости от того кто именно у нас используется руководством для предоставления и отзыва доступов конечных сотрудников
7)
в моём случае просто уже настроено, по умолчанию там AWS SSO