Обработчики политики авторизации: когда проверять претензии и поиск в базе данных?Когда использовать куки? - PullRequest
Новая
       61

Обработчики политики авторизации: когда проверять претензии и поиск в базе данных?Когда использовать куки?

0 голосов
/ 02 июля 2019

У меня есть Windows MVP-приложение Asp.Net Core для проверки подлинности, в котором в качестве базы данных SQL-сервера используется компонент Identity Management. База данных используется для хранения идентификатора пользователя, а также связывает эту идентификацию с приложениями, ApplicationRoles и ApplicationPermissions. (Аналогично AspNetIdentity, но настроен)

У меня возникают проблемы при попытке выбрать правильный способ реализации моих политик безопасности. На данный момент у меня есть класс требований разрешений и обработчик авторизации требований разрешений. При запуске я просматриваю все разрешения для всего приложения и регистрирую каждое разрешение как политику. Затем я могу использовать атрибут Authorize (Policy = "perm") на моих контроллерах и действиях. Это работает просто отлично. Мне было интересно, если это самый эффективный способ сделать это, и я ищу идеи о том, как сократить вызовы в базу данных.

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

 services.AddAuthorization(options =>
            {

                foreach (var role in IdentityManagementService.GetAllRoles())
                {
                    options.AddPolicy($"Require{role.RoleName}Role",
                        policy => policy
                        .RequireAuthenticatedUser()
                        .Requirements.Add(new RoleRequirement(role.RoleName)));
                }

                foreach (var p in IdentityManagementService.GetAllPermissions())
                {
                    options.AddPolicy(p.PermissionName,
                       policy => policy
                       .RequireAuthenticatedUser()
                       .Requirements.Add(new PermissionRequirement(p.PermissionName)));
                }

            });

Любая помощь / идеи будут оценены. Спасибо.

1 Ответ

0 голосов
/ 02 июля 2019

Во-первых, все является претензией. Даже роли - это просто претензии. Сам принципал - ClaimsPrincipal, что на самом деле означает, что это набор утверждений, принадлежащих конкретному аутентифицированному пользователю.

Во-вторых, все, что существует в качестве претензии, сохраняется в куки-файле auth. Вот почему утверждения являются постоянными: они считываются и восстанавливаются из файла cookie аутентификации, когда они передаются с каждым запросом. Если у вас есть данные, которые хранятся в базе данных, связанной с пользователем, вы, очевидно, должны извлечь их, чтобы прикрепить их в качестве заявки, но это должно быть единовременным случаем, когда пользователь входит в систему. Каждый последующий запрос должен опираться на претензии.

Очевидным недостатком, конечно, является то, что заявки не обновляются, поэтому, если у вас есть данные, которые могут измениться в течение жизни аутентифицированного сеанса пользователя, заявки могут не подходить для данных такого рода. Кроме того, вы можете аннулировать штамп безопасности, что приведет к обновлению файла cookie для аутентификации при следующей повторной проверке (по умолчанию каждые 30 минут). Вы также можете просто выйти из системы, а затем снова войти в нее.

...