Всем привет.

Есть набор одинаковых вэб приложений (20+ штук). Кажый сайт принадлежит отдельной компании, но пользователи на них одни и те же.
Вернее даже не так: один и тот же пользователь может иметь доступ к разным инстанциям (приложениям) исползуя одно и то же имя и пароль.
Это достигается существованием сайта-координатора (Директория) который занет какой пользователь имеет доступ к какой инстанции, предоставляет сводную информацию со всех инстанций пользователей, синхронизирует изменения в профиле пользователя со всеми инстанциями.

Так как сайты представляют собой разные приложения, то у них разные сессии (сделать шаред сессию не предлагать -- поломается все нафик). Так что если пользователь залогинен на сайте1, то на сайте2 ему нужно все равно вводить пароль для входа. Вот это-то и бесит пользователей.

Появилась задача: если пользователь залогинен на одном из сайтов, то его нужно автоматически логинить и на все остальные инстанции. Как только все сессии на всех сайтах истекут, его нужно кидать на логин.
Возможно эта ситуация уже имеет стандартное решение (что-то типа OpenID). Было бы очень здорово.


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

Т.е. основная задача с которой я пришел на форум: как определить что на инстанцию заходит юзер который уже залогинился на другой?
Или в технических терминах: как определить что на инстанцию обращается браузер из которого уже был логин в систему?




Мои мысли:
Нужно как-то идентефицировать браузер юзера.
1) Можно было бы использовать куки, но дело в том, что у каждого сайта свой собственный домен: у дериктории -- directory.com, у инстанций -- somecompany.directory.com, othercompany.directory.com, ...
2) Можно было бы потребовать перехода по всем инстанциям один раз чтобы в куки легла информация о пользователе, но это дыра в безопастности.
3) Можно было бы использовать IP для маппинга, но IP может быть один и тот же для группы пользователей
...
n) в общем ищется некий ID браузера

Зарание спасибо
СУВ, Aikin

Здравствуйте, Aikin.

Кое-какие мысли возникли по этому пункту:
A>1) Можно было бы использовать куки, но дело в том, что у каждого сайта свой собственный домен: у дериктории -- directory.com, у инстанций -- somecompany.directory.com, othercompany.directory.com, ...

(краткая справка)
http://www.citforum.ru/internet/html/cookie.shtml

Итак, cookie является частью HTTP заголовка. Полное описание поля Set-Cookie HTTP заголовка:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME; secure
....
domain=DOMAIN_NAME — домен, для которого значение cookie действительно. Например, "domain=cit-forum.com". В этом случае значение cookie будет действительно и для домена cit-forum.com, и для www.cit-forum.com. Но не радуйтесь, указания двух последних периодов доменных имен хватает только для доменов иерархии "COM", "EDU", "NET", "ORG", "GOV", "MIL" и "INT". Для обсуждаемых сейчас новых семи доменов первого уровня ("FIRM", "SHOP", "WEB", "ARTS", "REC", "INFO", "NOM"), вероятно, это условие сохранится. Для доменов иерархии "RU", например, придется указывать три периода.

Если этот атрибут опущен, то по умолчанию используется доменное имя сервера, на котором было задано значение cookie.

Т.е. мысль такая, что для конкретной cookie можно явно установить домен, который будет соответствовать некоторму "общему" домену (directory.com), и соответственно такая кука должна передаваться в запросах ко всем доменам, которые являются "дочерними" для нашего "общего" домена (somecompany.directory.com, othercompany.directory.com).

Здравствуйте, Овощ, Вы писали:

Спасибо. Сейчас как раз залез в MSDN по кукам:

You can also use the Domain property to create a cookie that can be shared among multiple subdomains, as shown in the following example:

Response.Cookies["domain"].Value = DateTime.Now.ToString();
Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);
Response.Cookies["domain"].Domain = "contoso.com";

The cookie will then be available to the primary domain as well as to sales.contoso.com and support.contoso.com domains.

Надо попробовать.

Один момент: можно ли из support.contoso.com выставить куку для contoso.com?

Иначе придеться все время логиниться из Директории. Что не так уж и плохо, но все же...

Здравствуйте, Aikin, Вы писали:
A>Есть набор одинаковых вэб приложений (20+ штук). Кажый сайт принадлежит отдельной компании, но пользователи на них одни и те же.
A>Вернее даже не так: один и тот же пользователь может иметь доступ к разным инстанциям (приложениям) исползуя одно и то же имя и пароль.
A>Это достигается существованием сайта-координатора (Директория) который занет какой пользователь имеет доступ к какой инстанции, предоставляет сводную информацию со всех инстанций пользователей, синхронизирует изменения в профиле пользователя со всеми инстанциями.

A>Один момент: можно ли из support.contoso.com выставить куку для contoso.com?
A>Иначе придеться все время логиниться из Директории. Что не так уж и плохо, но все же...

Совершенно нормально. Достаточно просто использовать Директорию для логина на всех сайтах.
То есть такой flow имеется в виду:
1. Заходим на application1.directory.com
2. Идем на защищенную страничку application1.directory.com/private
3. Обнаружив отсутствие сессии, страничка делает редирект на
http://directory.com/login?returnUrl=application1.directory.com/private
4. Там пользователь указывает пароль и делает POST туда же
5. Форма логина отдает куки и редирект обратно на application1.directory.com/private
6. Теперь уже кука на месте, и страничка может авторизовать пользователя.

Здравствуйте, Sinclair, Вы писали:

A>>Иначе придеться все время логиниться из Директории. Что не так уж и плохо, но все же...
S>Совершенно нормально. Достаточно просто использовать Директорию для логина на всех сайтах.
Вопрос не технического характера, а т.н. человеческий фактор: лезем на инстанцию, а нас кидают логиниться на директорию -- конфуз.
Хотя привыкнут. Куда они денутся
В любом случае это лучше чем постоянные логины-перелогины.

S>То есть такой flow имеется в виду:
Это понятно. Это стандартный flow

Здравствуйте, Aikin, Вы писали:

A>Один момент: можно ли из support.contoso.com выставить куку для contoso.com?

На 100% не уверен, но мне кажется что можно.
Если в теории, то надо посмотреть на RFC 2965 (вроде бы именно он актуален сейчас).

3.3.2 Rejecting Cookies

Правила там не совсем тривиальные но чуть ниже есть такой пример:

* A Set-Cookie2 from request-host x.foo.com for Domain=.foo.com
would be accepted.

Так что должно быть все нормально.

Еще по изначальной теме — можно покопать в сторону third-party cookies. Их зачастую используют для слежения за тем на какие сайты заходил пользователь.
Но, по-моему, их получится использовать и в наших мирных целях.

Здравствуйте, Овощ, Вы писали:

A>>Один момент: можно ли из support.contoso.com выставить куку для contoso.com?
О>Правила там не совсем тривиальные но чуть ниже есть такой пример:

О>

О>* A Set-Cookie2 from request-host x.foo.com for Domain=.foo.com
О> would be accepted.

О>Так что должно быть все нормально.
Отлично.

О>Еще по изначальной теме — можно покопать в сторону third-party cookies. Их зачастую используют для слежения за тем на какие сайты заходил пользователь.
О>Но, по-моему, их получится использовать и в наших мирных целях.
Не, это уж слишком


СУВ, Aikin

С решением определился.
Только вот вопрос: как это дело тестировать? Не на продакшене же
Тестовый сервер не имеет субдоменов: инстанции являются виртуальными каталогами

>Есть набор одинаковых вэб приложений (20+ штук). Кажый сайт принадлежит отдельной компании, но пользователи на них одни и те же.
>Вернее даже не так: один и тот же пользователь может иметь доступ к разным инстанциям (приложениям) используя одно и то же имя и пароль.

Ах да. Если ты пользуешься стандартной forms-аутентификацией, то делать-то тебе почти ничего не придется.
Достаточно во всех web-приложениях в субдоменах чуток подкорректировать web.config.
А именно задать корректный атрибут domain в елементе forms:
forms Element for authentication (ASP.NET Settings Schema)

<forms
name="name"
loginUrl="URL"
defaultUrl="URL"
protection="[All|None|Encryption|Validation]"
timeout="[MM]"
path="path"
requireSSL="[true|false]"
slidingExpiration="[true|false]">
enableCrossAppRedirects="[true|false]"
cookieless="[UseUri|UseCookie|AutoDetect|UseDeviceProfile]"
domain="domain name">
<credentials>...</credentials>
</forms>

domain
Optional attribute.
Specifies an optional domain to set on outgoing forms-authentication cookies. This setting takes precedence over the domain that is used in the httpCookies element.
This attribute is new in the .NET Framework version 2.0.
The default is an empty string ("").

Здравствуйте, Овощ, Вы писали:

О>Ах да. Если ты пользуешься стандартной forms-аутентификацией, то делать-то тебе почти ничего не придется.
О>Достаточно во всех web-приложениях в субдоменах чуток подкорректировать web.config.
Супер!

Вот только сама Директория написана на монорельсах и использует свою собственную аутентефикацию. Прикрутить Forms чтоли?

Здравствуйте, Aikin, Вы писали:

A>С решением определился.
A>Только вот вопрос: как это дело тестировать? Не на продакшене же
A>Тестовый сервер не имеет субдоменов: инстанции являются виртуальными каталогами

Дык насоздавай сайтов с хидерами разными и каталогами разными, но на один порт; а в hosts на своей машине пропиши имена и IP. Я так делал.

Здравствуйте, denisio_mcp, Вы писали:

_>Здравствуйте, Aikin, Вы писали:

A>>С решением определился.
A>>Только вот вопрос: как это дело тестировать? Не на продакшене же
A>>Тестовый сервер не имеет субдоменов: инстанции являются виртуальными каталогами

_>Дык насоздавай сайтов с хидерами разными и каталогами разными, но на один порт; а в hosts на своей машине пропиши имена и IP. Я так делал.
А можно поподробнее?

Здравствуйте, Aikin, Вы писали:
A>Вопрос не технического характера, а т.н. человеческий фактор: лезем на инстанцию, а нас кидают логиниться на директорию -- конфуз.
Никто этого не увидит. Обрати внимание, что у большинства современных порталов логин бегает по другому URL, чем основной сайт. Вот, к примеру, Live ID
A>Хотя привыкнут. Куда они денутся
Главное, чтобы они доверяли корневому сайту.

Здравствуйте, Aikin, Вы писали:

_>>Дык насоздавай сайтов с хидерами разными и каталогами разными, но на один порт; а в hosts на своей машине пропиши имена и IP. Я так делал.
A>А можно поподробнее?
Он имеет в виду, что у себя на локальной машине нужно найти файл C:\Windows\System32\Drivers\etc\hosts
И добавить в него записи вида

127.0.0.1 server1.directory.com
127.0.0.1 server2.directory.com
127.0.0.1 directory.com

(Это если сервер поднят у тебя на машине. Если тестовый сервер расположен не у тебя, то укажи здесь его IP вместо loopback)
Ну а теперь на тестовом сервере создаешь виртуальные хосты, забинденные на IP:*, порт:80 и соответствующие host names.
Ничего страшного, что кроме тебя никто про эти домены знать не будет.

Здравствуйте, Aikin, Вы писали:

>Есть набор одинаковых вэб приложений (20+ штук). Кажый сайт принадлежит отдельной компании, но пользователи на них одни и те же.
>Вернее даже не так: один и тот же пользователь может иметь доступ к разным инстанциям (приложениям) исползуя одно и то же имя и пароль.
>Это достигается существованием сайта-координатора (Директория) который занет какой пользователь имеет доступ к какой инстанции, предоставляет сводную информацию со всех инстанций пользователей, синхронизирует изменения в профиле пользователя со всеми инстанциями.

>Так как сайты представляют собой разные приложения, то у них разные сессии (сделать шаред сессию не предлагать -- поломается все нафик). Так что если пользователь залогинен на сайте1, то на сайте2 ему нужно все равно вводить пароль для входа. Вот это-то и бесит пользователей.

Мдя, у меня была похожая задача, только решение с куками не подходило принципиально — ибо сайты находились в разных доменах первого уровня (.ca, .com. net). Как сделалив итоге:

Вынесли форму авторизации в отдельное приложение. При заходе на сайт он редиректит на авторизацию, там проводится авторизация и браузер возвращается на исходный сайт вместе с токеном сессии. Затем этот токен кэшируется в куке, и при повторном заходе сервер через веб-сервис идёт на сервер авторизации и проверяет валидность токена. Если токен невалидный, то юзера отправляют на авторизацию, если валиден — ну тут и так понятно Сервер авторизации также кэширует токен, и при заходе на другой сайт проекта, будучи авторизованным на первом, приложение авторизации сразу отправляет юзера обратно с токеном.

Кстати, подобным образом работает всем известная Microsoft Passpost. По-моему, решение гораздо более надёжное и изящное, чем шаманство с куками, которое отвалится сразу же, как только возникнет необходимость накрыть SSO (Single Sign-On — так называются подобные системы) домен за пределами вашей доменной зоны...

Здравствуйте, koandrew, Вы писали:

K>Мдя, у меня была похожая задача, только решение с куками не подходило принципиально — ибо сайты находились в разных доменах первого уровня (.ca, .com. net). Как сделалив итоге:

K>Вынесли форму авторизации в отдельное приложение. При заходе на сайт он редиректит на авторизацию, там проводится авторизация и браузер возвращается на исходный сайт вместе с токеном сессии. Затем этот токен кэшируется в куке, и при повторном заходе сервер через веб-сервис идёт на сервер авторизации и проверяет валидность токена. Если токен невалидный, то юзера отправляют на авторизацию, если валиден — ну тут и так понятно Сервер авторизации также кэширует токен, и при заходе на другой сайт проекта, будучи авторизованным на первом, приложение авторизации сразу отправляет юзера обратно с токеном.

K>Кстати, подобным образом работает всем известная Microsoft Passpost. По-моему, решение гораздо более надёжное и изящное, чем шаманство с куками, которое отвалится сразу же, как только возникнет необходимость накрыть SSO (Single Sign-On — так называются подобные системы) домен за пределами вашей доменной зоны...

Что-то похожее сделано, кстати, в JA-SIG CAS (правда, это для Java). Видимо, это типичный способ реализации междоменного SSO.

Только для пущей безопасности там токен, выдаваемый сервису, одноразовый и генерируется специально для конкретного сервиса (т.е перехватив чужой токен в другой сервис не залогинишься от этого пользователя). После аутентикации на сервере CAS (который выдаёт юзеру безопасную куку, т.е она передаётся только по HTTPS), пользователя редиректят обратно на сервис с этим одноразовым токеном. Сервис запросом к серверу CAS (по HTTPS, таким образом проверяется аутентичность сервера CAS) проверяет токен (и токен автоматом становится невалидным, т.е перехватив токен повторно залогиниться с ним уже не удастся) и уже у себя в сессии сохраняет информацию о аутентичности пользователя.

Здравствуйте, Sinclair, Вы писали:

Про hosts я знаю.
S>Ну а теперь на тестовом сервере создаешь виртуальные хосты, забинденные на IP:*, порт:80 и соответствующие host names.
А вот про это нет Поразбираюсь, пасиб.

Здравствуйте, koandrew, Вы писали:


K>Вынесли форму авторизации в отдельное приложение. При заходе на сайт он редиректит на авторизацию, там проводится авторизация и браузер возвращается на исходный сайт вместе с токеном сессии. Затем этот токен кэшируется в куке, и при повторном заходе сервер через веб-сервис идёт на сервер авторизации и проверяет валидность токена. Если токен невалидный, то юзера отправляют на авторизацию, если валиден — ну тут и так понятно Сервер авторизации также кэширует токен, и при заходе на другой сайт проекта, будучи авторизованным на первом, приложение авторизации сразу отправляет юзера обратно с токеном.
Понятно! Большое спасибо. А я-то думал как, блин, определить, что это именно тот пользователь

А тут все просто: при редиректе на отдельную логин-страницу (одну на все домены), для нее будет доступна своя кука, по которой и будет идентефицирован пользователь... (Голова два уха )


K>По-моему, решение гораздо более надёжное и изящное, чем шаманство с куками, которое отвалится сразу же, как только возникнет необходимость накрыть SSO (Single Sign-On — так называются подобные системы) домен за пределами вашей доменной зоны...
В моем случае главное, что решение с куками добавляется правкой конфига. Домен же будет всегда один и тот же (99,9%)

Здравствуйте, Aikin, Вы писали:

S>>Ну а теперь на тестовом сервере создаешь виртуальные хосты, забинденные на IP:*, порт:80 и соответствующие host names.
У меня IIS 5.1 на XP pro. В котором нельзя создать больше одного вэб узла (витруального хоста). 3
На тестовом серваке можно это сделать, но не хотелось бы.

Здравствуйте, Aikin, Вы писали:

S>>>Ну а теперь на тестовом сервере создаешь виртуальные хосты, забинденные на IP:*, порт:80 и соответствующие host names.
A>У меня IIS 5.1 на XP pro. В котором нельзя создать больше одного вэб узла (витруального хоста). 3
Нашел интересный исапи-фильтер: iis_multiplex который позволяет хостить несколько сайтов...
Но что-то какой-то он халявный (выдержка из инструкции по установки):

2.
Edit iis_multiplex_mappings.txt. The first line is the root that
the web server is set to. This would be where your normal document
root would be. The remaining lines are server names, and where the new
document root should be for those servers. For example, here's a
sample iis_multiplex_mappings.txt file:
----------------
c:\myroot\siteA
siteA.com c:\myroot\betterA
siteB.com c:\myroot\betterB
----------------
In this case, under the IIS properties, the 'Default Web Site's home
directory would be 'c:\myroot\siteA'. When someone goes to siteA.com,
documents would be served from c:\myroot\betterA instead, and when
they go to siteB.com, documents would be served from
c:\myroot\betterB.

Но для теста думаю, сойдет