Служба аутентификации с использованием WCF

Question

У меня есть пользовательский MembershipProvider, как показано ниже. Он проверяет имя пользователя и пароль в Active Directory. Я хотел бы сделать это как «сервис аутентификации». Это должно работать, даже если клиент использует проверку подлинности с помощью форм или проверку подлинности Windows.

Существует WCF «HR Service», который предоставляет информацию о сотрудниках. Сайт «HR UI» использует сервис WCF «HR Service». Теперь нам нужно убедиться, что любой клиент, использующий «Сервис HR», должен пройти аутентификацию с использованием «Сервиса аутентификации», прежде чем получить доступ к операции «Сервис HR». Если клиентское приложение проходит проверку подлинности один раз, в следующий раз оно не должно проверяться повторно (до тех пор, пока приложение не будет закрыто). Когда открывается новый экземпляр клиентского приложения, его необходимо аутентифицировать с самого начала.

Как нам этого достичь? У нас есть примеры кода для демонстрации сквозного потока?

Примечание: я должен быть в состоянии проверить это, используя сервисы .

Примечание. Клиент может быть любой платформы (например, Java).

namespace LijosCustomValidation
{
public sealed class LijoMembershipProvider : MembershipProvider
{

    public override bool ValidateUser(string username, string password)
    {
        bool isValid = true;
 //my logic to validate the user name and password
        return isValid;
    }

   //other implementations of Abstract Methods from MembershipProvider
  }

Answer 1

Ваша служба аутентификации должна вернуть токен, если аутентификация прошла успешно.Этот токен, в свою очередь, должен быть представлен службе HR.

У вас есть несколько вариантов действий службы HR на этом этапе.Он может либо узнать секрет для проверки токена, либо ему нужно вызвать службу аутентификации для проверки токена.

Токен должен иметь какое-то значение, которое можно проверить, если вы знаете секрет, так что это может быть что-тоскажем, идентификатор пользователя, который симметрично зашифрован.В идеале в нем должен быть компонент времени, чтобы предотвратить атаки воспроизведения.

Я бы предложил что-то вроде

<hash value>|<token issue time>|<user id>

Значение хэша должно быть хешем (sha1, md5 и т. Д.)все после первой трубы.Затем вы можете base64 закодировать результат и передать его.После проверки токена можно было проверить, что дата выпуска была в пределах определенного периода времени.

У вас также есть возможность сохранить токен в клиенте в файле cookie и передать его в виде файла cookie службам или сделать так, чтобыпараметр на ваших услугах.Могут быть и другие варианты, в зависимости от архитектуры вашего клиента и того, как вы хотите структурировать свои услуги.