IT评测·应用市场-qidao123.com

标题: .NET云原生应用实践（四）：基于Keycloak的认证与授权 [打印本页]
作者: 缠丝猫    时间: 2024-10-29 02:37
标题: .NET云原生应用实践（四）：基于Keycloak的认证与授权
本章目标

Keycloak的本地摆设

Keycloak的本地摆设最简单的方式就是使用Docker。可以根据官方文档构建Dockerfile，然后使用Docker Compose直接运行。由于Keycloak也是基础设施的一部分，所以可以直接加到我们在上一讲使用的docker-compose.dev.yaml文件中。同样，在docker文件夹下新建一个keycloak的文件夹，然后新建一个Dockerfile，内容如下：
  1. FROM quay.io/keycloak/keycloak:26.0 AS builder
  3. # Enable health and metrics support
  4. ENV KC_HEALTH_ENABLED=true
  5. ENV KC_METRICS_ENABLED=true
  7. # Configure a database vendor
  8. ENV KC_DB=postgres
  10. WORKDIR /opt/keycloak
  11. # for demonstration purposes only, please make sure to use proper certificates in production instead
  12. RUN keytool -genkeypair -storepass password -storetype PKCS12 -keyalg RSA -keysize 2048 -dname "CN=server" -alias server -ext "SAN:c=DNS:localhost,IP:127.0.0.1" -keystore conf/server.keystore
  13. RUN /opt/keycloak/bin/kc.sh build
  15. FROM quay.io/keycloak/keycloak:26.0
  16. COPY --from=builder /opt/keycloak/ /opt/keycloak/
  18. ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]
复制代码
然后修改docker-compose.dev.yaml文件，加入一个名为stickers-keycloak的新的service：
  1. stickers-keycloak:
  2.   image: daxnet/stickers-keycloak:dev
  3.   build:
  4.     context: ./keycloak
  5.     dockerfile: Dockerfile
  6.   environment:
  7.     - KC_DB=postgres
  8.     - KC_DB_USERNAME=postgres
  9.     - KC_DB_PASSWORD=postgres
  10.     - KC_DB_SCHEMA=public
  11.     - KC_DB_URL=jdbc:postgresql://stickers-pgsql:5432/stickers_keycloak?currentSchema=public
  12.     - KC_HOSTNAME=localhost
  13.     - KC_HOSTNAME_PORT=5600
  14.     - KC_HTTP_ENABLED=true
  15.     - KC_HOSTNAME_STRICT=false
  16.     - KC_HOSTNAME_STRICT_HTTPS=false
  17.     - KC_PROXY=edge
  18.     - KC_BOOTSTRAP_ADMIN_USERNAME=admin
  19.     - KC_BOOTSTRAP_ADMIN_PASSWORD=admin
  20.     - QUARKUS_TRANSACTION_MANAGER_ENABLE_RECOVERY=true
  21.   command: [
  22.       'start',
  23.       '--optimized'
  24.   ]
  25.   depends_on:
  26.     - stickers-pgsql
  27.   ports:
  28.     - "5600:8080"
复制代码
在这些情况变量中，KC_DB指定了Keycloak所使用的数据库类型，我们打算复用上一讲中所使用的PostgreSQL数据库，所以这里填写postgres。KC_DB_USERNAME、KC_DB_PASSWORD、KC_DB_SCHEMA和KC_DB_URL指定了数据库的用户名、密码、schema名称以及数据库连接字符串。KC_HOSTNAME、KC_HOSTNAME_PORT指定了Keycloak运行的主机名和端标语，这个端标语需要跟ports里指定的对外端标语同等。KC_BOOTSTRAP_ADMIN_USERNAME和KC_BOOTSTRAP_ADMIN_PASSWORD指定了Keycloak默认的管理员名称和密码。
在启动Keycloak之前，还需要预备好PostgreSQL数据库，Keycloak启动后会自动连接数据库并创建数据库对象（表、字段、关系等等）。预备数据库也非常简单，继续相沿上一讲介绍的方法，在构建PostgreSQL数据库镜像的时候，将创建数据库的SQL文件复制到镜像中的/docker-entrypoint-initdb.d文件夹中即可。SQL文件包含以下内容：
  1. SET statement_timeout = 0;
  2. SET lock_timeout = 0;
  3. SET idle_in_transaction_session_timeout = 0;
  4. SET client_encoding = 'UTF8';
  5. SET standard_conforming_strings = on;
  6. SELECT pg_catalog.set_config('search_path', '', false);
  7. SET check_function_bodies = false;
  8. SET xmloption = content;
  9. SET client_min_messages = warning;
  10. SET row_security = off;
  12. CREATE DATABASE stickers_keycloak WITH TEMPLATE = template0 ENCODING = 'UTF8' LOCALE_PROVIDER = libc LOCALE = 'en_US.utf8';
  13. ALTER DATABASE stickers_keycloak OWNER TO postgres;
复制代码
然后重新构建并运行PostgreSQL和Keycloak容器：
  1. $ docker compose -f docker-compose.dev.yaml build
  2. $ docker compose -f docker-compose.dev.yaml up
复制代码
猛烈建议在重建和运行容器之前，清除本地的stickers-pgsql:dev镜像，并且删除docker_stickers_postgres_data卷，以确保旧数据不会影响新的摆设。
在成功启动容器之后，打开浏览器访问http://localhost:5600，应该可以打开Keycloak的主页面并用admin/admin进行登录。
在Keycloak中设置Stickers Realm

限于篇幅，这里就不把设置Keycloak的整个过程逐一展示出来了，请移步到我之前写的几篇文章查看具体步调：
请根据上面两篇文章的步调，进行如下的设置：
你可以参考上面列出的两篇文章和这些步调来设置Keycloak，也可以使用本章的代码直接编译Keycloak Docker镜像然后直接运行容器，Keycloak容器运行起来之后，所有的设置都会自动导入，此时就可以使用根据界面上的设置，比对上面的步调进行学习了。
在完成Keycloak端的设置之后，就可以开始修改Stickers.WebApi项目，使我们的API支持认证与授权了。
在Stickers.WebApi中启用认证机制

关于什么是认证，什么是授权，这里就不多作讨论了，网上相关文章很多，也可以通过ChatGPT获得具体的表明和介绍。我们首先实现一个目标，就是只允许注册用户可以访问Stickers微服务，而不管这些用户是不是真的具有访问此中的某些API的权限。我这里用粗体字强调了“注册用户”和“权限”两个概念，也就可以区分出什么是认证，什么是授权了，通俗地说：认证就是该用户是否被允许使用网站的服务，授权就是在允许使用网站服务的前提下，该用户是否可以对此中的某些功能进行操纵。
在ASP.NET Core中，集成认证与授权机制是非常容易的，首先，向Stickers.WebApi项目添加Microsoft.AspNetCore.Authentication.JwtBearer NuGet包，然后在Program.cs中，加入如下代码：
  1. builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
  2.     .AddJwtBearer(options =>
  3. {
  4.     options.Authority = "http://localhost:5600/realms/stickers";
  5.     options.RequireHttpsMetadata = false;
  6.     options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
  7.     {
  8.         NameClaimType = "preferred_username",
  9.         RoleClaimType = ClaimTypes.Role,
  10.         ValidateIssuer = true,
  11.         ValidateAudience = false
  12.     };
  13. });
复制代码
上面的代码用来初始化ASP.NET Core的认证机制，我们使用Jwt Bearer Token的认证模块，在设置中，指定认证机构Authority为stickers Realm的Base URL，然后对token的认证进行参数设置。这里的NameClaimType指定了在解析access token的时候，应该将哪个Claim看成是用户名称，同理，RoleClaimType指定了应该将哪个Claim看成是用户角色。在启动了PostgreSQL和Keycloak容器之后，可以使用类似下面的cURL下令获得access token：
  1. $ curl --location 'http://localhost:5600/realms/stickers/protocol/openid-connect/token' \
  2. --header 'Content-Type: application/x-www-form-urlencoded' \
  3. --data-urlencode 'grant_type=password' \
  4. --data-urlencode 'client_id=public' \
  5. --data-urlencode 'client_secret=B2REunrXWN57KtQoJWoP2Dhr7gqKJrol' \
  6. --data-urlencode 'username=daxnet' \
  7. --data-urlencode 'password=daxnet'
复制代码
然后打开jwt.io，将这个access token复制到Debugger的Encoded部分，在Decoded部分可以看到，用户名是在preferred_username字段指定的，这就是NameClaimType指定为preferred_username的原因：

当然，还需要在Program.cs文件中加入Authentication和Authorization的Middleware：
  1. app.UseAuthentication();
  2. app.UseAuthorization();
复制代码
并在StickersController上启用Authorize特性：
  1. [ApiController]
  2. [Authorize]
  3. [Route("[controller]")]
  4. public class StickersController(ISimplifiedDataAccessor dac) : ControllerBase
  5. {
  6.     // ...
  7. }
复制代码
此时如果启动Stickers API，然后使用cURL获取所有的“贴纸”，则会返回401 Unauthorized：
  1. $ curl --location 'http://localhost:5141/stickers?asc=true&size=20&page=0' -v
  2. * Host localhost:5141 was resolved.
  3. * IPv6: ::1
  4. * IPv4: 127.0.0.1
  5. *   Trying [::1]:5141...
  6. * Connected to localhost (::1) port 5141
  7. > GET /stickers?asc=true&size=20&page=0 HTTP/1.1
  8. > Host: localhost:5141
  9. > User-Agent: curl/8.5.0
  10. > Accept: */*
  11. >
  12. < HTTP/1.1 401 Unauthorized
  13. < Content-Length: 0
  14. < Date: Sat, 26 Oct 2024 13:05:21 GMT
  15. < Server: Kestrel
  16. < WWW-Authenticate: Bearer
  17. <
  18. * Connection #0 to host localhost left intact
复制代码
但如果将刚刚获得的access token加到cURL下令中，就可以正常访问API了（access token太长，这里先把它截断了）：
  1. $ curl --location 'http://localhost:5141/stickers?asc=true&size=20&page=0' \
  2.        --header 'Authorization: Bearer eyJh...' -v
  3. * Host localhost:5141 was resolved.
  4. * IPv6: ::1
  5. * IPv4: 127.0.0.1
  6. *   Trying [::1]:5141...
  7. * Connected to localhost (::1) port 5141
  8. > GET /stickers?asc=true&size=20&page=0 HTTP/1.1
  9. > Host: localhost:5141
  10. > User-Agent: curl/8.5.0
  11. > Accept: */*
  12. > Authorization: Bearer eyJh...
  13. >
  14. < HTTP/1.1 200 OK
  15. < Content-Type: application/json; charset=utf-8
  16. < Date: Sat, 26 Oct 2024 13:08:06 GMT
  17. < Server: Kestrel
  18. < Transfer-Encoding: chunked
  19. <
  20. * Connection #0 to host localhost left intact
  21. {"items":[],"pageIndex":0,"pageSize":20,"totalCount":0,"totalPages":0}
复制代码
 在Stickers.WebApi中启用授权机制

在我之前写的《ASP.NET Core Web API下基于Keycloak的多租户用户授权的实现》一文中，已经具体介绍了如何基于Keycloak完成授权，在Stickers案例中，我会采取雷同的实现方式，因此这里就不再赘述具体的实现过程了，仅介绍Stickers微服务所特有的部分。
上面我们已经在Keycloak中设置了授权，这里大抵总结一下与授权相关的设置。首先，我们定义了四个scope，分别是：admin.manage_users、stickers.read、stickers.update以及stickers.delete。所谓的scope，实在就是对资源的操纵类型；然后，我们定义了两种资源：admin-api和stickers-api，分别表示两组不同的API：admin-api表示与站点管理相关的API（虽然临时我们还没有实现管理API），而stickers-api则表示与“贴纸”相关的API（也就是StickersController所提供的API）；接下来，我们又定义了两个Policy：require-admin-policy和require-registered-user-policy，分别表示“干某件事需要管理员角色”和“干某件事需要注册用户角色”。可以看到，实在基于角色的授权，在Keycloak的整个授权体系中，只是此中的一种特例，Keycloak所支持的Policy类型，并不但只有基于角色这一种计谋；最后，定义了四个Permission：admin-manage-users-permission、stickers-delete-permission、stickers-update-permission和stickers-view-permission，这些permission都关联了对应的计谋（这里都是基于角色的计谋）和对资源的操纵类型scope，而这些操纵类型又进一步被资源所引用。所以，总的来说，Permission就定义了符合某种计谋（Policy）的访问者对某种资源（Resource）具有完成何种操纵类型（Scope）的权限。
仔细思考你会发现，我们实在根本不关心当前登任命户是什么角色，我们只关心该用户的某些特质是否到达访问某种资源并完成相应操纵的需求，角色只不过是这些特质中的一种。所以，一方面在API上，我们定义该API是什么资源，它支持什么操纵，而另一方面，当认证用户访问该API时，我们从用户的Claims中读取该用户在该资源上所能完成的操纵名称，两者进行比对即可，而至于认证用户是否满意访问该资源并完成该操纵的需求，在Keycloak的授权模块中就已经完成计算了，Keycloak只是在发送的token中带上计算结果就可以了。
下图展示了在Keycloak中，针对daxnet这个用户所进行的权限评估，从评估结果可以看到，该用户在stickers-api资源上的stickers.read、stickers.update以及stickers.delete操纵是具有权限的；而在admin-api资源上的admin.manage_users上是没有权限的。所以，我们只需要在Stickers.WebApi上实现这个判断就可以了。

完成这个判断逻辑，大抵会需要两个步调：首先，使用access token，通过将grant_type设置成urn:ietf:paramsauth:grant-type:uma-ticket并再次调用/realms/stickers/protocol/openid-connect/token接口，以获得包含授权信息的user claims，然后，在API被访问时，根据该API所支持的操纵列表，从带有授权信息的user claims中查找，看是否API所支持的操纵在user claims中能被找到，如果能找到，就说明该用户可以访问API，否则就返回403 Forbidden。
完整代码这里就不具体介绍了，还是猛烈建议移步阅读《ASP.NET Core Web API下基于Keycloak的多租户用户授权的实现》这篇博文，并配套本章节的源代码以了解细节。
这里还是涉及到user claims缓存的题目，由于在获取用户授权信息的时候，存在两次Keycloak的调用，这样做并特别高效，后续会考虑引入缓存机制来解决这个题目。
在完成代码的实现之后，就可以进行测试了，使用daxnet用户获取access token：
  1. $ curl --location 'http://localhost:5600/realms/stickers/protocol/openid-connect/token' \
  2. --header 'Content-Type: application/x-www-form-urlencoded' \
  3. --data-urlencode 'grant_type=password' \
  4. --data-urlencode 'client_id=public' \
  5. --data-urlencode 'client_secret=B2REunrXWN57KtQoJWoP2Dhr7gqKJrol' \
  6. --data-urlencode 'username=daxnet' \
  7. --data-urlencode 'password=daxnet'
复制代码
然后使用这个access token来访问GET /stickers API，可以看到，能够成功返回结果：
  1. $ curl --location 'http://localhost:5141/stickers' \
  2.      --header 'Authorization: Bearer eyJhbGci......' \
  3.      -v && echo
  4. * Host localhost:5141 was resolved.
  5. * IPv6: ::1
  6. * IPv4: 127.0.0.1
  7. *   Trying [::1]:5141...
  8. * Connected to localhost (::1) port 5141
  9. > GET /stickers HTTP/1.1
  10. > Host: localhost:5141
  11. > User-Agent: curl/8.5.0
  12. > Accept: */*
  13. > Authorization: Bearer eyJhbGci......
  14. >
  15. < HTTP/1.1 200 OK
  16. < Content-Type: application/json; charset=utf-8
  17. < Date: Mon, 28 Oct 2024 13:15:58 GMT
  18. < Server: Kestrel
  19. < Transfer-Encoding: chunked
  20. <
  21. * Connection #0 to host localhost left intact
  22. {"items":[],"pageIndex":0,"pageSize":20,"totalCount":0,"totalPages":0}
复制代码
重新使用nobody用户获取access token：
  1. $ curl --location 'http://localhost:5600/realms/stickers/protocol/openid-connect/token' \
  2. --header 'Content-Type: application/x-www-form-urlencoded' \
  3. --data-urlencode 'grant_type=password' \
  4. --data-urlencode 'client_id=public' \
  5. --data-urlencode 'client_secret=B2REunrXWN57KtQoJWoP2Dhr7gqKJrol' \
  6. --data-urlencode 'username=nobody' \
  7. --data-urlencode 'password=nobody'
复制代码
然后使用这个access token来访问GET /stickers API，可以看到，API返回403 Forbidden：
  1. $ curl --location 'http://localhost:5141/stickers' \
  2.        --header 'Authorization: Bearer eyJhbGci......' -v && echo
  3. * Host localhost:5141 was resolved.
  4. * IPv6: ::1
  5. * IPv4: 127.0.0.1
  6. *   Trying [::1]:5141...
  7. * Connected to localhost (::1) port 5141
  8. > GET /stickers HTTP/1.1
  9. > Host: localhost:5141
  10. > User-Agent: curl/8.5.0
  11. > Accept: */*
  12. > Authorization: Bearer eyJhbGci......
  13. >
  14. < HTTP/1.1 403 Forbidden
  15. < Content-Length: 0
  16. < Date: Mon, 28 Oct 2024 13:18:31 GMT
  17. < Server: Kestrel
  18. <
  19. * Connection #0 to host localhost left intact
复制代码
总结

本文简单介绍了在Stickers.WebApi上基于Keycloak实现认证与授权的步调，由于一些原理性的内容和具体实现细节在之前我的博文中都有具体介绍，所以这里也就不再重复了，建议可以结合这些文章来阅读本章代码，相信会有不少的收获。下一章会基于.NET Web Assembly实现前端，并在开辟情况中调通整个前后端流程。
源代码

本章源代码在chapter_4这个分支中：https://gitee.com/daxnet/stickers/tree/chapter_4/
下载源代码前，请先删除已有的stickers-pgsql:dev和stickers-keycloak:dev两个容器镜像，并删除docker_stickers_postgres_data数据卷。
下载源代码后，进入docker目录，然后编译并启动容器：
  1. $ docker compose -f docker-compose.dev.yaml build
  2. $ docker compose -f docker-compose.dev.yaml up
复制代码
现在就可以直接用Visual Studio 2022大概JetBrains Rider打开stickers.sln解决方案文件，并启动Stickers.WebApi进行调试运行了。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/) Powered by Discuz! X3.4