ASP.NET Core authentication

[shadow7256]

я бы посоветовал делать все КАК МОЖНО ПРОЩЕ.
тоесть если это какой то портал для внутреннего пользования внутри компании, то не заморачиваться и передовать ID как URL параметр.
сколько ползователей будет пользовать вебсайт в день?
если меньше 1 000 000 в день то не замарачиваться с кэшем а лазить в базу (или где там вы храните groups<-->users)
при каждом обращении к сереверу.

в КРАЙНЕМ случае потом можно будет оптимизировать.

передавать ID чего? ID юзера? ну тогда рано или поздно кастомер узнает какой ID валидный и будет просто напрямую заходить в те приложения в обход портала.. это не есть гуд.

[ie]

передавать ID чего? ID юзера? ну тогда рано или поздно кастомер узнает какой ID валидный и будет просто напрямую заходить в те приложения в обход портала.. это не есть гуд.

SessionID. можно добавить к нему Date-Time и зашифровать, тагда даже "russians" не смогут взломать ваш сайт.

[shadow7256]

передавать ID чего? ID юзера? ну тогда рано или поздно кастомер узнает какой ID валидный и будет просто напрямую заходить в те приложения в обход портала.. это не есть гуд.

SessionID. можно добавить к нему Date-Time и зашифровать, тагда даже "russians" не смогут взломать ваш сайт.

наверное так проще всего будет. При логине в портал генерим SessionID (тот же GUID). Добавляем к линку на другие приложения. При клике на линк приложение откроется, поищет SessionID. Если нет его то кинет обратно на страницу портала. Если есть, залезет в базу, вытащит пользователя, авторизует и вперед..

в гробу я видал все эти custom headers и прочую херню...

[Oleg-NY]

Точно! Нахрен все! Не гугль с амазном какие-нить, вавилоны на голове строить... )))

В вашем последнем: "поищет SessionID" должно уже возвращать юзера - один сервис.

[shadow7256]

Точно! Нахрен все! Не гугль с амазном какие-нить, вавилоны на голове строить... )))

В вашем последнем: "поищет SessionID" должно уже возвращать юзера - один сервис.

тут еще вот в чем проблемка может быть.. Портал может использовать Identity authentication (бывшая Forms) или Windows authentication. В первом случае у клиента будет база данных (тот же SQL Server) с юзерами и группами, а во втором случае юзер будет тащиться из Active Directory. Вот именно поэтому и хотелось сделать так, что портал сам достанет юзера (либо из базы либо из Active Directory), создаст какой то объект класса, заполнит поля, сериализует (в тот же token какой нибудь) и уже передаст его дальше в приложения.. а приложения уже "распакуют" этот объект и обработают..

Допустим одно из приложений написано на ASP.NET MVC, тогда можно было бы в Session_Start вытащить этот токен, распаковать, создать ClaimsPrincipal, добавить claims, выставить этот Principal и все.. клиент "залогинен". Больше ничего делать не надо, остальной код уже будет работать с User (UserPrincipal).. собственно он и щас уже работает..

таким образом приложениям из портала наплевать где живет юзер.. в базе данных или в Active Directory. А так придется порталу генерить SessionID, где то его хранить.. запоминать что с этим SessionID связано и прочее..

[ie]

Допустим одно из приложений написано на ASP.NET MVC, тогда можно было бы в Session_Start вытащить этот токен, распаковать, создать ClaimsPrincipal, добавить claims, выставить этот Principal и все.. клиент "залогинен". Больше ничего делать не надо, остальной код уже будет работать с User (UserPrincipal).. собственно он и щас уже работает..

можно пример как вы это делаете тут запостить.
просто интересно.

[shadow7256]

Допустим одно из приложений написано на ASP.NET MVC, тогда можно было бы в Session_Start вытащить этот токен, распаковать, создать ClaimsPrincipal, добавить claims, выставить этот Principal и все.. клиент "залогинен". Больше ничего делать не надо, остальной код уже будет работать с User (UserPrincipal).. собственно он и щас уже работает..

можно пример как вы это делаете тут запостить.
просто интересно.

мы в свое время для одного клиента (я тут писал уже эту тему) забацали SAML authentication для нашего приложения. Для этого используется third party компонент, который собственно и делает всю грязную работу по работе с SAML. В итоге нам в Session_Start уже приходит готовый ClaimsPrincipal, и вот я его обрабатываю вот так:

Code: Select all

var user = ClaimsPrincipal.Current;

if (user != null && user.Identity.AuthenticationType == "Federation")
{
     var groups = GetSAMLGroupNames (user);
     
     // и так далее..
}

private static List<string> GetSAMLGroupNames(ClaimsPrincipal principal)
{
       var result = new List<string>();

       var groupClaims = principal.Claims.Where(c => c.Type.Contains("Group"));

       if (groupClaims.Any())
       {
            result.AddRange(groupClaims.Select(g => g.Value));
       }
       return result;
}

то есть идея в том, что на начале сессии мы уже знаем Юзера и его группы, держим все это в памяти и работаем. Поэтому было бы вообще круто, если бы портал как то передал эту информацию, я бы в Session_Start просто создал этого Principal и все..

[shadow7256]

вообщем эту безумную идею отвергли. Единственный способ это сделать это поставить SAML server или ADFS и чтобы все 5 приложений имплементировали либо тот либо другой протокол. Все приложения разные по натуре и структуре и это займет тучу времени. Плюс надо будет делать 5 разных auth cookies, по одному для каждого приложения..Плюс не факт что клиенты будут рады самостоятельно обслуживать SAML или ADFS. Это геморрой ох какой большой...

[Flash-04]

Не пишите с нуля как вам тут насоветовали. Найдите готовое single sign on решение. Если вы сами никогда не писали подобное, 100% гарантия что "дырки" будут. Очень наивно думать что это очень просто написать "на коленке".

[Oleg-NY]

Дык у них там целый зоопарк так, что скорее всего придется все ручками, ручками...

[Flash-04]

Ну-ну, тогда потом не жалуетесь

[Oleg-NY]

Ладно вам людей пугать-то! )) Тестировать просто надо хорошо, вот и все дела... )) Не боги горшки обжигают!

[M. Ridcully]

Ладно вам людей пугать-то! )) Тестировать просто надо хорошо, вот и все дела... )) Не боги горшки обжигают!

А тесты будут писать те же люди, что и собственно систему спроектируют?
ИМХО скорее аудит нужен, а не тесты...

[VovaK98]

Как потом правильно переправить юзера на другой домен из Javascript?

Code: Select all

	<script>
		window.location.href = "http://www.google.com";
	</script>

А вообще.. тысячи сайтов используют facebook authentication token. Куча примеров и use cases, что стоит поискать.
Посмотреть, почитать, понять как работает
https://developers.facebook.com/docs/facebook-login/web" onclick="window.open(this.href);return false;
и забацать свою, сильно упрощенную версию.

[shadow7256]

А вообще.. тысячи сайтов используют facebook authentication token. Куча примеров и use cases, что стоит поискать.

наши клиенты не будут использовать facebook authentication

[Oleg-NY]

Так вам вроде и не предлагают...

[shadow7256]

Не пишите с нуля как вам тут насоветовали. Найдите готовое single sign on решение. Если вы сами никогда не писали подобное, 100% гарантия что "дырки" будут. Очень наивно думать что это очень просто написать "на коленке".

это не очень просто мы это знаем. Мы когда делали SAML authentication для клиента ох мы на...сь с этим делом. Но вот именно single sign on мы не делали.

[ie]

вообщем эту безумную идею отвергли. Единственный способ это сделать это поставить SAML server или ADFS и чтобы все 5 приложений имплементировали либо тот либо другой протокол. Все приложения разные по натуре и структуре и это займет тучу времени. Плюс надо будет делать 5 разных auth cookies, по одному для каждого приложения..Плюс не факт что клиенты будут рады самостоятельно обслуживать SAML или ADFS. Это геморрой ох какой большой...

какую идею и кто отверг?
больше деталей можно? просто интересно...

[Flash-04]

Ладно вам людей пугать-то! )) Тестировать просто надо хорошо, вот и все дела... )) Не боги горшки обжигают!

я не пугаю, просто я несколько лет работал "ассесором" разных систем включая Web Apps. Насмотрелся, мама дорогая.... Причём были продукты от компаний с хорошей репутацией. А причина в том, что "типичный" программист о безопасности не думает в принципе и воспринимает требования как досадную помеху в работе. Особенно смешно когда что-то относящееся к безопасности начинают "прикручивать" когда сама система уже говотова, а она в принципе не проектировалась чтобы какой-то там доступ разделять.
Вот посоветовали "прикрутить" facebook authentication. Человек который это посоветовал знает разницу между authentication и authorization?

[Oleg-NY]

Насколько я понял предлагалось не прикручивать FB auth, а покурить и сделать нечто подобное. Нет?
А насчет authorization, так в этом деле напортачить можно с любой, даже самой хорошей third party системой...

P.S. По поводу программеров, так мы вроде не обсуждаем здесь индусо-устойчивость подхода, а чисто идеи, предполагая, что на готове команда с прямыми руками. Как в том фильме "Василий Иванович меняет профессию": Да ты, батюшка, только скажи, а мы переймем (музыканты).

[Flash-04]

"индусо-устойчивость" ни при чём. Тут в Канаде приходилось работать и с "русско-еврейским" коллективом. То же самое, только в профиль.

[ie]

Человек который это посоветовал знает разницу между authentication и authorization?

вот и спецы подтянулись

так вы что-нить посоветовали уже? или только распалцовкой нас будете радовать?

[Flash-04]

моя работа не советовать, а находить "дыры" в том что вы тут насоветуете
мне за это деньги платят. (кстати совет был выше)

[katit]

Я голосую за готовое решение. Читать доки, разбираться, продумывать как это будет имплементироваться все не фан с точки зрения девелоперов. НО. Кода будет меньше чем самому писать и даже если будет больше частей то скорее всего оно будет надежнее. Сейчас я говорю не как девелопер а как человек который не хочет разгребать чье-то "код".

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

[ie]

позволю себе сделать одно маленькое замечание.

надесь уважаемые доны со мно согласятся, что если мы проектируем вебсайт типа амазон -- у нас одни требование к секюрити
если мы проектирум портал для внутреннего пользования в компании из 20 человек, который всегда будет работать ЗА файрволом

у нас ДРУГИЕ требование к секюрити. yes/no/maybe?

т.к. во втором случае конешно можно нагородить гарадулек, и превратить маленький проект на 2-3 дня
в проект на 2-3 месяца с умопомрачительным майтаненс.

agree?