asp.net mvc аутентификация против шибболет и авторизация - PullRequest
0 голосов
/ 21 мая 2009

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

Могу ли я установить некоторые ограничения для действий с использованием атрибута [Authorize] на основе данных, полученных из shibboleth?

Ответы [ 4 ]

2 голосов
/ 09 сентября 2009

Shibboleth публикует пользовательские атрибуты, связанные с сеансы в заголовки HTTP-запроса, основанные на именах заголовков, определенных в политике принятия атрибутов (1.3.x) или сопоставлении атрибутов (2.x) файлы. Эти заголовки преобразуются в переменные CGI на основе на правилах отображения, определенных в спецификации CGI.

Вы должны знать об этой рекомендации по безопасности: http://shibboleth.net/community/advisories/secadv_20090615.txt

0 голосов
/ 25 февраля 2015

Вы захотите создать метод в Global.asax.cs со следующей подписью

protected void Application_PostAuthenticateRequest()
{
    //Your code here.
}

Это будет вызвано автоматически, прежде чем будет выполнено почти что-либо еще (MVC вызовет этот метод, если он существует, вам не нужно «включать его» где-либо), и именно здесь вам нужно установить Принципал. Например, давайте предположим, что у вас есть заголовок с именем RolesHeader, в котором значение ролей разделено запятыми, и другой заголовок с именем UserId, в котором (duh) указан идентификатор пользователя.

Ваш код без обработки ошибок может выглядеть примерно так:

protected void Application_PostAuthenticateRequest()
{
    var rolesheader = Context.Request.Headers["RolesHeader"];
    var userId = Context.Request.Headers["UserId"];
    var roles = rolesheader.Split(',');
    var principal = new GenericPrincipal(new GenericIdentity(userId), roles);
    Context.User = principal;
}

Это Принцип / Удостоверение, которое использует атрибут [Authorize], поэтому его установка здесь в начале жизненного цикла запроса означает, что атрибут [Authorize] будет работать правильно.

Остальное необязательно, но я рекомендую:

Мне нравится создавать свои собственные пользовательские классы, которые реализуют IPrincipal и IIdentity, а не используют GenericPrincipal и GenericIdentity, чтобы в них можно было добавлять больше пользовательской информации. Мои пользовательские объекты «Принципал» и «Идентичность» содержат гораздо более подробную информацию, такую ​​как номера филиалов, адреса электронной почты и т. Д.

Затем я создаю контроллер с именем BaseController, который имеет следующий

protected new CustomPrincipal User
{
    get
    {
        return (base.User as CustomPrincipal) ?? CustomPrincipal.GetUnauthorizedPrincipal();
    }
}

Это позволяет мне получить доступ ко всем моим богатым, пользовательским данным Принципала, а не только к тому, что определено в IPrincipal. Все мои настоящие контроллеры наследуются от BaseController, а не от Controller.

Очевидно, что при использовании подобного Принципала, подобного этому, в методе Application_PostAuthenticateRequest () вы устанавливаете Context.User как CustomPrincipal вместо GenericPrincipal.

0 голосов
/ 12 октября 2009

Куда бы вы прикрепили свой основной принцип? В начале запроса вы говорите, но что, если вы не хотите, чтобы каждый запрос был авторизован?

0 голосов
/ 02 июня 2009

У меня никогда не было пользователя shibboleth, но вы можете получить информацию о пользователе из свойства Controller.User. Он возвратит общий принципал текущего потока. Используя этот принципал, вы можете проверить, прошел ли пользователь аутентификацию, и получить имя пользователя. Это связано с тем, что после входа в систему установлен файл cookie аутентификации, и этот файл cookie содержит ограниченный объем информации. И при каждом запросе после входа в систему проверяется только этот файл cookie (если он существует и действителен - пользователь аутентифицирован).
Поэтому, если вам нужна какая-то конкретная информация, вы можете вручную загрузить пользователя (здесь лучше использовать кеш) и проверить все, что вы хотите.
Также вы можете создать и присоединить своего собственного участника с необходимой информацией к потоку при запуске запроса (например, при запуске запроса загрузить пользователя из db / cache, используя имя пользователя из основного принципала, создать и установить свой собственный участник в поток) , После этого вы можете проверить все свойства нужного вам пользователя.

...