Сделать контроллер упрвления пользователями

[zetroot]

Создать
установить пароль
установить роль

[zetroot]

Я тут поразмыслил - из единообразия это можно сделать напрямую в бэкенде. То есть там реализовать сервис, который будет работать с менеджерами пользователей\ролей в asp.net identity. Креды доступа к бд нам известны. Нужды городить под это отдельные контроллеры и клиентов к ним нет.

[zetroot]

@ArtemK123 что думаешь? Отличная возможность поковырять protobuf

[ArtemK123]

1. Мне нравится идея поковырять protobuf. Так что я с радостью занялся бы созданиям страниц на клиенте и контроллеров на бэке.
2. Мне не нравится идея из сервиса A (Backend) лезть напрямую в базу данных сервиса Б (Identity Server). Identity Server задумывался как отдельное приложение, которое по идее не зависит от остальных. А если мы будем лазить в его базу из других сервисов, то это создаст лишние зависимости. Как результат, пропадает возможность деплоить сервисы с отдельными инстансами базы. Тем более девелопить и дебажить будет сложнее из-за работы с двумя базами одновременно.

Я бы лучше сделал один из следующих вариантов:

1. Бэк работает как прослойка и отправляет запросы на IdentityServer
2. Бэк редиректит юзера на IdentityServer. IdentityServer самостоятельно хендлит создание юзера и редиректит назад на основное приложение
3. Отказаться от IdenityServer в принципе. Сохранять юзеров напрямую в базе бэка. Мы потеряем oauth2, но вопрос в том - а нужен ли он вообще? :)

[zetroot]

Да, наверно соглашусь - лазить в базу соседнего сервиса это такое себе:-) Надо постараться обойтись без этого.

Про вариант 3 - пожалуй сразу нет. А какие есть альтернативные варианты? Собственное велосипедостроение я уже как то делал, и мне не понравилось. То есть в принципе это работало, но не могу сказать, что я горжусь этим решением. Если так то можно тогда подключить Identity Server напрямую в бэкенд.

Про вариант 2 - мне не хочется городить еще один фронт в отдельном сервисе. Я вообще не фронтендер, и боюсь это будет потом сложно мне поддерживать. У нас уже есть wasm приложение, почему бы не делать всё в нём?

А вот вариант 1 мне нравится - это получается почти api gateway. Возможно даже на первое время можно обойтись без отдельного сервиса бизнес-логики в бэке и просто пересылать запросы клиента в сервис identity. Хочется только еще токен передать как то красиво - то есть автоматически. Есть идеи как это можно делать?

[ArtemK123]

Зависит от того, кто создает юзеров.
Если сами юзеры - то у них и нету токенов ещё, если они себе только аккаунт создают.
Если админы - то бэк должен сначала провалидировать их токен по стандартному флоу авторизации, а потом отправить запрос на IdentityServer. Но если админы технари, они (возможно) могут и руками в базу данные вносить про юзеров, и тогда не нужно будет вообще создавать UI. В таком случае будет приемущество в том, что бэк ничего не знает про создание юзеров - он полностью перекладывает работу с юзерами на IdentityServer.

[zetroot]

Юзеров будут создавать админы, и не всегда админы могут быть технарями чтобы быстренько в уме посчитать и посолить хэши юзерских паролей и прописать их в psql сидя в контейнере на проде:-)
По этому ui должен быть, без этого не обойтись. Плюс пользователь должен иметь возможность сменить себе пароль самостоятельно.
Валидация токенов на бэке вообще без проблем - это уже реализовано. Все "контроллеры" grpc имеют аттрибут Authorize, ты можешь поэкспериментировать с этим и каким нибудь grpcurl.
Меня больше интересует та часть сценария, когда бэк будет дёргать identity server по обычному rest. Ему же надо добавить токен к запросу? Как это сделать красиво, чтобы не копировать его каждый раз вручную?

[zetroot]

Предлагаю пока такое API:

• создать пользователя (модель: логин, имя, фамилия, пароль)
• удалить пользователя (по идентификатору)
• получить список всех пользователей
• установить новый пароль

Доступ - только для авторизованных пользователей. Ролевые политики накрутим позже.

Соответственно нужно сделать контроллер в identity server, grpc сервис с моделями и какую то морду на фронте для этого.

[ArtemK123]

Как по мне, модель API выглядит валидно. Предлагаю такую и имплементировать. Я думаю, сегодня-завтра смогу начать делать эту таску.

[zetroot]

У тебя есть идеи как передать токен авторизации через бэкенд?
Я начинаю склоняться к мнению, что стоит обойтись чем то готовым - например keycloack

[ArtemK123]

А зачем передавать токен авторизации через бэк?

[zetroot]

А как защитить контроллеры управления пользователями в identity server?

[ArtemK123]

Бэк может передавать токен юзера, который будет делать добавление.
Либо другой вариант - бэк будет работать от лица админ юзера. Но тогда нужно продумать, как он будет авторизироваться и где хранить креды

[zetroot]

Ну я как раз про первый вариант и говорю;) как это сделать красиво? Второй вариант с выделенным "системным" пользователем выглядит как костыль)

[ArtemK123]

Я хз как работает в формате grpc, но в http токен обычно приходит с фронта в качестве хедера. Нам нужно этот токен вычитать и прикрепить к запросу в Identity.
Но, если мы используем подход с токеном юзера, мы закрываем себе возможность добавлять юзеров без явного запроса клиента. Значит, мы не сможем работать с юзерами в фоне.

[zetroot]

Я про юзеров в фоне ничего не понял:)
Мне не нравится идея перекладывать ручками токены. Но если никаких других идей нет - давай так