Comment ajouter des revendications pour obtenir un jeton d'accès de IdentityServer3 à l'aide de ressources propriétaire de flux avec javascript client

J'utilise le propriétaire de la ressource de flux avec IdentityServer3 et envoyer obtenir de demande de jeton à l'identité du serveur jeton d'extrémité avec le nom d'utilisateur et le mot de passe dans le code javascript ci-dessous:

        function getToken() {
        var uid = document.getElementById("username").value;
        var pwd = document.getElementById("password").value;
        var xhr = new XMLHttpRequest();
        xhr.onload = function (e) {
            console.log(xhr.status);
            console.log(xhr.response);
            var response_data = JSON.parse(xhr.response);
            if (xhr.status === 200 && response_data.access_token) {
                getUserInfo(response_data.access_token);
                getValue(response_data.access_token);
            }
        }
        xhr.open("POST", tokenUrl);
        var data = {
            username: uid,
            password: pwd,
            grant_type: "password",
            scope: "openid profile roles",
            client_id: 'client_id'
        };
        var body = "";
        for (var key in data) {
            if (body.length) {
                body += "&";
            }
            body += key + "=";
            body += encodeURIComponent(data[key]);
        }
        xhr.setRequestHeader("Authorization", "Basic " + btoa(client_id + ":" + client_secret));
        xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
        xhr.send(body);
    }

Le jeton d'accès est retourné à partir du serveur de l'identité et de l'authentification de l'utilisateur. Puis-je utiliser ce jeton d'envoyer une requête à mon Api Web.

Le problème est que lorsque je vérifie si l'utilisateur est affecté à un rôle, je trouve que la demande n'existe pas.

    [Authorize]
    //GET api/values
    public IEnumerable<string> Get()
    {
        var id = RequestContext.Principal as ClaimsPrincipal;
        bool geek = id.HasClaim("role", "Geek");  //false here
        bool asset_mgr = id.HasClaim("role", "asset_manager"); //false here
        return new string[] { "value1", "value2" };
    }

Ici est de savoir comment le client est défini dans le serveur d'identité.

new Client 
            {
                ClientName = "Client",
                ClientId = "client_id",
                Flow = Flows.ResourceOwner,
                RequireConsent = false,
                AllowRememberConsent = false,

                AllowedScopes = new List<string>
                {
                    "openid",
                    "profile",
                    "roles",
                    "sampleApi"
                },
                AbsoluteRefreshTokenLifetime = 86400,
                SlidingRefreshTokenLifetime = 43200,
                RefreshTokenUsage = TokenUsage.OneTimeOnly,
                RefreshTokenExpiration = TokenExpiration.Sliding,
                ClientSecrets = new List<Secret>
                {
                    new Secret("4C701024-0770-4794-B93D-52B5EB6487A0".Sha256())
                },
            },

et c'est de cette façon l'utilisateur est défini:

new InMemoryUser
            {
                Username = "bob",
                Password = "secret",
                Subject = "1",

                Claims = new[]
                {
                    new Claim(Constants.ClaimTypes.GivenName, "Bob"),
                    new Claim(Constants.ClaimTypes.FamilyName, "Smith"),
                    new Claim(Constants.ClaimTypes.Role, "Geek"),
                    new Claim(Constants.ClaimTypes.Role, "Foo")
                }
            }

Comment puis-je ajouter des réclamations à l'access_token dans ce cas? Merci beaucoup!

La bonne réponse est ici: stackoverflow.com/questions/34107146/...

OriginalL'auteur Yang Zhang | 2015-11-26

15

Je viens de passer un moment en pensant cela par moi-même. @leastprivilege commentaire de Yang de la réponse qu'avait la moindre idée, cette réponse est juste en expansion.

C'est tout de la façon dont les oAuth et OIDC spécifications évolué, ce n'est pas un artefact de IdentityServer (qui est génial).
Tout d'abord, voici un assez décent à la discussion des différences entre l'identité des jetons et jetons d'accès: https://github.com/IdentityServer/IdentityServer3/issues/2015 qui est intéressant à lire.

Avec des Ressources Propriétaire de flux, comme vous le faites, vous pourrez toujours obtenir un Jeton d'Accès. Par défaut et par la spec, vous ne devriez pas inclure les revendications dans ce jeton (voir le lien ci-dessus pour expliquer pourquoi). Mais, dans la pratique, il est très agréable quand vous le pouvez; il vous permet d'économiser des efforts supplémentaires sur le client et le serveur.

Ce Leastprivilege est allusion, c'est que vous avez besoin pour créer une étendue, quelque chose comme ceci:
```
new Scope
{
    Name = "member",
    DisplayName = "member",
    Type = ScopeType.Resource,

    Claims = new List<ScopeClaim>
        {
              new ScopeClaim("role"),
              new ScopeClaim(Constants.ClaimTypes.Name),
              new ScopeClaim(Constants.ClaimTypes.Email)
        },

    IncludeAllClaimsForUser = true
}
```
Et puis il vous faudra demander à la portée lorsque vous demandez pour le jeton. I. e. votre ligne
scope: "openid profile roles", devrait changer pour scope: "member", (eh bien, je dis que les étendues de jouer un double rôle ici, aussi loin que je peux voir - ils sont aussi une forme de contrôle, à savoir le client demande pour certaines étendues et peut être rejetée si elle n'est pas permis à ceux qui, mais c'est un autre sujet).

De noter l'importance de la ligne qui m'a échappé pendant un certain temps, ce qui est Type = ScopeType.Resource (parce que les Jetons d'Accès sont sur le contrôle d'accès aux ressources). Cela signifie qu'il va s'appliquer à Jetons d'Accès et les allégations indiquées seront inclus dans le jeton (je pense que, éventuellement, contre les spec mais merveilleusement).

Enfin, dans mon exemple, j'ai inclus à la fois des revendications particulières ainsi que IncludeAllClaimsForUser ce qui est évidemment ridicule, mais je voulais juste vous montrer quelques options.

Super réponse! Très clair et très utile. Si ma compréhension est correcte, cela signifie jeton d'accès n'a pas l'intention d'inclure les revendications, et, si l'on veut vérifier les revendications d'utilisateur, une demande distincte serait plus préférable? De cette façon, les revendications peuvent être différents pour chaque utilisateur avec la même portée. Suis-je le droit? Le problème que j'ai voulu résoudre était de fournir des revendications différentes pour les différents utilisateurs.
Dans mon application, je me retrouve avec une solution à ne mettre allégations génériques dans le champ d'application et de laisser le client demande de faire une demande distincte à une api de service pour connaître les capacités (réclamations) de l'utilisateur.
oui, techniquement, les jetons d'accès ne sont pas destinées à contenir des revendications comme les noms, donc, techniquement, vous êtes censé recevoir séparément. C'est juste gênant. Et oui, cette solution permettra de donner à chaque utilisateur de leurs revendications personnelles.
Quelqu'un sait pourquoi cela ne fonctionne pas dans IdentityServer4?

OriginalL'auteur Frans

Je trouve que je peux réaliser cela en remplaçant la valeur par défaut IClaimsProvider de IdentityServerServiceFactory.

La cusomized IClaimsProvider est comme ci-dessous:

public class MyClaimsProvider : DefaultClaimsProvider
{
    public MaccapClaimsProvider(IUserService users) : base(users)
    {
    }

    public override Task<IEnumerable<Claim>> GetAccessTokenClaimsAsync(ClaimsPrincipal subject, Client client, IEnumerable<Scope> scopes, ValidatedRequest request)
    {
        var baseclaims = base.GetAccessTokenClaimsAsync(subject, client, scopes, request);

        var claims = new List<Claim>();
        if (subject.Identity.Name == "bob")
        {
            claims.Add(new Claim("role", "super_user"));
            claims.Add(new Claim("role", "asset_manager"));
        }

        claims.AddRange(baseclaims.Result);

        return Task.FromResult(claims.AsEnumerable());
    }

    public override Task<IEnumerable<Claim>> GetIdentityTokenClaimsAsync(ClaimsPrincipal subject, Client client, IEnumerable<Scope> scopes, bool includeAllIdentityClaims, ValidatedRequest request)
    {
        var rst = base.GetIdentityTokenClaimsAsync(subject, client, scopes, includeAllIdentityClaims, request);
        return rst;
    }
}

Ensuite, remplacez le IClaimsProvider comme ceci:

//custom claims provider
factory.ClaimsProvider = new Registration<IClaimsProvider>(typeof(MyClaimsProvider));

Le résultat est que, lorsque la demande de jeton d'accès est envoyé à jeton d'extrémité les revendications sont ajoutés à l'access_token.

Outre que ce n'est pas la façon de le faire. Créer un champ d'application et de céder les droits que vous avez besoin. Alors demander à la portée. Notre défaut fournisseur de revendications sera alors appeler le service à l'usager pour récupérer les revendications.
Que faire si les revendications sont différentes pour les différents utilisateurs? Si j'associe les revendications de portée, est-ce que les revendications doivent être les mêmes pour tous les utilisateurs?

OriginalL'auteur Yang Zhang

0

Pas seulement que j'ai essayé d'autres méthodes, j'ai essayé toutes les combinaisons possibles des étendues etc. Tout ce que je pouvais lire dans le jeton d'accès a été "portée", "nom de l'étendue", pour des Flux de Ressources il n'y avait pas de revendications, j'ai ajouté de la période.

J'ai eu à faire tout ce
1. Ajouter des UserServiceBase et remplacer AuthenticateLocalAsync depuis que j'ai le nom d'utilisateur/mot de passe et j'ai besoin des deux pour aller chercher les choses à partir de la base de données
2. Ajouter des affirmations que j'ai besoin de la même fonction (ce sur elle-même ne sera pas ajouter de la demande de Jeton d'Accès, en revanche, vous serez en mesure de les lire dans divers ClaimsPrincipal paramètres)
3. Ajouter des DefaultClaimsProvider et remplacer GetAccessTokenClaimsAsync où ClaimsPrincipal objet contient les réclamations j'ai défini précédemment, je viens de me prendre et de les mettre à nouveau dans ølist de demandes pour la suite.
Je suppose que cette dernière étape pourrait être fait primordial GetProfileDataAsync dans la coutume UserServiceBase, mais ce que je viens d'travaillé donc je ne voulait pas déranger.

Le grand problème n'est pas la façon de régler les réclamations, c'est l'endroit où vous de les remplir. Vous devez remplacer quelque chose quelque part.

Ce ici a travaillé pour moi car j'ai besoin des données à partir d'une base de données, quelqu'un d'autre devrait se remplir les revendications ailleurs. Mais ils ne vont pas apparaître comme par magie juste parce que vous avez bien défini les Étendues et les Revendications de l'Identité des configurations de Serveur.

La plupart des réponses ne dis pas un mot sur la où pour définir les valeurs de demande correctement. Dans chaque ignorer que vous avez fait, les paramètres transmis, quand ils ont des revendications, dans la fonction sont attachés à l'identité ou jeton d'accès.

Il suffit de prendre soin de tout cela et tout ira bien.

OriginalL'auteur alex.peter

Vous devez vous connecter pour publier un commentaire.