Есть ли у кого-то опыт использования идентити сервиса для такой цепочки?
Получается, что Identity Service содержит некие свои логины, не имеющие отношения к реальным юзерам SQL Server

МихаилРРолг Хупин,

Не уверен что понял правильно ваш вопрос, поэтому задам свои уточняющие:
Я правильно понимаю, что вы говорите об использование Federated Authentication в WCF, когда за аутентификацию отвечает отдельный сервис, который вы назвали Identity Service?
Тогда ответ на первый вопрос, да, есть. Я работал с WIF, мы разрабатывали собстенный Identity Service, который обслуживал остальные прикладные сервисы.

Что касается второго вопроса, я бы ответил так: пользователи, которые используются для аутентификации клиента причем как в схеме как у вас (Client->Identity Service->WCF->SQL Server) так и в более простой (Client->WCF->SQL Server) теоретически могут быть и пользователями SQL, но это скорее исключительная ситуация.

Стандартными средствами WCF, вообще невозможно делать аутентификацию, опираясь на SQL-пользователей.

Сейчас у меня клиентские приложения работают так:

клиент->(имя, пароль (Windows domain или SQL))->WCF (impersonation(w), коннект)->SQL Server

То есть юзер с клиента передает имя пароль, сервис коннектится к скл серверу, обрабатывает запросы.

При наличии отдельного сервиса WIF, клиентское приложение логинится в нем, затем передает токен сервису, тот обращается к тому же сервису, уточняет свойства клиента и работает.

Вот и был вопрос о юзерах - искуственно ли созданные или реальные могут быть

МихаилРРолг Хупин,

Теперь понял. Я совсем упустил момент имперсонации.

У нас был вариант без имперсонации, поэтому пользователи были свои ("искуственно созданные"), и, на сколько я знаю - это более распространенный вариант. Однако у WIF есть механизм позволяющий по claim токену получить Windows-токен и далее работать с ним.

Сам я об этом только читал, но не работал.
В версии WIF 3.5 за это отвечал Claims to Windows Token Service (c2WTS) .


а что я могу сделать с Windows токеном при коннекте к Sql Server внутри сервиса?

Sql Server не принимает напрямую Windows токен.

МихаилРРолг Хупина что я могу сделать с Windows токеном при коннекте к Sql Server внутри сервиса?
Sql Server не принимает напрямую Windows токен.
То же, что и сейчас - имперсонироваться и подключиться, используя Windows аутентификацию

Сейчас я делаю приблизительно так





Если я правильно понимаю, то в случае использования WIF сервиса, можно сразу из него получить dupeTokenHandle без плясок с логином и паролем и использовать его для имперсонейта?

МихаилРРолг ХупинСейчас я делаю приблизительно так





Я ведь правильно понимаю, что вы сейчас работаете с UserName/Password аутентификацией (иначе откуда бы у вас были доступны strDomain, strPassword)?
А вы не рассматривали вариант просто перейти на Windows-аутентифкацию? Там у вас будет доступна имперсонация сразу "из коробки".

Ролг ХупинЕсли я правильно понимаю, то в случае использования WIF сервиса, можно сразу из него получить dupeTokenHandle без плясок с логином и паролем и использовать его для имперсонейта?
Нет. С Identity Service вам будет приходит токен с клеймами, но это не Windows токен.
Однако, взяв этот Claims Token вы сможете обратиться к службе c2WTS (она, как я понимаю, должна быть развернута тут же на сервере) и у нее получить уже Windows Token. Примерно как этот код выглядит, можно посмотреть здесь How to: Request a Token from the c2WTS

Но чтобы это сработало, как я понимаю, ваш Identity Service, среди прочих клеймов в токене, должен выдать Kerberos unique principal name (UPN) - если ничего не путаю, это имя в формате E-Mail. А для этого, он должен понимать, как мапить пользователей, которых он авторизует, на пользователей AD. А это подталкивает к использованию Windows-аутентификации на Identity Service.

Поэтому снова встает вопрос - может проще просто перейти на Windows аутентификацию? На сколько вам реально необходим Identity Service?

да, сейчас так:

юзер из клиентского прложения шифрует и присылает в сервис
домен\имя+пароль

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

Я вот и думаю, если будет отдельно взятый специальный сервис для аутентификации MyIS, юзер будет присылать в сервис ид, полученный из этого специального сервиса, а мой сервис получив этот ид будет запрашивать MyIS, передавая ему ид и получив WindowsIdentity token, при помощи которого мой сервис сможет сделать имперсонейт, не требуя от юзера имя и пароль.

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

МихаилРНо вообще протестировать данный вариант надо очень внимательно. Основная проблема здесь, что при имперсонации, вы можете обращаться только к ресурсам локальной машины, а для доступа к удаленным ресурсам (тому же SQL на другой машине) нужно разрешать делегирование.

С другой стороны - а зачем вам доступ к SQL от имени разных пользователей, у вас какая-то логика на этом построена? Просто если у вас к базе нет прямого обращения с клиентов, а только через сервер приложений, то может стоит подумать - есть ли в принципе смысл в такой имперсонации - это ж лишние сложности, как мне кажется?

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

МихаилРРолг ХупинСейчас я делаю приблизительно так





Я ведь правильно понимаю, что вы сейчас работаете с UserName/Password аутентификацией (иначе откуда бы у вас были доступны strDomain, strPassword)?
А вы не рассматривали вариант просто перейти на Windows-аутентифкацию? Там у вас будет доступна имперсонация сразу "из коробки".

Ролг ХупинЕсли я правильно понимаю, то в случае использования WIF сервиса, можно сразу из него получить dupeTokenHandle без плясок с логином и паролем и использовать его для имперсонейта?
Нет. С Identity Service вам будет приходит токен с клеймами, но это не Windows токен.
Однако, взяв этот Claims Token вы сможете обратиться к службе c2WTS (она, как я понимаю, должна быть развернута тут же на сервере) и у нее получить уже Windows Token. Примерно как этот код выглядит, можно посмотреть здесь How to: Request a Token from the c2WTS

Но чтобы это сработало, как я понимаю, ваш Identity Service, среди прочих клеймов в токене, должен выдать Kerberos unique principal name (UPN) - если ничего не путаю, это имя в формате E-Mail. А для этого, он должен понимать, как мапить пользователей, которых он авторизует, на пользователей AD. А это подталкивает к использованию Windows-аутентификации на Identity Service.

Поэтому снова встает вопрос - может проще просто перейти на Windows аутентификацию? На сколько вам реально необходим Identity Service?

Сам идентити сервис мне не нужен был, но одна из причин:

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

МихаилРРолг Хупин,

Ну тогда как я и писал смотрите в сторону связки WIF + c2WTS.
Да, сразу скажу, что разрабатывать свой Identity Service даже с помощью WIF - задача не самая простая (не то, чтобы супер сложно, но можно убить много времени разбираясь, кто за что отвечает), поэтому, возможно будет удобным взять готовый IS.
Например, Thinktecture IdentityServer 2 (версии 3 и 4 - заточены на OAuth 2).

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