如何扩展OAuth2主体 [英] How to extend OAuth2 principal

问题描述

我们正在开发一个针对两个用例使用OAuth 2的应用程序:

We are developing an application that uses OAuth 2 for two use cases:

1. 访问后端微服务(使用client_credentials)
2. 对应用程序的用户进行身份验证(使用authorization_code，因此将用户重定向到Keycloak进行登录)，其配置大致如

1. Access to backend microservies (using client_credentials)
2. Authenticating the application's users (using authorization_code, so redirecting the users to Keycloak for login, roughly configured like shown in the tutorial).

在对我们的用户进行身份验证时，我们会从身份验证服务器收到一部分信息(例如登录名)，而另一部分则可以在本地用户表中找到.我们想做的是创建一个Principal对象，其中还包含本地数据库中的数据.

While authenticating our users, we receive part of the information from the auth server (such as login) and the other part can be found in a local user table. What we like to do is to create a Principal object containing also the data from the local database.

前进的方式.由于我们必须使用手动OAuth配置来避免干扰OAuth用例1，因此我们对其进行创建和设置:

PrincipalExtractor seems to be the way to go. Since we have to use manual OAuth configuration to not interfere with OAuth use case 1, we create it and set it:

tokenServices.setPrincipalExtractor(ourPrincipalExtractor);

该实现基本上进行数据库查找，并在映射函数中返回CustomUser对象.现在，尽管这似乎可行(调用了提取程序)，但它不能正确持久地保留在会话中.因此，在许多REST资源中，我们正在注入当前用户:

The implementation basically does a DB lookup and returns a CustomUser object in the mapping function. Now although this seems to work (extractor is called), it is not persisted in the session correctly. So in many of our REST resource we are injecting the current user:

someRequestHandler(@AuthenticationPrincipal CustomUser activeUser) {

并在那里接收null.查看注入的Authentication，它表明它是 OAuth2Authentication 对象和默认的Principal对象(我认为它是Spring User/UserDetails).之所以为null，是因为它不是我们之前返回的CustomUser.

and receive null there. Looking into an injected Authentication it shows that it is an OAuth2Authentication object with the default Principal object (I think it is a Spring User / UserDetails). So null because it is not our CustomUser returned before.

我们是否误解了PrincipalExtractor的工作方式?是否可能因为我们在同一个应用程序中有两种不同的OAuth机制(如前所述)而对过滤器链进行了错误配置? Spring的Principal资料库中的一个断点向我们显示，CustomUser保存在此处，然后是原始类型的保存，似乎覆盖了它.

Have we misunderstood the way PrincipalExtractor works? Can it be a misconfiguration of our filter chain because we have two different OAuth mechanisms in the same application as mentioned before? A breakpoint in Spring's Principal repository showed us that CustomUser is saved there, followed by a save with the original type which seems to overwrite it.

推荐答案

好，回答我自己的问题:

Ok, to answer my own question:

1. PrincipalExtractor似乎是自定义主体的常用且标准的方法
2. 在我们的情况下不起作用，因为我们使用的是JHipster应用程序，该应用程序在使用自己的User登录后直接覆盖了主体.因此，PrincipalExtractor中的所有映射都将重置.如果有人有相同的问题:请查看UserService.

1. PrincipalExtractor seems to be the usual and standard way to customize the principal
2. It doesn't work in our case because we are using a JHipster application that simply overwrites the principal right after the login with it's own User. So all mapping in PrincipalExtractor is reset. If anyone has the same question: Look into UserService.

这是使用您可能不知道的详细生成代码的缺点.

That's the downside of using generated code you don't know in detail I guess.

这篇关于如何扩展OAuth2主体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！