Identity Server 3 неявное предоставление, авторизация на основе ролей

Question

Я установил Identity Server 3 с базой данных перезагрузки членства в качестве моего сервера авторизации и также разработал проект Web Api, к которому будет обращаться веб-приложение javascript.

Используя неявный поток, клиент может войти в систему и получить id_token и access_token. Теперь у меня есть несколько вопросов, на которые я также хотел бы получить некоторые подробные ответы:

1. Что такое функциональность id_token? Получив его, что я могу с ним сделать?

2. Роли пользователей хранятся в базе данных в виде претензий (например, ключевое значение «role», «admin»). Как выполнить авторизацию на основе ролей на этом этапе? Похоже, что id_token содержит эти утверждения, но access_token этого не делает. При отправке моего access_token в качестве носителя по моему запросу Api, как api знает, какие роли у пользователя-отправителя?

3. В контроллере Web API, я хочу, чтобы получить доступ к информации пользователя с помощью:

   уага пользователя = User как ClaimsPrincipal;

Используя этот код, я ничего не могу получить о пользователе; имя пользователя, идентификатор и т. д. Также, когда я использую в контроллере user.Claims, у меня нет доступа к претензиям, хранящимся в базе данных. Как есть два набора претензий: один в базе данных один в токене ?!

Любая дополнительная информация с благодарностью.

Answer 1

1. id_token следует использовать в клиенте. Вы можете использовать его для доступа к претензиям на стороне клиента. AccessToken должен использоваться в API.

2. К претензиям, которые должны быть включены в access_token, необходимо создать область с соответствующими утверждениями и запросить эту область в запросе. Чтобы создать область (в self-host sample добавить объем в Scopes.cs):

   new Scope 
   { 
         Name = "myApiScope", 
         DisplayName = "IdentityManager", 
         Type = ScopeType.Resource, 
         Emphasize = true, 
         ShowInDiscoveryDocument = false, 
   
         Claims = new List<ScopeClaim> 
         { 
          new ScopeClaim(Constants.ClaimTypes.Name), 
          new ScopeClaim(Constants.ClaimTypes.Role) 
         } 
   } 
   

Ask за рамки в запросе авторизации (В Javascript implicit client - simple это делается следующим образом)

function getToken() { 
     var authorizationUrl = 'https://localhost:44333/core/connect/authorize'; 
     var client_id = 'implicitclient'; 
     var redirect_uri = 'http://localhost:37045/index.html'; 
     var response_type = "token"; 
     var scope = "myApiScope"; 
     var state = Date.now() + "" + Math.random(); 

     localStorage["state"] = state; 

     var url = 
      authorizationUrl + "?" + 
      "client_id=" + encodeURI(client_id) + "&" + 
      "redirect_uri=" + encodeURI(redirect_uri) + "&" + 
      "response_type=" + encodeURI(response_type) + "&" + 
      "scope=" + encodeURI(scope) + "&" + 
      "state=" + encodeURI(state); 
     window.location = url; 
    } 

Это будет включать требования о имени и ролях в ваш токен доступа

3. Настройте свои API с соответствующим промежуточным программным обеспечением при запуске веб-API (в примере SampleAspNetWebApi это делается следующим образом)

   приложение.UseIdentityServerBearerTokenAuthentication (новые IdentityServerBearerTokenAuthenticationOptions { орган = "https://localhost:44333/core", RequiredScopes = новый [] { "myApiScope"} });

Тогда вы можете получить доступ к претензии следующим

  var principal = User as ClaimsPrincipal; 
      return from c in principal.Identities.First().Claims 
        select new 
        { 
         c.Type, 
         c.Value 
        };