Как по-разному аутентифицировать пользователей в стеке службы на основе маршрутов службы?

Я использую сервисный стек. Я хочу аутентифицировать пользователей по-разному в зависимости от маршрута в API. Например: если пользователь получает доступ к маршруту компании: /api/company (POST) (обновление данных компании), я хочу использовать мастер-ключи, хранящиеся в учетной записи суперадминистратора (например). Но если пользователь получает доступ к некоторым тривиальным данным, например, отделам сотрудников, тогда аутентификация этого сотрудника, маршрут: /api/employees/74274762764/departments (GET)

Итак, как мне это сделать, если я использую аутентификацию учетных данных (наследование и внедрение).

Я обнаруживаю пути и пишу логику? Это будет очень ломко. Теоретически я хочу указать атрибут для служб и обеспечить необходимую аутентификацию. Итак, что-то вроде:

[CorporateAuthentication] или [UserAuthentication], чтобы логика аутентификации могла определить, где проверить пользователя.

Пожалуйста помоги.

Спасибо

Амит


authentication api custom-attributes
person Amit Jindal    schedule 03.11.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Вот пример использования вики-страницы аутентификации и авторизации ServiceStack:

[Authenticate]
//All HTTP (GET, POST...) methods need "CanAccess"
[RequiredRole("Admin")]
[RequiredPermission("CanAccess")]
[RequiredPermission(ApplyTo.Put | ApplyTo.Post, "CanAdd")]
[RequiredPermission(ApplyTo.Delete, "AdminRights", "CanDelete")]
public class Secured
{
    public bool Test { get; set; }
}

Этот более ранний ответ StackOverflow подробно описывает, как роли и разрешения работают в ServiceStack.

person mythz    schedule 03.11.2012
comment
Я это уже знаю. Сценарий, который я описываю, предназначен для условий, когда у нас есть обычная аутентификация пользователя для большинства функций, но для сброса пароля пользователя или для некоторых особых вещей нам нужен другой пароль. - person Amit Jindal; 03.11.2012
comment
Разве вы не можете просто предоставить дополнительный пароль/ApiKey/Guid в службах, которым это нужно? - person mythz; 03.11.2012
comment
Что ж, прямо сейчас он подходит к TryAuthenticate как имя пользователя и пароль. Что я делаю, так это то, что если он не проходит аутентификацию пользователя, я проверяю основную аутентификацию. Я бы предпочел не делать этого. - person Amit Jindal; 03.11.2012