ASP.NET Core authentication

[Flash-04]

В теории да. Но я не заметил чтобы TC говорил о чисто интранетном приложении. Да и в таких тоже есть свои требования. Помнится я такую HR систему проверял...

[ie]

В теории да. Но я не заметил чтобы TC говорил о чисто интранетном приложении. Да и в таких тоже есть свои требования. Помнится я такую HR систему проверял...

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

[Flash-04]

В упомянутом случае? А пожалуйста: через 10 минут после логина (нам выдали тестовые экаунты) я обнаружил что имею доступ ко всем экаунтам read/write простой манипуляцией запроса к серверу. Ну а подумать что делать, я предоставлю вам

[ie]

В упомянутом случае? А пожалуйста: через 10 минут после логина (нам выдали тестовые экаунты) я обнаружил что имею доступ ко всем экаунтам read/write простой манипуляцией запроса к серверу. Ну а подумать что делать, я предоставлю вам

это все что вы можете сказать? нигуста, нигуста.

[Flash-04]

А больше я вам и не собирался говорить. NDA знаете ли.

[Oleg-NY]

В упомянутом случае? А пожалуйста: через 10 минут после логина (нам выдали тестовые экаунты) я обнаружил что имею доступ ко всем экаунтам read/write простой манипуляцией запроса к серверу. Ну а подумать что делать, я предоставлю вам

Ну вот это обычно и происходит, когда люди путаются в таких понятиях как URL, GET, POST и headers. А всего-то нужно один раз передать зашифрованный блоб в апликуху при форвардинге после authentication, где он будет храниться в сессии (если оная поддерживается) или любым другим способом.

[ie]

А больше я вам и не собирался говорить. NDA знаете ли.

"у нас есть такие системы, но мы вам про них нираскажим"

но распальцовка была классная.

[Flash-04]

Не у нас, а у клиента. Вы лучше про себя расскажите. Что вы в своих "рогах и копытах" пишите?

[Flash-04]

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

Не всего то, а для начала нужно аккуратно описать что с этим "блобом" северное приложение делает, и ещё до того надо аккуратно описать модель доступа которую имплементировать собираетесь.

[ie]

Не у нас, а у клиента. Вы лучше про себя расскажите. Что вы в своих "рогах и копытах" пишите?

вот Флаш... with all due respect как грица...
вы как бы пришли в гараж, тут механики в масле и грязных комбезах чинят машины, обмениваются опытoм
тут вы выдаете: "все неправильно, я вот недавно мотор переберал, а там таакоеееее"

и на конкретный вопрос, что там "такоеее" ответ "он не работал"

"а больше я вам нискажу т.к. у меня NDA."

[Flash-04]

Не передергивайте. Я вам по существу ответил. Что там унутри неонки было, по сути не важно. Исходный код нам не показывали, по условию был black box test. Но могу предположить что вот что-то на коленке писаное.
Тезис был: "не пишите свое, если у вас в этом нет опыта". Данный пример его подтверждает.

[Oleg-NY]

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

Не всего то, а для начала нужно аккуратно описать что с этим "блобом" северное приложение делает, и ещё до того надо аккуратно описать модель доступа которую имплементировать собираетесь.

Гоните! Сей блоб ни что иное как то же самое, что чел собирался вытаскивать про юзера из базы данных. Это вообще две разные темы: как разделять доступ и описывать права юзера в базе и как сделать так, чтобы апп не ходила за этими данными по несколько раз.

[ie]

Не передергивайте. Я вам по существу ответил. Что там унутри неонки было, по сути не важно. Исходный код нам не показывали, по условию был black box test. Но могу предположить что вот что-то на коленке писаное.

вот именно. это может быть "на коленке" это может быть "готове решение" которое прикрутили неправильно,
это может быть какой то test mode который забыли отключить..

[Flash-04]

Нет, точно не это.

[Flash-04]

Гоните! Сей блоб ни что иное как то же самое, что чел собирался вытаскивать про юзера из базы данных. Это вообще две разные темы: как разделять доступ и описывать права юзера в базе и как сделать так, чтобы апп не ходила за этими данными по несколько раз.

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

[ie]

Нет, точно не это.

"black box" оказался немного прозрачным?

[shadow7256]

Ну вот это обычно и происходит, когда люди путаются в таких понятиях как URL, GET, POST и headers. А всего-то нужно один раз передать зашифрованный блоб в апликуху при форвардинге после authentication, где он будет храниться в сессии (если оная поддерживается) или любым другим способом.

ну вот как раз в этом то и дело, что "просто передать зашифрованый блоб" не получится. Как я уже сказал там 5 разных web applications, выполненых по разным технологиям, каждая из них по разному работает с authentication/authorization, у каждой свои правила какие то. Из этих пяти я плотно работал только с одним приложением, которое сделано на ASP.NET MVC. Ну передали туда этот блоб.. и дальше что? по крайней мере нужно будет выставить CurrentPrincipal, чтобы дать понять приложению что юзер залогинен. Просто так в любом месте его выставить не получится.. допустим мы передали блоб каким то образом и вызвался обработчик Session_Start, мы там раскрыли блоб, создали CurrentPrincipal, выставили его и радуемся.. фиг с маслом. После того как Session_Start закончит работу этот CurrentPrincipal тут же потеряется и пользователь опять будет not authenticated. Мы столько натрахались с этим уже.. именно поэтому использовали в одном проекте (для SAML) спец компонент. Он глубоко внедряется в ASP.NET pipeline и делает все работу.

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

[Oleg-NY]

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

[Flash-04]

оказался немного прозрачным?

нет конечно. Хорошо, перефразирую: судя по тому как можно было манипулировать запросами, это не было похоже на готовые решения известные мне на тот момент.

[ie]

оказался немного прозрачным?

нет конечно. Хорошо, перефразирую: судя по тому как можно было манипулировать запросами, это не было похоже на готовые решения известные мне на тот момент.

ткните пальцем на готовые решения? или на вебсайты которые используют эти решения?

[shadow7256]

но да, надо идти глубже и что-то делать custom как те же handlers.

абсолютно.

Сама аутентификация - дело специфическое для каждой аппликухи

"Обратно согласен" (с.)

[Flash-04]

ткните пальцем на готовые решения? или на вебсайты которые используют эти решения?

зависит от требований. Если к примеру чисто Windows среда и много завязано на AD, смотреть в сторону ADFS.
Если у вас что-то "нейтральное", то к примеру Auth0. Да там много разных. Читайте описание, отзывы, выбирайте что больше подходит.

[Palych]

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

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

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

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

agree?

Мне кажется тут упускается один момент:
"Требования к секьюрити" - это способ логина, цвет букв на Login screen, etc.
То о чем говорил Flash-04 - дырки в секьюрити. Тут требование одно: их не должно быть.
И действительно - очень многие программисты почему-то делаются очень обидчивыми когда им говорят о authentication, authorization... Я искренне не понимаю этого феномена. Стараюсь избегать этих тем, к счастью не отвечаю за это.