java - com.microsoft.azure.spring.autoconfigure.aad.UserPrincipal を拡張するにはどうすればよいですか?

Question

フロント エンド (PKCE) とazure-active-directory-spring-boot-starterサーバーで MSAL を使用して、ログインしているユーザーとそのクレームを表すエンティティを提供しています。

UserPrincipalよく知られているクレームに簡単にアクセスできるように、Microsoft のクラスをラップするクラスを作成しました。

import com.microsoft.azure.spring.autoconfigure.aad.UserPrincipal;
public class MyCustomUser {
    private UserPrincipal userPrincipal;

    public MyCustomUser(UserPrincipal userPrincipal) {
        this.userPrincipal = userPrincipal;
    }

    public String getEmployeeId() {
        return String.valueOf(this.userPrincipal.getClaim("emplid"));
    }
}

ヘルパークラスを介してこれを利用できるようにします

@Component
public class MyAppSecurityContext {
    public MyCustomUser getUser() {
        UserPrincipal principal = (UserPrincipal) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
        return new MyCustomUser(principal);
    }
}

そして、それを私のサービスレイヤーで使用します:

@Service
public class AnnouncementServiceImpl implements AnnouncementService {

    @Autowired
    private MyAppSecurityContext securityContext;

    @Override
    public List<Announcement> saveAnnouncement(Announcement announcement) {
        MyCustomUser currentUser = this.securityContext.getUser();
        String empid = currentUser.getEmployeeId();

        return this.announcementRepository.saveAnnouncement(empid, announcement);
    }
}

これは機能しますが、気分が悪いです。メンバー オブジェクトの前にファサードを提供するのではなく、 MyCustomUser UserPrincipal を使用して、(独自の を効果的に再実装せずに)カスタムextend型をgetPrincipal()返すことをお勧めします。UserPrincipal問題は、UserPrincipal のコンストラクターが JWT の懸念を想定していることです。これは、これが正しいアプローチではないことを示唆しています。クライアント側のクレームのみに依存する Spring セキュリティ プロジェクトのユーザーをモデル化する別のより適切な方法はありますか?