WCF Single Authentication Несколько конечных точек

Question

При создании приложения-службы WCF я реализовал UserNamePassValidator для пользовательской аутентификации, и это работает как ожидалось.

Но из-за большого количества функциональных возможностей службы я отделил ее от различных контрактов на обслуживание, таких как служба управления запасами, служба управления местоположением, служба управления задачами и т. Д., И затем я разоблачил их на разных конечных точек в одной службе.

Это, кажется, работает нормально, однако я бы предпочел аутентификацию с одной конечной точкой и сохранение этого состояния сеанса по всем конечным точкам. В настоящее время происходит то, что я аутентифицируюсь на один, я могу получить доступ к функциональности этого контракта на обслуживание, но если мне нужно подключиться к другой конечной точке, это потребует от меня повторной аутентификации.

Мое текущее решение для костылей - передать ClientCredentials между формами на стороне клиента для аутентификации, и хотя он использует защиту сообщений, поэтому они шифруются по проводу, это, очевидно, не идеальное решение.

Есть ли решение для первой части? И если нет, то в чем заключается наилучшая практика хранения введенных пользователем учетных данных в памяти (во время выполнения) на стороне клиента.

Answer 1

Вы можете реализовать схему, аналогичную WS-Federation. Это своего рода федеративная безопасность для уровня обслуживания.

• Во-первых, ваша проверка подлинности конечной точки следует называть STS (Security службы маркеров). Он выполняет аутентификацию и возвращает клиенту маркер безопасности .

• Во-вторых, STS следует доверять всем конечным точкам обслуживания. Когда , вызывающий конечные точки, вы должны передать в токен безопасности, который предоставляется STS , чтобы конечные точки могли прочитать этот токен и признали, что токен был выпущен доверенной STS.

Я реализовал один с Thinktecture в https://github.com/khoanguyen/Test-WS-Federation, но жаль, что я не дал объяснений вам нужно будет исследовать немного о WS-Federation и Thinktecture и WIF. Но вы должны знать, что это можно сделать.

---

Легкое решение, которое я использую для REST услуг для мобильного проекта ниже:

• настроить конечную точку проверки подлинности. Эта конечная точка содержит пару частных/открытых ключей DSA. Когда клиент аутентифицирован, эта конечная точка генерирует токен и подписывает его с помощью закрытого ключа DSA. Затем я объединяю подпись и токен вместе и возвращаю его в качестве маркера безопасности для клиента.

• В конечных точках службы я дал им открытый ключ DSA (от пары ключей конечной точки аутентификации). Открытый ключ DSA предназначен для проверки токенов безопасности.

• Когда клиент вызывает конечные точки службы, он прикрепляет маркер безопасности в качестве заголовка HTTP-сообщения. Затем конечные точки службы считывают заголовок для извлечения маркера безопасности -> извлекают токен и подпись из токена безопасности -> используют общедоступную DSA для проверки.

Стратегия создания токена зависит от ваших потребностей. В моем случае мой токен содержит имя пользователя клиента, временную метку истечения срока действия. Используя DSA, хакер может извлечь все данные токена, но они не могут его изменить, потому что у них должен быть закрытый ключ DSA для подписи измененного токена. Наша задача заключается в том, чтобы хранить секретный ключ в тайне и не оставлять конфиденциальную информацию (например, пароль) в токене.

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