ASP.NET Core authentication

[shadow7256]

Уважаемые.

скоро будем делать новый проект. Использовать будем ASP.NET Core. Суть такова. Есть несколько web applications, установлены все на одном веб сервере (пусть будет IIS). Есть так называемый web portal (вон это и будет новый проект), на котором находится страница логина.

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

Для хранения информации о юзерах мы будем использовать свою базу данных, то есть всякие SAML или third party providers нам не нужны.

Подскажите в какую сторону здесь смотреть, про что учить

Спасибо

[ie]

Подскажите в какую сторону здесь смотреть, про что учить

старый, кандовый способ.. надеюсь не отменили?

как только узер ауторизовался, ему присаваивается ID (session ID or whatever you call it)
это id передается на client side, (cookies, url params)
на server side делаем проверку, если id нет, значит юзер не ауторизован, бай-бай.

[shadow7256]

Ну тут не совсем так просто все. Дело в том, что каждый юзер будет принадлежать каким то группам. Для простоты будем считать что он принадлежит какой то определенной группе. При логине нужно эти группы будет передавать обратно, потому что те линки, которые он будет видеть в своем портале (линки на другие приложения) будут зависеть от того к какой группе он принадлежит. Юзеры в группе А будут видеть одни линки.. юзеры в группе В будут видеть другие линки...

может быть какой нибудь IdentityServer использовать? типа IdentityServer4....

и потом эти Группы (Роли) нужно будет также как то передавать в другие приложения, доступные юзеру.

То есть портал это централизованое место для логина. После логина юзеры могут "шляться" по другим приложениям. Но другие приложения должны знать что юзер залогинен и к каким Группам он принадлежит..

[ie]

Ну тут не совсем так просто все. Дело в том, что каждый юзер будет принадлежать каким то группам. Для простоты будем считать что он принадлежит какой то определенной группе. При логине нужно эти группы будет передавать обратно, потому что те линки, которые он будет видеть в своем портале (линки на другие приложения) будут зависеть от того к какой группе он принадлежит. Юзеры в группе А будут видеть одни линки.. юзеры в группе В будут видеть другие линки...

может быть какой нибудь IdentityServer использовать? типа IdentityServer4....

и потом эти Группы (Роли) нужно будет также как то передавать в другие приложения, доступные юзеру.

То есть портал это централизованое место для логина. После логина юзеры могут "шляться" по другим приложениям. Но другие приложения должны знать что юзер залогинен и к каким Группам он принадлежит..

эти группы где-то хранятся так? тоесть допустим в дб у нас связка userid<-->group
на сервере (или клинте) ваши приложения должны проверять принадлежит ли текущий user к правильной группе
и соответсвенно выдавать (enable/disable) соответсвующие линки...

тут у вас как бы две (или больше) отдельные задачи:
1) user authentication
2) user authentication persistence between different apps (servers?)
3) app configuration based on #1

[VovaK98]

В целом я согласен с IE.
На самом деле, есть такое понятие как authorization token, который выдается юзверю.
И вот с ним он и скачет по всем приложениям.

Эти applications, когдя видят токен у юзверя, просто стучатся в центральный authentication server (or app) и проверяют этот токен на валидность и group membership.
(Блин, проще было бы по английски написать )

Можно конечно поставить identityserver или еще какое-то 3rd party SSO решение, но кмк authorization token весьма просто написать с нуля. И если не быстрее, то уж точно понятнее, чем въезжать в чей-то код.

Пример: https://developers.facebook.com/docs/fa ... usertokens" onclick="window.open(this.href);return false;

Disclaimer: в интернетах это называется 'authentication token', но кмк, тут речь идёт о group membership and roles, так что я назвал это authorization token.

[Oleg-NY]

В порядке бреда, а почему не зашифровать всю нужную инфу о группах/привелегиях и не засунуть ее в те же куки, чтобы апликухи не ходили каждый раз к сервису за ней, что есть сильно дольше, чем расшифровать? Я бы лишний раз к базе не обращался и особенно если пользователей много...

[VovaK98]

В порядке бреда, а почему не зашифровать всю нужную инфу о группах/привелегиях и не засунуть ее в те же куки, чтобы апликухи не ходили каждый раз к сервису за ней, что есть сильно дольше, чем расшифровать? Я бы лишний раз к базе не обращался и особенно если пользователей много...

Можно и так..
Но если session/token lifespan несколько часов или даже дней, то юзеру придется перелогиниваться тут же как только поменялась его группа.
А можно и скомбинировать решение. Если юзер в основном read-only, то можно и в куках это прописать. Как только ему дается более широкий access, то пусть сверяется с базой.

[Oleg-NY]

Ну да. Но по-моему если что-то такое меняется, то юзера заставляют перелогиниваться. Особенно если его демоутнули.

[katit]

В порядке бреда, а почему не зашифровать всю нужную инфу о группах/привелегиях и не засунуть ее в те же куки, чтобы апликухи не ходили каждый раз к сервису за ней, что есть сильно дольше, чем расшифровать? Я бы лишний раз к базе не обращался и особенно если пользователей много...

Можно и так..
Но если session/token lifespan несколько часов или даже дней, то юзеру придется перелогиниваться тут же как только поменялась его группа.

У меня в аппе оно грузится при логине и будет работать пока пользователь не перелогинится

[VovaK98]

У меня в аппе оно грузится при логине и будет работать пока пользователь не перелогинится

Mobile apps все-таки более stateful (если так можно выразиться). В отличие от web applications.
Но как я предложил выше, можно скомбинировать оба метода. Если юзер изначально read-only, то его атрибуты можно хранить в session cookies. Если более широкий access, то стучаться в базу. Хоть через раз, или только в ответственных частях приложения.

[katit]

У меня в аппе оно грузится при логине и будет работать пока пользователь не перелогинится

Mobile apps все-таки более stateful (если так можно выразиться). В отличие от web applications.
Но как я предложил выше, можно скомбинировать оба метода. Если юзер изначально read-only, то его атрибуты можно хранить в session cookies. Если более широкий access, то стучаться в базу. Хоть через раз, или только в ответственных частях приложения.

Я именно про web app. Кука хоть и кука но ее надо туда сюда гонять всеравно. Я думаю что просто сделаю логаут по inactivity timeout когда нибудь. И может в ну очень критических местах проверку добавлю вместе с паролем заодно.

[shadow7256]

эти группы где-то хранятся так? тоесть допустим в дб у нас связка userid<-->group

ну да. В базе хранится все.

тут у вас как бы две (или больше) отдельные задачи:

именно

1) user authentication

да. Вот открылась страница логина. Допустим ввел я имя и пароль.. при использовании той же forms authentication все за меня сделает membership. А тут что делать? Вот допустим я обнаружил что юзер в базе есть.. вытащил его группы, вернул.. и как дальше с ними быть,

2) user authentication persistence between different apps (servers?)

а вот как сделать вообще не представляю.. это собвственно продолжение первого пункта..

[BronenosezPotemkin]

По моему, нужно написать один Web/WCF Service, который будет ответсвенен за работу с базой данных(Data Access Layer), а также за User authentication/authorization. Все веб приложения должны будут авторизироваться, получить токен у этого сервиса и передавать его каждый раз вместе с другими переменными для получения/изменения данных.

[Oleg-NY]

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

[ie]

как вариант можно кэшировать на сервере. надеюсь сервер TC-ра это позволяет делать.

[ie]

В порядке бреда, а почему не зашифровать всю нужную инфу о группах/привелегиях и не засунуть ее в те же куки, чтобы апликухи не ходили каждый раз к сервису за ней, что есть сильно дольше, чем расшифровать? Я бы лишний раз к базе не обращался и особенно если пользователей много...

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

[Oleg-NY]

Сервер - понятие абстрактное, а не физическое. Лучше абстрагироваться от этого, тогда легче будет спрятаться за load balancer.

[Oleg-NY]

В порядке бреда, а почему не зашифровать всю нужную инфу о группах/привелегиях и не засунуть ее в те же куки, чтобы апликухи не ходили каждый раз к сервису за ней, что есть сильно дольше, чем расшифровать? Я бы лишний раз к базе не обращался и особенно если пользователей много...

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

Я подумал об этом и потому не отверг хождение за валилацией токена на сервис, но только для этого: да или нет.

[shadow7256]

тут геморой еще вот в чем. Те другие приложения они "изготовлены" из разных технологий. Одно приложение сделано на ASP.NET MVC 2, другое приложение это вообще SPA (AngularJS 1.5). Каждое из них сейчас понятно дело по разному работает с authenticantion/authorization.

Вот допустим пользователь залогинился на главном портале. Допустим получил в ответ объект какого нибудь класса User. Все валидно, объект содержит кучу полей. Дальше он видит на странице портала несколько URLs которые открывают разные приложения...А дальше что? Как передать этот объект тем другим приложениям? Как дать понять приложениям что пользователь залогинен ?

[shadow7256]

пока вырисовывается такая картина..пользователь логинится в портал. Происходит валидация, пользователь установлен, получена инфа о нем. Затем портал строит token (каким нибудь образом зашифрованый) в котором зашифрованы имя пользователя и его Группы. Потом этот токен каким то образом (а вот каким?) передается в другие приложения. Передавать через URL параметр не комильфо.. токен может быть длинным. то есть надо как то через POST делать и помещать Token в хедере... а красиво ли открывать приложение через POST запрос?

но вообще проблематично будет. Единственный способ передать инфу это добавить хедер, а добавлять его придется через Javascript...А потом делать запрос на другой домен через тот же Ajax. CORS не позволит это сделать.

[Oleg-NY]

Какое отношение тип запроса (GET/POST/etc.) имеет к headers в которых куки живут? Вы полагаете, что headers только у POST бывают? Боюсь вам надо почитать азы, а то вы слишком понижаете нам уровень дискуссии...

[shadow7256]

Какое отношение тип запроса (GET/POST/etc.) имеет к headers в которых куки живут? Вы полагаете, что headers только у POST бывают? Боюсь вам надо почитать азы, а то вы слишком понижаете нам уровень дискуссии...

дело не в GET/POST... хедер можно добавить только через Javascript.. а потом сделать вызов на другой домен. Лишь немногие современные браузеры позволят это сделать...

[ie]

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

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

[Oleg-NY]

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

[shadow7256]

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

Добавить custom header скриптом проблем вообще нет. Как потом правильно переправить юзера на другой домен из Javascript?

Code: Select all

<a href="javascript:Go();">Go To SnF</a>

<script language="javascript" type="text/javascript">

    function Go() {
        $.ajax({
            type: 'POST',
            url: "http://localhost:39079",
            headers: {
                "Auth": "asdfasdfasdfasdf"
            }
        });
    };

</script>

в данном случае вызовется код из приложения на http://localhost:39079" onclick="window.open(this.href);return false;, все окейно, но пользователь все равно останется на той странице где находится линк Go... наверное я как то неправильно делаю редирект.

когда я говорил про "не все браузеры" я имел в виду, что не все браузеры позволяют делать Cross domain request.