IdentityServer4实战 - 基于角色的权限控制及Claim详解

一.前言

大家好,许久没有更新博客了,最近从重庆来到了成都,换了个工作环境,前面都比较忙没有什么时间,这次趁着清明假期有时间,又可以分享一些知识给大家。在QQ群里有许多人都问过IdentityServer4怎么用Role(角色)来控制权限呢?还有关于Claim这个是什么呢?下面我带大家一起来揭开它的神秘面纱!

二.Claim详解

我们用过IdentityServer4或者熟悉ASP.NET Core认证的都应该知道有Claim这个东西,Claim我们通过在线翻译有以下解释:

(1)百度翻译

(2)谷歌翻译

这里我理解为声明,我们每个用户都有多个Claim,每个Claim声明了用户的某个信息比如:Role=Admin,UserID=1000等等,这里Role,UserID每个都是用户的Claim,都是表示用户信息的单元 ,我们不妨把它称为用户信息单元

建议阅读杨总的Claim相关的解析 http://www.cnblogs.com/savorboard/p/aspnetcore-identity.html

三.测试环境中添加角色Claim

这里我们使用IdentityServer4的QuickStart中的第二个Demo:ResourceOwnerPassword来进行演示(代码地址放在文末),所以项目的创建配置就不在这里演示了。

这里我们需要自定义IdentityServer4(后文简称id4)的验证逻辑,然后在验证完毕之后,将我们自己需要的Claim加入验证结果。便可以向API资源服务进行传递。id4定义了IResourceOwnerPasswordValidator接口,我们实现这个接口就行了。

Id4为我们提供了非常方便的In-Memory测试支持,那我们在In-Memory测试中是否可以实现自定义添加角色Claim呢,答案当时是可以的。

1.首先我们需要在定义TestUser测试用户时,定义用户Claims属性,意思就是为我们的测试用户添加额外的身份信息单元,这里我们添加角色身份信息单元:

new TestUser
{
    SubjectId = "1",
    Username = "alice",
    Password = "password",
    Claims = new List<Claim>(){new Claim(JwtClaimTypes.Role,"superadmin") }
},
new TestUser
{
    SubjectId = "2",
    Username = "bob",
    Password = "password",
    Claims = new List<Claim>(){new Claim(JwtClaimTypes.Role,"admin") }
}

JwtClaimTypes是一个静态类在IdentityModel程序集下,里面定义了我们的jwt token的一些常用的Claim,JwtClaimTypes.Role是一个常量字符串public const string Role = "role";如果JwtClaimTypes定义的Claim类型没有我们需要的,那我们直接写字符串即可。

2.分别启动 QuickstartIdentityServer、Api、ResourceOwnerClient 查看 运行结果:

可以看见我们定义的API资源通过HttpContext.User.Claims并没有获取到我们为测试用户添加的Role Claim,那是因为我们为API资源做配置。

3.配置API资源需要的Claim

在QuickstartIdentityServer项目下的Config类的GetApiResources做出如下修改:

public static IEnumerable<ApiResource> GetApiResources()
{
    return new List<ApiResource>
    {
//                new ApiResource("api1", "My API")
        new ApiResource("api1", "My API",new List<string>(){JwtClaimTypes.Role})
    };
}

我们添加了一个Role Claim,现在再次运行(需要重新QuickstartIdentityServer方可生效)查看结果。

可以看到,我们的API服务已经成功获取到了Role Claim。

这里有个疑问,为什么需要为APIResource配置Role Claim,我们的API Resource才能获取到呢,我们查看ApiResource的源码:

public ApiResource(string name, string displayName, IEnumerable<string> claimTypes)
{
    if (name.IsMissing()) throw new ArgumentNullException(nameof(name));

    Name = name;
    DisplayName = displayName;

    Scopes.Add(new Scope(name, displayName));

    if (!claimTypes.IsNullOrEmpty())
    {
        foreach (var type in claimTypes)
        {
            UserClaims.Add(type);
        }
    }
}

从上面的代码可以分析出,我们自定义的Claim添加到了一个名为UserClaims的属性中,查看这个属性:

/// <summary>
/// List of accociated user claims that should be included when this resource is requested.
/// </summary>
public ICollection<string> UserClaims { get; set; } = new HashSet<string>();

根据注释我们便知道了原因:请求此资源时应包含的相关用户身份单元信息列表。

四.通过角色控制API访问权限

我们在API项目下的IdentityController做出如下更改

[Route("[controller]")]
    
public class IdentityController : ControllerBase
{
    [Authorize(Roles = "superadmin")]
    [HttpGet]
    public IActionResult Get()
    {
        return new JsonResult(from c in HttpContext.User.Claims select new { c.Type, c.Value });
    }

    [Authorize(Roles = "admin")]
    [Route("{id}")]
    [HttpGet]
    public string Get(int id)
    {
        return id.ToString();
    }
}

我们定义了两个API通过Authorize特性赋予了不同的权限(我们的测试用户只添加了一个角色,通过访问具有不同角色的API来验证是否能通过角色来控制)

我们在ResourceOwnerClient项目下,Program类最后添加如下代码:

response = await client.GetAsync("http://localhost:5001/identity/1");
if (!response.IsSuccessStatusCode)
{
    Console.WriteLine(response.StatusCode);
    Console.WriteLine("没有权限访问 http://localhost:5001/identity/1");
}
else
{
    var content = response.Content.ReadAsStringAsync().Result;
    Console.WriteLine(content);
}

这里我们请求第二个API的代码,正常情况应该会没有权限访问的(我们使用的用户只具有superadmin角色,而第二个API需要admin角色),运行一下:

可以看到提示我们第二个,无权访问,正常。

五.如何使用已有用户数据自定义Claim

我们前面的过程都是使用的TestUser来进行测试的,那么我们正式使用时肯定是使用自己定义的用户(从数据库中获取),这里我们可以实现IResourceOwnerPasswordValidator接口,来定义我们自己的验证逻辑。

/// <summary>
/// 自定义 Resource owner password 验证器
/// </summary>
public class CustomResourceOwnerPasswordValidator: IResourceOwnerPasswordValidator
{
    /// <summary>
    /// 这里为了演示我们还是使用TestUser作为数据源,
    /// 正常使用此处应当传入一个 用户仓储 等可以从
    /// 数据库或其他介质获取我们用户数据的对象
    /// </summary>
    private readonly TestUserStore _users;
    private readonly ISystemClock _clock;

    public CustomResourceOwnerPasswordValidator(TestUserStore users, ISystemClock clock)
    {
        _users = users;
        _clock = clock;
    }

    /// <summary>
    /// 验证
    /// </summary>
    /// <param name="context"></param>
    /// <returns></returns>
    public Task ValidateAsync(ResourceOwnerPasswordValidationContext context)
    {
        //此处使用context.UserName, context.Password 用户名和密码来与数据库的数据做校验
        if (_users.ValidateCredentials(context.UserName, context.Password))
        {
            var user = _users.FindByUsername(context.UserName);

            //验证通过返回结果 
            //subjectId 为用户唯一标识 一般为用户id
            //authenticationMethod 描述自定义授权类型的认证方法 
            //authTime 授权时间
            //claims 需要返回的用户身份信息单元 此处应该根据我们从数据库读取到的用户信息 添加Claims 如果是从数据库中读取角色信息,那么我们应该在此处添加 此处只返回必要的Claim
            context.Result = new GrantValidationResult(
                user.SubjectId ?? throw new ArgumentException("Subject ID not set", nameof(user.SubjectId)),
                OidcConstants.AuthenticationMethods.Password, _clock.UtcNow.UtcDateTime,
                user.Claims);
        }
        else
        {
            //验证失败
            context.Result = new GrantValidationResult(TokenRequestErrors.InvalidGrant, "invalid custom credential");
        }
        return Task.CompletedTask;
    }

在Startup类里配置一下我们自定义的验证器:

实现了IResourceOwnerPasswordValidator还不够,我们还需要实现IProfileService接口,他是专门用来装载我们需要的Claim信息的,比如在token创建期间和请求用户信息终结点是会调用它的GetProfileDataAsync方法来根据请求需要的Claim类型,来为我们装载信息,下面是一个简单实现:

public class CustomProfileService: IProfileService
{
/// <summary>
/// The logger
/// </summary>
protected readonly ILogger Logger;

/// <summary>
/// The users
/// </summary>
protected readonly TestUserStore Users;

/// <summary>
/// Initializes a new instance of the <see cref="TestUserProfileService"/> class.
/// </summary>
/// <param name="users">The users.</param>
/// <param name="logger">The logger.</param>
public CustomProfileService(TestUserStore users, ILogger<TestUserProfileService> logger)
{
    Users = users;
    Logger = logger;
}

/// <summary>
/// 只要有关用户的身份信息单元被请求(例如在令牌创建期间或通过用户信息终点),就会调用此方法
/// </summary>
/// <param name="context">The context.</param>
/// <returns></returns>
public virtual Task GetProfileDataAsync(ProfileDataRequestContext context)
{
    context.LogProfileRequest(Logger);

    //判断是否有请求Claim信息
    if (context.RequestedClaimTypes.Any())
    {
        //根据用户唯一标识查找用户信息
        var user = Users.FindBySubjectId(context.Subject.GetSubjectId());
        if (user != null)
        {
            //调用此方法以后内部会进行过滤,只将用户请求的Claim加入到 context.IssuedClaims 集合中 这样我们的请求方便能正常获取到所需Claim

            context.AddRequestedClaims(user.Claims);
        }
    }

    context.LogIssuedClaims(Logger);

    return Task.CompletedTask;
}

/// <summary>
/// 验证用户是否有效 例如:token创建或者验证
/// </summary>
/// <param name="context">The context.</param>
/// <returns></returns>
public virtual Task IsActiveAsync(IsActiveContext context)
{
    Logger.LogDebug("IsActive called from: {caller}", context.Caller);

    var user = Users.FindBySubjectId(context.Subject.GetSubjectId());
    context.IsActive = user?.IsActive == true;

    return Task.CompletedTask;
}

同样在Startup类里启用我们自定义的ProfileServiceAddProfileService<CustomProfileService>()

值得注意的是如果我们直接将用户的所有Claim加入 context.IssuedClaims集合,那么用户所有的Claim都将会无差别返回给请求方。比如默认情况下请求用户终结点(http://Identityserver4地址/connect/userinfo)只会返回sub(用户唯一标识)信息,如果我们在此处直接 context.IssuedClaims=User.Claims,那么所有Claim都将被返回,而不会根据请求的Claim来进行筛选,这样做虽然省事,但是损失了我们精确控制的能力,所以不推荐。

上述说明配图:

如果直接 context.IssuedClaims=User.Claims,那么返回结果如下:

         /// <summary>
        /// 只要有关用户的身份信息单元被请求(例如在令牌创建期间或通过用户信息终点),就会调用此方法
        /// </summary>
        /// <param name="context">The context.</param>
        /// <returns></returns>
        public virtual Task GetProfileDataAsync(ProfileDataRequestContext context)
        {
            var user = Users.FindBySubjectId(context.Subject.GetSubjectId());
            if (user != null)
                context.IssuedClaims .AddRange(user.Claims);

            return Task.CompletedTask;
        }

用户的所有Claim都将被返回。这样降低了我们控制的能力,我们可以通过下面的方法来实现同样的效果,但却不会丢失控制的能力。

(1).自定义身份资源资源

身份资源的说明:身份资源也是数据,如用户ID,姓名或用户的电子邮件地址。 身份资源具有唯一的名称,您可以为其分配任意身份信息单元(比如姓名、性别、身份证号和有效期等都是身份证的身份信息单元)类型。 这些身份信息单元将被包含在用户的身份标识(Id Token)中。 客户端将使用scope参数来请求访问身份资源。

public static IEnumerable<IdentityResource> GetIdentityResourceResources()
{
    var customProfile = new IdentityResource(
        name: "custom.profile",
        displayName: "Custom profile",
        claimTypes: new[] { "role"});

    return new List<IdentityResource>
    {
        new IdentityResources.OpenId(), 
        new IdentityResources.Profile(),
        customProfile
    };
}

(2).配置Scope 通过上面的代码,我们自定义了一个名为“customProfile“的身份资源,他包含了"role" Claim(可以包含多个Claim),然后我们还需要配置Scope,我们才能访问到:

new Client
{
    ClientId = "ro.client",
    AllowedGrantTypes = GrantTypes.ResourceOwnerPassword,

    ClientSecrets = 
    {
        new Secret("secret".Sha256())
    },
    AllowedScopes = { "api1" ,IdentityServerConstants.StandardScopes.OpenId, 
        IdentityServerConstants.StandardScopes.Profile,"custom.profile"}
}

我们在Client对象的AllowedScopes属性里加入了我们刚刚定义的身份资源,下载访问用户信息终结点将会得到和上面一样的结果。

六.总结

写这篇文章,简单分析了一下相关的源码,如果因为有本文描述不清楚或者不明白的地方建议阅读一下源码,或者加下方QQ群在群内提问。如果我们的根据角色的权限认证没有生效,请检查是否正确获取到了角色的用户信息单元。我们需要接入已有用户体系,只需实现IProfileServiceIResourceOwnerPasswordValidator接口即可,并且在Startup配置Service时不再需要AddTestUsers,因为将使用我们自己的用户信息。

Demo地址:https://github.com/stulzq/IdentityServer4.Samples/tree/master/Practice/01_RoleAndClaim

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CDA数据分析师

工具 | Python Web 开发的十个框架

Python 是一门动态、面向对象语言。其最初就是作为一门面向对象语言设计的,并且在后期又加入了一些更高级的特性。除了语言本身的设计目的之外,Python标准 ...

23610
来自专栏java一日一条

加快Android编译速度的技巧总结

对于Android开发者而言,随着工程不断的壮大,Android项目的编译时间也逐渐变长,即便是有时候添加一行代码也需要等待好久才能看见期待的效果。之前加快An...

563
来自专栏ASP.NET MVC5 后台权限管理系统

已经重写,源码和文章请跳转http://www.cnblogs.com/ymnets/p/5621706.html

文章由于写得比较仓促 已经重写,源码和文章请跳转 http://www.cnblogs.com/ymnets/p/5621706.html  前言: 导入导出实...

2218
来自专栏.NET技术

.net core实践系列之SSO-同域实现

SSO的系列还是以.Net Core作为实践例子与大家分享,SSO在Web方面复杂度分同域与跨域。本篇先分享同域的设计与实现,跨域将在下篇与大家分享。

881
来自专栏ytkah

防止SQL注入的6个要点

922
来自专栏Bug生活2048

.net core下访问控制层的实现

对于一般的程序而言,如果在未登录的情况下理应是没有对应的权限访问对应的页面的,同时,不同的用户也需要验证该用户权限是否满足条件。

642
来自专栏程序员的SOD蜜

常见.NET功能代码汇总

1,在Web上修改指定文件位置的Web.config 这里需要使用 WebConfigurationManager 类,但必须使用WebConfiguratio...

3669
来自专栏菩提树下的杨过

Flash/Flex学习笔记(10):FMS 3.5之Hello World!

Adobe的FMS真的是一个倍儿牛叉的技术!(至少Silverlight在"实时广播"方面目前还没有任何能超越FMS的迹象) 曾经盛极一时的tudou,ku6,...

1738
来自专栏程序小工

windows7使用Sphinx+PHP+MySQL详细介绍

由于业务需要,需要做类似淘宝商城商品检索的功能,对于数据量很大的情况,MySQL 查询的效率损耗很大,需要使用专门的索引引擎进行搜索查询,实现功能,对于和 PH...

1181
来自专栏小樱的经验随笔

【经验分享】后台常用的万能密码

这万能密码好几年前就有了。我都不当回事,结果这次真派上用场了,还真进了后台了 网站后台万能密码就是在用户名与密码处都写入下列字符,如果知道管理员帐号的话直接添...

3385

扫码关注云+社区