Как клиент может запросить две разные области в зависимости от пользователя? Имеет ли это смысл? Open Id Connect // Identity Server 4 - PullRequest
Новая
       96

Как клиент может запросить две разные области в зависимости от пользователя? Имеет ли это смысл? Open Id Connect // Identity Server 4

0 голосов
/ 08 января 2019

Я пытаюсь полностью понять, что может обеспечить OpenId Connect и как.

Я перечислю сомнения, чтобы вы могли ответить на них по порядку.

A) Контекст: представьте, что существует защищенный ресурс "Phone.Api" со следующими областями действия: "scope.admin", "scope.read" и "scope.write". Мы получаем к нему доступ, используя веб-клиент MVC под названием «phone.Client»

a.1) Представьте, что «Супермастер Билли» и «Стандарт Джин» используют оба клиента. Как мне получить "scope.admin" для Billy и "scope.read" для jean, если они используют один и тот же клиент?

a.2) Должен ли "phone.Client" добавить каждую область в запросе access_token? Потому что, когда я определяю параметры аутентификации в моем клиенте, я должен определить области, которые будут запрашиваться пользователю. 

services.AddOpenIdConnect("oidc", options =>
{
   options.SignInScheme = "Cookies";
   options.Authority = "http://localhost:4000";
   options.RequireHttpsMetadata = false;
   options.ClientId = "phone.client";
   options.ClientSecret = "secret";
   options.ResponseType = "code id_token";
   options.Scope.Add("scope.admin"); //here I should request all scopes?? what happens if I don`t want Jean to have scope.admin ?
   options.Scope.Add("scope.read");
   options.Scope.Add("scope.write");
   options.GetClaimsFromUserInfoEndpoint = true;
   options.SaveTokens = true;
});

Я не понимаю, как мне задать разные области (внутри access_token), используя один и тот же клиент.

a3) Представьте себе клиента, всегда запрашивайте все доступные ему области. Это может быть правильно, так как это то, что клиенту разрешено делать, несмотря на пользовательские разрешения внутри приложения. Это правильно?

B) Open Id connect, когда говорится, что он обеспечивает аутентификацию и авторизацию, о которых идет речь. Какие из моих предположений верны?

b1) Аутентификация пользователя централизованным способом (с использованием централизованного провайдера идентификации)

b2) Пользователи авторизуют Клиентов для доступа к защищенным ресурсам от его имени?

b3) Сервер разрешает клиентам доступ к проектированным ресурсам

Большое спасибо !!

Ответы [ 2 ]

0 голосов
/ 09 января 2019
0 голосов
/ 08 января 2019

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

Например, если вы запрашиваете область действия API, вы запрашиваете у провайдера идентификации доступ к его API от имени пользователя. Когда пользователь входит в систему с поставщиком удостоверений, поставщик удостоверений проверяет области и проверяет, имеет ли пользователь доступ к API.

В большинстве случаев для передачи групп безопасности можно запрашивать группы областей действия. Если эта область предусмотрена, поставщик удостоверений предоставит вам претензии по группам, к которым принадлежит пользователь

Области, предоставляемые поставщиком удостоверений

...