Context
Для одного из наших клиентов я внедряю новую стратегию аутентификации и авторизации. Мы управляем одним из их приложений, которое раньше выполняло проверку доступа на основе следующего:
- IP-адрес
- E-mail (Должен быть зарегистрирован в-в CRM, отправлен как параметр)
- Ключ (простой ключ, передаваемый в качестве параметра в функцию WCF)
Теперь, поскольку некоторые вещи изменились, проверка на основе IP больше не является опцией. Поэтому я посоветовал нашим клиентам внедрить авторизацию на основе токенов, поскольку они прошли полную миграцию Office 365, и все их соответствующие пользователи теперь находятся в Azure AD. Я бы просто зарегистрировал приложение и сервис в AAD и добавил пользователей, которым можно выдать токены.
Теперь токены будут сохраняться на локальном компьютере в кеше токенов с использованием ADAL, и один раз каждые X дней им будет предложено ввести логин для получения нового токена. (Токен отправляется при каждом обращении к службе WCF и проверенному серверу. сторона) Наш клиент посчитал, что решение не соответствует их требованиям. Вместо того, чтобы просить пользователя войти в систему на регулярной основе, ему нужен однократный вход в систему, который предоставит ему доступ на неопределенный срок.
Вопрос
К сожалению, я не могу придумать стандартизированный способ, как этого можно достичь. Поэтому я создал собственную стратегию аутентификации. Я хотел бы знать, будет ли моя стратегия аутентификации достаточной с точки зрения безопасности.
Теперь мне нужен совет, можно ли выполнять проверку на основе GUID машины и адреса электронной почты пользователя?
Приложение представляет собой надстройку Outlook. (Нет Office365 API, иначе у меня не было бы этой проблемы)
Теперь я планирую получить GUID компьютера и получить текущего активного пользователя в Outlook. (Это может быть только электронная почта, которая также зарегистрирована в CRM).
Это поток, которому следуют;
В момент открытия внешнего вида и загрузки надстройки надстройка отправит простой запрос в службу WCF, чтобы узнать, зарегистрирован ли пользователь уже в БД. Это делается путем добавления заголовка Identity в мыльный конверт и хранения строки с двойным шифрованием, содержащей электронную почту пользователя и GUID компьютера.
Когда сервер получает этот запрос, он проверяет правильность заголовка идентификатора. В случае сбоя этого шага клиенту будет предложено войти в свою учетную запись O365, чтобы получить токен от AAD.
После успешного входа в систему клиент немедленно отправит новый запрос определенной функции регистрации пользователя, также размещенной в WCF. Этот запрос содержит токен, который был передан пользователю путем проверки по AAD.
Сервер проверит токен AAD и, если он будет проверен, зарегистрирует идентификатор машины и электронную почту пользователя в БД. Перед тем, как это будет фактически сохранено в БД, оно будет дважды зашифровано с использованием ключей, отличных от тех, которые используются для передачи токена с клиента на сервер.
После того, как клиент получит «успешную регистрацию», он сделает тот же вызов, что и в начале, теперь успешно, так как пользователь и гид зарегистрированы, в случае неудачи пользователю будет предложено снова войти в систему. .
Каждая функция с включенной службой WCF требует наличия заголовка Identity и допустимости содержимого, без которого функции не будут выдавать никакой информации.
Я надеюсь, что кто-то может дать мне какой-либо вклад или отзыв по этому вопросу.