2010-10-12 4 views
3

Нужно ли использовать сеансы proc во время внедрения единого входа? Каким будет ограничение inproc? , который является лучшим способом реализации единого входа в домене?Single Sign On

ответ

1

Использование сеанса inproc vs. persisted session имеет мало общего с SSO. Основным ограничением сессий inproc является то, что он не будет работать в настройке с балансировкой, но опять же, он имеет мало общего с SSO. Самый простой способ реализовать SSO - использовать Windows Identity Foundation (WIF), который является частью .NET Framework 4.0 (также есть версия, которая работает с .net 3.5). В основном вы просто реализуете a passive STS. Существует несколько проходов.

+0

Мне нужно реализовать в ASP.net 2.0. – Dee

+0

Ну, удачи с этим тогда :-) –

+0

да что отстой. :) Лучше всего будет веб-сервис ASMX (промежуточный сервер). Оба домена будут «разговаривать» с этой веб-службой для выполнения единого входа. И только этот веб-сервис будет заниматься сессией. – RPM1984

0

Если оба этих приложения используют проверку подлинности форм, то это решение легко. Все, что вам нужно сделать, - настроить machineKey для обоих приложений одинаковым и установить домен в файле cookie как .exampledomain.com для web.configs.

0

Если вы используете настраиваемую схему проверки подлинности, построенную вокруг переменных сеанса, возможно, вам стоит подумать о том, чтобы настроить оба сервера на одну и ту же базу данных состояния SQL. Если вы пройдете этот маршрут, вы можете изменить GetTempAppID, чтобы всегда возвращать 1 и настроить machineKey в обоих приложениях одинаковыми. Просто еще одно предложение от вашего дружелюбного sheero. Ха!

0

сеансы inproc будут проблемой, если ваше приложение работает за балансирами нагрузки, поэтому вы можете подумать о сеансах на базе SQL Server, плюс вам также нужно подумать, действительно ли вам нужно обычное SSO, которое просто держит вас автоматически регистрируется, например, если у вашего пользователя разные права/разрешения, установленные на разных сайтах, тогда вы можете добавить какой-то пользовательский код в свою часть входа в систему единого входа, так как вы упоминали, что используете ASP.Net 2.0, поэтому я предполагаю, используйте профили, основанные на ролях .Net для групповой безопасности и разрешений, поэтому вы также можете проверить, не попали ли вы сами в сценарий, когда ваш зарегистрированный пользователь имеет разные разрешения, установленные на разных сайтах. Поэтому для меня это не просто SSO свой пользовательский код входа для конкретного требования, которое вы, возможно, захотите изучить.