Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Aikin, Вы писали:
S>>>>Ну а теперь на тестовом сервере создаешь виртуальные хосты, забинденные на IP:*, порт:80 и соответствующие host names. A>>У меня IIS 5.1 на XP pro. В котором нельзя создать больше одного вэб узла (витруального хоста). 3 A>Нашел интересный исапи-фильтер: iis_multiplex который позволяет хостить несколько сайтов...
Нифига не выходит. Статический контент он сервит нормально, а вот динамический нет. Видимо не может предоставить asp.net-фильтру (aspnet_filter.dll) нужную информацию. А жаль
Здравствуйте, Aikin, Вы писали: A>У меня IIS 5.1 на XP pro. В котором нельзя создать больше одного вэб узла (витруального хоста).
Придется разжиться Windows Server. Ну или Apache
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Aikin, Вы писали: A>>У меня IIS 5.1 на XP pro. В котором нельзя создать больше одного вэб узла (витруального хоста). S>Придется разжиться Windows Server. Ну или Apache
Так они есть Тестовый в нашей конторе и тестовый у заказчика.
Но хотелось бы у меня на рабочей машинке (апачу ставить не хочу )
Здравствуйте, Aikin, Вы писали: A>Но хотелось бы у меня на рабочей машинке (апачу ставить не хочу )
Ну вот поэтому true web developers работают на Win2k8Server
А те, кто хочет быть белым и пушистым, поднимают win2k8 в VMWare.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Aikin, Вы писали:
A>В моем случае главное, что решение с куками добавляется правкой конфига. Домен же будет всегда один и тот же (99,9%)
Может быть, но есть очень серьёзная вероятность, что в тот момент, когда такая необходимость таки возникнет, ты не вспомнишь об этом допущении, и в итоге некоторое время в дебаггере для тебя и потоки мата с твоего рабочего места для окружающих обеспечены...
Здравствуйте, koandrew, Вы писали:
A>>В моем случае главное, что решение с куками добавляется правкой конфига. Домен же будет всегда один и тот же (99,9%) K>Может быть, но есть очень серьёзная вероятность, что в тот момент, когда такая необходимость таки возникнет, ты не вспомнишь об этом допущении, и в итоге некоторое время в дебаггере для тебя и потоки мата с твоего рабочего места для окружающих обеспечены...
Думаю, такого не будет. Что я уже не замечу что кука идет на общий домен?
При настройке инстанции адаптируется для нее конфиг...
Здравствуйте, Овощ, Вы писали:
>>Есть набор одинаковых вэб приложений (20+ штук). Кажый сайт принадлежит отдельной компании, но пользователи на них одни и те же. >>Вернее даже не так: один и тот же пользователь может иметь доступ к разным инстанциям (приложениям) используя одно и то же имя и пароль.
Забабахал Все работает как часы.
Единственное что, нужно было еще добавить machineKey:
Здравствуйте, Aikin, Вы писали:
A>Вот интересно, как генерить эти ключи? A>Я использовал метод слепого письма: "sdflsdklvcjxvjxkcjvlkxzcjvepdrdsp"? но по цифрам
1) В IIS7 в панели управления вроде видел что то подобное
Здравствуйте, Aikin, Вы писали:
A>Единственное что, нужно было еще добавить machineKey: A>
A> <machineKey
A> validationKey="C50B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE"
A> decryptionKey="8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F"
A> validation="SHA1" />
A>
A>Вот интересно, как генерить эти ключи?
using System;
using System.Text;
using System.Security.Cryptography;
namespace Crypto
{
public class KeyCreator
{
public static void Main(String[] args)
{
String[] commandLineArgs = System.Environment.GetCommandLineArgs();
string decryptionKey = CreateKey(System.Convert.ToInt32(commandLineArgs[1]));
string validationKey = CreateKey(System.Convert.ToInt32(commandLineArgs[2]));
Console.WriteLine("<machineKey validationKey=\"{0}\" decryptionKey=\"{1}\" validation=\"SHA1\"/>", validationKey, decryptionKey);
}
static String CreateKey(int numBytes)
{
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
byte[] buff = new byte[numBytes];
rng.GetBytes(buff);
return BytesToHexString(buff);
}
static String BytesToHexString(byte[] bytes)
{
StringBuilder hexString = new StringBuilder(64);
for (int counter = 0; counter < bytes.Length; counter++)
{
hexString.Append(String.Format("{0:X2}", bytes[counter]));
}
return hexString.ToString();
}
}
}
K>Вынесли форму авторизации в отдельное приложение. При заходе на сайт он редиректит на авторизацию, там проводится авторизация и браузер возвращается на исходный сайт вместе с токеном сессии.
Не совсем понял, как токен переходит от сайта авторизации до конечного сайта, на который хочет зайти пользователь. Не могли бы Вы уточнить. Если он переходит кукой, то каким образом его передать, если сайт авторизации и конечный сайт находятся в разных корневых доменах?
Здравствуйте, slabkoslabko, Вы писали:
S>Не совсем понял, как токен переходит от сайта авторизации до конечного сайта, на который хочет зайти пользователь. Не могли бы Вы уточнить. Если он переходит кукой, то каким образом его передать, если сайт авторизации и конечный сайт находятся в разных корневых доменах?
Как параметр GET-запроса, которым юзер редиректится с сайта авторизации на конечный сайт.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, slabkoslabko, Вы писали:
S>>Не совсем понял, как токен переходит от сайта авторизации до конечного сайта, на который хочет зайти пользователь. Не могли бы Вы уточнить. Если он переходит кукой, то каким образом его передать, если сайт авторизации и конечный сайт находятся в разных корневых доменах?
K>Как параметр GET-запроса, которым юзер редиректится с сайта авторизации на конечный сайт.
Но GET запрос можно перехватить. Можно от этого как-то защититься?
Здравствуйте, Аноним, Вы писали:
А>Но GET запрос можно перехватить. Можно от этого как-то защититься?
А толку? Он одноразовый и может быть насколько угодно сильно привязан к данному экземпляру браузера (вплоть до challenge-response системы). Это всё детали реализации и уровень параноидальности определяется исходя из конкретных условий...
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Аноним, Вы писали:
А>>Но GET запрос можно перехватить. Можно от этого как-то защититься?
K>А толку? Он одноразовый и может быть насколько угодно сильно привязан к данному экземпляру браузера (вплоть до challenge-response системы). Это всё детали реализации и уровень параноидальности определяется исходя из конкретных условий...
правильно я понимаю подход?
Клиент заходит на одно их приложений, получает куку, идентифицирующую его браузер, и редеректится на систему аутентификации. После аутентификации, он по гету передает полученный от системы аутентификации токен и в качестве подтверждения того, что он есть тот кто есть, прикладывает куку полученную в самом начале?
Здравствуйте, Аноним, Вы писали:
А>правильно я понимаю подход?
А>Клиент заходит на одно их приложений, получает куку, идентифицирующую его браузер, и редеректится на систему аутентификации. После аутентификации, он по гету передает полученный от системы аутентификации токен и в качестве подтверждения того, что он есть тот кто есть, прикладывает куку полученную в самом начале?
Как я и сказал, степень параноидальности выбирается по вкусу. Вот что мне пришло в голову (надеюсь вы оцените параноидальность моих мыслей ):
1. Клиент генерит случайное число и затем загоняет его к качестве seed в Random.
2. Затем, используя этот экземпляр Random, он генерит последовательность определяемого в конфиге кол-ва чисел (назовём это значение num) и берёт последнее (назовём его response).
3. seed включается в challenge-тикет при редиректе на авторизацию, полученное число response сохраняется в сессии.
4. Авторизация создаёт объект Random на основе seed, который она получила в составе тикета, и аналогичным образом получает response (серверу также должен юыть известен num). Затем он хэшируется конкатенируется со строкой параметров клиента (тут может быть IP, User Agent и т.п.), полученная строка хэшируется и добавляется в GET-запрос, с которым юзер идёт обратно на целевой сайт.
4. при возврате мы достаём из сессии наш response, собираем строку по аналогии с п.4, хэшируем её и сравниваем с тем, что пришло в GET-запросе. При совпадении считаем авторизацию успешной.
Основан метод на особенности работы ГПСЦ, коим является Random, заключающейся в том, что Random генерирует одинаковую последовательности при одинаковых seed'ах. Для иллюстрации приведу псевдокод.
Целевой сайт, перед отправкой на авторизацию:
var rand = new Random(DateTime.Now);
var seed = rand.Next();
var rand2 = new Random(seed);
var response = 0;
for(var i = 0; i < num; i++)
{
response = rand2.Next();
}
Сервер авторизации:
var rand = new Random(seed);//seed достаётся из параметров запросаfor(var i = 0; i < num; i++)
{
response = rand2.Next();
}
var identString = GenerateClientIdentString(Request); //включаем сюда всё, что по вашему мнению может идентефицировать браузер клиентаvar identString += response.ToString();
var authResponse = GetMD5Hash(identString);
Целевой сайт, после возврата с авторизации:
var identString = GenerateClientIdentString(Request);
var identString += += response.ToString();
var authResponse = GetMD5Hash(identString);
//сравниваем полученных хэш с тем, что получили от авторизации, при совпадении считаем авторацию успешной
для того чтобы пользователь со своими креденциями свободно заходил в другие приложения достаточно в web.confog у всех этих приложений сделать одинаковым ключ
Здравствуйте, <Аноним>, Вы писали:
А>для того чтобы пользователь со своими креденциями свободно заходил в другие приложения достаточно в web.confog у всех этих приложений сделать одинаковым ключ
А><machineKey validation="SHA1" validationKey="..." decryptionKey="..." />
Большое вам спасибо
Но это только часть вопроса. И самое главное, вопрос давным давно уже решен ;-
Здравствуйте, Аноним, Вы писали:
А>для того чтобы пользователь со своими креденциями свободно заходил в другие приложения достаточно в web.confog у всех этих приложений сделать одинаковым ключ
А><machineKey validation="SHA1" validationKey="..." decryptionKey="..." />
Эти настройки не имеют никакого отношения к SSO и вышесказанное не соответствует действительности — не вводите людей в заблуждение...