Борьба с WIF за мой собственный IPrincipal в приложении MVC
Я хочу добавить Azure ACS на один из моих сайтов, но у меня возникают проблемы со всей магией. У меня есть приложение MVC, которое использует глобальный фильтр, чтобы установить собственный IPrincipal для жизни запроса. Проблема с методологией "добавить ссылку на STS" в WIF заключается в том, что она замыкает это через модуль HttpModule.
Вот что я знаю: ACS возвращается к моему веб-приложению по URL-адресу, для которого я его настроил, и этот отскок представляет собой POST с нормализованным токеном SAML. Меня не интересуют настройки файлов cookie WIF или что-то в этом духе... Я просто хочу получить претензии, которые меня интересуют, от POST и сам оттуда разбираюсь с настройками аутентификации. Какой рабочий процесс? Документация паршивая, и фокусируется на волшебном решении "щелчка правой кнопкой мыши".
2 ответа
Я думаю, что есть действительно простое решение вашей проблемы:
Зарегистрируйтесь на SecurityTokenValidated событие WSFederationAuthenticationModule, задавать e.Cancel в true и начните свой логический вход с информации, представленной в ClaimsPrincipal свойство события args.
настройка Cancel в true Аргументы события запрещают WIF создавать IPrincipal или сеанс, так что вы можете справиться с этим самостоятельно.
Есть много примеров использования WIF + MVC с разными уровнями контроля. Я бы предложил следующие: http://claimsid.codeplex.com/ или те, которые входят в комплект учебных материалов по идентификации.
WIF в значительной степени позаботится обо всем для вас. Для более глубокого расширения, вы должны проверить книгу Витторио.
Относительно: я просто хочу получить претензии, которые меня интересуют, из POST и сам разбираюсь с настройками.
Что бы вы хотели сделать сами, чего нет в WIF? Какие функции вы бы включили в ваш IPrincipal, который IClaimsPrincipal не предоставляет?
В WIF есть много ручек и рычагов с полным контролем качества зерна. Вероятно, это поможет, если вы поделитесь тем, чем хотите заниматься.