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

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

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

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

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

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

    var user = пользователь как ClaimsPrincipal;

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

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

1 ответ

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

  2. Чтобы заявки были включены в access_token, вам нужно создать область с соответствующими заявками и запросить эту область в запросе. Чтобы создать область (в примере самостоятельного размещения добавьте область в 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)
                }
    }
    

Запросите область в вашем запросе авторизации (В неявном клиенте Javascript - просто это делается следующим образом)

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;
    }

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

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

    app.UseIdentityServerBearerTokenAuthentication (new IdentityServerBearerTokenAuthenticationOptions {Authority = " https://localhost:44333/core", RequiredScopes = new [] {"myApiScope"}});

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

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