Пересчитать претензии для пользователя SharePoint 2010, пока пользователь еще вошел в систему - PullRequest
Новая
       35

Пересчитать претензии для пользователя SharePoint 2010, пока пользователь еще вошел в систему

6 голосов
/ 09 ноября 2011

Я ни в коем случае не эксперт по SharePoint, и мне было очень трудно найти нужную информацию по этому вопросу.Помогите, пожалуйста!

Мне нужен способ вызвать токен утверждения, установленный с помощью вызова SPFederationAuthenticationModule.SetPrincipalAndWriteSessionToken, чтобы пересчитать утверждения на токене без выхода из системы текущего пользователя.Есть какой-либо способ сделать это?

Некоторые сведения о том, почему я спрашиваю это:

Мы используем настраиваемый поставщик ролей и членства для authN / Z в нашем настраиваемом веб-приложении SharePoint 2010.Не вдаваясь в подробности того, почему (которые являются сложными) поставщик ролей создает динамически генерируемые имена ролей для пользователя на основе состояния пользователя в основной базе данных приложения;Эти роли представляют разрешения для пользователя и используются внутри SharePoint для определения доступа пользователя к сайтам и семействам сайтов в приложении.

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

Есть ли какой-нибудь способ программно пересчитать токен сеанса без выхода из системы пользователя?

Или мы лаем неправильное дерево?В моей обычной счастливой стране ASP.NET я бы использовал Forms Auth, которая вычисляет авторизацию при каждом запросе, а не при входе в систему.К сожалению, в SP2010 такой возможности нет, и на данный момент я довольно застрял в SharePoint.Есть ли другие действия, которые мы можем предпринять?

Ответы [ 2 ]

5 голосов
/ 18 ноября 2011

Хорошо, после долгих исследований, вызванных ссылками @ Yahia, я нашел ответ на свои проблемы в сообщении в блоге .Работал как шарм.Я дам краткий обзор ниже, на случай, если ссылка когда-нибудь разорвется:

В Windows Identify Foundation SessionAuthenticationModule, который используется в качестве среды аутентификации SharePoint 2010, есть изящное небольшое событие, которое вы можете перехватить и которое называется SessionSecurityTokenReceived, который вызывается в начале каждого запроса.Подключив это событие, я могу заставить SharePoint запрашивать продление авторизации, не заставляя пользователя повторно вводить учетные данные.

Код прост и приятен: 

var sam = sender as SessionAuthenticationModule;
var logonWindow = SPSecurityTokenServiceManager.Local.LogonTokenCacheExpirationWindow;
var newValidTo = DateTime.UtcNow.Add(logonWindow);
e.SessionToken = sam.CreateSessionSecurityToken(
    e.SessionToken.ClaimsPrincipal,
    e.SessionToken.Context,
    e.SessionToken.ValidFrom,
    newValidTo,
    e.SessionToken.IsPersistent);
e.ReissueCookie = true;

Я проверил его, и подход определенно работает, но есть недостатки:

  1. ВызовCreateSessionToken нужны существующие данные из токена текущего сеанса, которые, как мне кажется, я могу получить только из события.Это означает, что такой подход может быть реализован только в контексте нового запроса.Поскольку событие запускается для каждого запроса, и я хочу обновлять аутентификацию только при определенных обстоятельствах, я вынужден проверять каждый запрос на наличие запроса на обновление аутентификации.Самый простой подход - создать магический URL-адрес, такой как "/ refreshToken? RedirectUrl = {url}", который вы проверяете в обработчике событий.Просто перенаправьте на этот URL, когда аутентификация была обновлена, и токен должен быть обновлен.
  2. Зацепить событие проблематично - вы не можете сделать это статически, потому что модуль не существует, когда создаются статические конструкторы.В конечном счете, лучше всего делать это в пользовательском HttpModule или global.asax - оба требуют обновления ресурсов, которые не могут быть затронуты при развертывании файла .WSP (web.config или global.asax),поэтому любой подход вызывает проблемы развертывания, по крайней мере, для первого развертывания.Я решил пойти по маршруту global.asax.

В общем, удовлетворительный взлом.Получил работу, с минимальным обходным путем.

2 голосов
/ 16 ноября 2011

Я вижу несколько возможностей:

  • попробуйте использовать SPRoleAssignment и SPGroupCollection на соответствующем SPUser для динамического добавления групп / ролей

  • используйте RenewToken с последующим ValidateTokenБудет ли это действительно то, что вам нужно, зависит от того, как реализовано кэширование (т. Е. Обновляет / проверяет, в свою очередь, делает недействительными кэшированные утверждения)

  • , сохраняя пароль в памяти, введитеновый токен (с тем же пользователем / pw, но с новым ID!), затем вызовите ValidateTokenЯ думаю, что это самый простой вариант, НО в то же время кошмар безопасности (т.е. плохая практика)!

  • звоните Authenticate всякий раз, когда вы хотите проверить наличиеЗапросРаботает ли это, зависит от вашего пользовательского провайдера ... если он работает, это будет стоить производительности, хотя ...

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

Другие полезные ресурсы включают в себя:

...