Keycloak是一个功能强大的开源身份和访问管理系统，提供了一整套解决方案，包括用户认证、单点登录（SSO）、身份联合、用户注册、用户管理、角色映射、多因素认证和访问控制等。它广泛应用于企业和云服务，可以简化和统一不同应用程序和服务的安全管理，支持自托管或云部署，适用于需要安全、灵活且易于扩展的用户身份管理和访问控制的场景。
SaaS（Software as a Service，软件即服务）是一种软件分发模式，其中软件应用程序通过互联网托管并由服务提供商管理。用户通常通过订阅模式访问这些服务，而不是购买和安装软件。SaaS应用程序通常部署在云环境中，只要用户有互联网连接，他们就可以随时随地访问服务。在SaaS应用中，多租户支持是关键需求之一。在多租户环境中，一个服务实例需要为多个租户（即不同的公司、组织或个人用户）提供服务，同时保障数据隔离和安全性。因此，多租户的支持也成为了与SaaS应用集成的身份和访问管理（IAM）服务的基本需求，在选用Keycloak作为SaaS应用IAM服务的场景下，对于多租户模式的支持，也是Keycloak实施的一个关键需求。
Keycloak中的基本概念及其之间的关系要理解Keycloak对于多租户的支持方式，首先需要了解Keycloak中的一些基本概念以及它们之间的关系。当然，本文不会详细解释这些概念是什么，Keycloak的官方文档里有详细的解释，了解这部分内容将有助于选择以何种方式实现多租户。
下图简要描述了Keycloak中的一些主要的基本概念及其之间的关系：
在一个Keycloak的部署中包含多个Realm，Realm是一个管理的域，它作为顶层组织单元，用来封装和管理一组用户、角色、群组和客户端（即应用程序或服务）。每个Realm可以有自己的一套用户目录、身份验证和授权规则、客户端配置以及其他安全性设置，不同的Realm之间是相互隔离的。在一个Realm中，可以创建多个Client，Client是一个非常重要的概念，它代表了可以请求Keycloak进行认证和授权的实体。在OAuth 2.0和OpenID Connect（OIDC）的上下文中，客户端通常指的是一个应用程序，它希望使用Keycloak作为身份提供者来验证用户的身份，并可能获取用户授权的令牌，以便访问受保护的资源。在不同的Client下，可以创建互相隔离的一组Client Role，也就是Client下的角色，一个角色可以关联到多个用户（user）或者用户组（group）上。与此同时，Client下还可以有一组Client Scope，而Client Scope还可以映射到某个或者某些用户信息属性（user profile attribute）上，而用户信息属性（user profile attribute）则可以是定义在用户（user）上的自定义属性。
Keycloak中多租户的不同模式从上面的结构可以分析得出，Keycloak对多租户的支持主要有两种模式：
每个租户（tenant）使用独立的Realm，即Realm per tenant模式所有租户共享同一个Realm，但使用不同的Client，即Single Realm模式需要根据不同需求来选择不同的模式。
Realm per Tenant这种模式的实现比较简单清晰：数据严格隔离，简单地按照上图中的关系对Realm进行配置就行了，比如，在Realm下可以直接创建用户组，这些用户组就是属于当前这个租户的；但另一方面，由于不同的Realm拥有完全不同的一套用户（user）和用户组（group）数据，于是，Realm per Tenant无法实现某个用户同时属于多个租户的场景。你可以在不同的租户中创建名字和电子邮件地址完全相同的用户，但是，它们虽然名字相同，却是完全不同的两个实体。除此之外，当租户数量越来越大时，Realm的个数也会相应增加，对于Keycloak来说也存在一定的性能影响（我没有实际测试过，但是根据目前来自各方面的文档资料，Keycloak维护上百个Realm还是没有太大问题的）。
Single Realm在Single Realm模式下，每个租户就是一个Client，好处是用户及用户组可以属于多个租户，比如：A用户可以同时属于T1和T2两个租户，也不必考虑Realm太多影响性能。每个Client都可以配置不同的登录选项，因此，可以满足多租户的需求。但实现这种模式相对比较复杂，而且有些信息比如用户的角色、所属的用户组等会全部出现在用户的access token里，而这些信息有些是属于特定租户的，其数据隔离性没有Realm per Tenant模式好。
使用Single Realm实现多租户的一般思路是，针对每一个租户创建一个Client，所以在这个Realm下，用户是跨租户的，用户组理论上也是跨租户的，但是，可以对不同的租户，设置不同的用户组，然后在这个租户级别的用户组下，还可以创建子组，所以，用户组也可以做到按租户隔离。对于角色而言，Client下本身就可以分配不同的角色，所要做的就是将用户/用户组分配到不同的角色上，只不过选择角色的时候需要指定，是分配到哪个Client下的哪个角色。
演练：在Keycloak中配置Single Realm多租户模式注意：本文演练部分基于Keycloak 24.0.2，对于其它版本的Keycloak，界面操作可能会有出入。
创建一个新的Realm启动Keycloak本地开发环境，推荐使用docker，可以参考这篇文章。启动成功后，用admin/admin登录管理界面，点击界面左边的Keycloak下拉框，然后点击Create realm按钮，以创建一个新的Realm。
在Create realm界面，只需要输入Realm name即可，例如：multitenant，然后点击Create按钮，系统提示Realm created successfully，表示Realm创建成功。
创建对应于租户的Client接下来，在侧边栏中点击Clients链接，打开Clients列表界面，在界面中，点击Create client，注意：这里我们就是为某个租户创建一个Client，因此，可以考虑用租户的名称来命名这个Client，假设我们客户的名字叫Globex Corporation，于是，Client就命名为globex。在Create client界面中，Client ID填globex，然后点击Next按钮：
在Capability config下，启用Client authentication，Authorization也可以考虑启用，在Authentication flow中，暂时先勾选Direct access grants，以便后面的测试。在OIDC的Authorization Code Flow和Authorization Code Flow /w PKCE两种flow下，该选项可以关闭，当然，具体的可以根据项目实际情况选择。这部分的配置如下：
点击Next按钮，在Login settings页面，可以无需修改配置，直接点击Save按钮，此时Client创建成功。
配置Client scopes在左侧侧边栏，点击Client scopes，然后点击Create client scope按钮，在Create client scope页面中，输入Client scope名称，其它的默认就行，然后点击Save按钮：
在新创建的Client scope下，点击Mappers标签页，然后点击Configure a new mapper按钮：
在Configure a new mapper列表中，找到Group Membership，直接点击选中，然后在Add mapper页面下，输入Mapper的名字，然后Token Claim Name也指定一下，其它的开关按钮保持默认就行。这里注意的是，Token Claim Name并不是必须的，但是如果你希望它出现在用户的access token中，那么这个是必填的：
完成配置后点击Save按钮保存配置。然后回到Clients列表，点击刚刚新建的Client：globex，进入Client scopes标签页，单击Add client scope按钮：
在弹出的Add client scopes to globex对话框中，选择刚刚新建的Client scope，然后点击Add -> Default按钮：
配置用户（user）和用户组（group）注意：此处配置的用户和用户组是跨多租户，也就是跨多个Client的，之后会在Client的Role下通过角色关联来将用户关联到租户上。
在左边侧边栏点击Users链接，在Users界面中，点击Create new user按钮，然后在General部分输入Username，其它信息可以按需填写，然后点击Create按钮：
在用户详细信息页面中，点击Credentials选项卡，然后点击Set password按钮：
在弹出的对话框中，输入密码，然后关闭Temporary选项，再点击Save按钮，在确认对话框中，点击红色的Save password按钮即可：
在左侧侧边栏点击Groups链接，然后点击Create group按钮，在弹出的Create a group对话框中，输入组名。由于我们希望不同租户具有不同的组配置策略，也就是租户的用户组也需要隔离，因此，在这里组名就使用租户的名称，也就是globex。然后点击Create按钮创建组。在成功创建组之后，点击Members选项卡，然后点击Add member按钮，在弹出的Add member对话框中，将刚刚新建的super用户添加到globex组中。
一个对应于租户的组（比如这里的globex组）下还可以创建多个子用户组，也就可以定义针对不同租户的用户组层次结构。
配置用户/用户组角色点击左边侧边栏的Clients链接，在Clients列表中，点击globex Client，在Roles选项卡下，点击Create role按钮，新建一个角色，比如administrator，然后点击Save按钮：
回到Users或者Groups界面，选择某个用户或者用户组，比如选择刚刚新建的super用户，在用户的Role mapping选项卡下，点击Assign role按钮：
在Assign roles to super对话框中，点击Filter by realm roles下拉框，选择Filter by clients，然后选择globex这个Client的administrator角色，表示需要将globex租户的administrator角色分配给super用户：
测试我们的配置点击左侧侧边栏的Clients链接，然后选择globex Client，进入Credentials选项卡，在Client Secret部分点击复制按钮，将Client Secret复制到剪贴板中，然后打开Postman，使用下面的HTTP请求：
POST URL为http://<server>:<port>/realms/<realm>/protocol/openid-connect/tokengrant_type：passwordclient_id：租户的名称，globexclient_secret：上一步复制到剪贴板的内容password：用户密码username：用户名称点击Send按钮后，即可得到access token。打开https://jwt.io，将access token复制到Debugger的Encoded部分，即可解出access token的明文：
详细内容类似如下：
{"exp": 1712410272,
"iat": 1712409972,
"jti": "8f18192e-c223-4f60-a23d-6e825f5e6b37",
"iss": "http://localhost:5600/realms/multitenant",
"aud": "account",
"sub": "1a666edc-36c2-4704-ac14-2a8d88332781",
"typ": "Bearer",
"azp": "globex",
"session_state": "448c536c-3f11-4275-b03c-78bec00deb56",
"acr": "1",
"allowed-origins": [
"/*"
],
"realm_access": {
"roles": [
"offline_access",
"uma_authorization",
"default-roles-multitenant"
]
},
"resource_access": {
"globex": {
"roles": [
"administrator"
]
},
"account": {
"roles": [
"manage-account",
"manage-account-links",
"view-profile"
]
}
},
"scope": "email profile",
"sid": "448c536c-3f11-4275-b03c-78bec00deb56",
"email_verified": false,
"name": "Super Admin",
"groups": [
"/globex"
],
"preferred_username": "super",
"given_name": "Super",
"family_name": "Admin",
"email": "super@globex.com"
}
可以看到：
azp代表了当前请求access token的租户名称resource_access下列出了该用户所属的租户名称，以及在每个租户下所属的角色groups下列出了该用户所属的用户组，很遗憾，这里它会将所有该用户所属的用户组列出来，比如，如果还存在另一个租户soylent，那么，这个groups数组里就会出现/soylent这个项目。在实际项目中，可以在Action Filter中，通过代码来处理这个信息与ASP.NET Core Web API的集成此时可以新建一个ASP.NET Core Web API应用程序，集成Keycloak身份认证，来查看在User Principle上可以拿到哪些数据。修改Program.cs文件，加入这些代码：
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(options =>
{
options.Authority = "http://localhost:5600/realms/multitenant";
options.MetadataAddress =
"http://localhost:5600/realms/multitenant/.well-known/openid-configuration";
options.RequireHttpsMetadata = false;
options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
{
NameClaimType = "preferred_username",
RoleClaimType = ClaimTypes.Role,
ValidateIssuer = true,
ValidateAudience = false
};
});
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
然后，在Controller上加入[Authorize]特性：
[ApiController][Authorize]
[Route("[controller]")]
public WeatherForecastController : ControllerBase
{
// 省略N行
}
在某个Controller Action方法上设置一个调试断点，然后启动ASP.NET Core Web API应用程序。接下来，在Postman中调用这个设置了调试断点的API服务，记得Authorization选择Bearer Token，然后将上面通过Postman获得的access_token作为Bearer Token填入，发起请求。此时，Visual Studio中断点会被命中，查看User对象，可以看到，有关租户的一些信息已经在User的Claims下：
之后，只需利用这些信息来实现用户授权即可。
