I'm using MSAL on the front end (PKCE) and azure-active-directory-spring-boot-starter on the server to provide an entity which represents the logged in user and their claims.
I've built a class which wraps Microsoft's UserPrincipal to provide easy access to well-known claims:
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"));
}
}
I make this available via a helper class
@Component
public class MyAppSecurityContext {
public MyCustomUser getUser() {
UserPrincipal principal = (UserPrincipal) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
return new MyCustomUser(principal);
}
}
and then use it in my service layer:
@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);
}
}
This works, but it feels wrong. I'd prefer to have MyCustomUser extend UserPrincipal and have getPrincipal() return my custom type (without effectively re-implementing my own UserPrincipal) instead of providing a facade in front of a member object. The problem is that UserPrincipal's constructor expects JWT concerns, which suggests that this isn't the correct approach. Is there another, more appropriate way to model the user for a Spring security project which relies on client-side claims only?
