What's the value of getCallerName over getCallerPrincipal and have something proprietaty if the standard offers a unified way that supports multiple Authentication mechanisms, not just OpenID Connect?
Indeed, if the reason was to have the very specific OpenID "raw" response available for some reason, then I might make some sense. But a developer only wanting to work with 1 object is maybe not a very good reason. There are many other objects in a typical Jakarta EE application a developer works with.
There seems more value in the getCallerGroups method as at least SecurityContext one of has to query a little more complex,
We actually had a getCallerGroups in the SecurityContext, but Alex argued to remove it at the last second; citing concerns over unlimited lists of groups being returned. This was one of the things I had hoped to address for 3.0, but alas. We can put that on the agenda for the next version.
but e.g. Spring Security does not duplicate things either.
Spring relies a lot on inheritence so the OicdUser is just a subclass of its Principal element but there is no redundant method name there either.
The whole groups Design also looks different via just claims, so the getCallerGroups can be seen as a convenience method.
I highly recommend avoiding redundancies. You can always add things later but it's very hard to remove something from a standard.
Not offering it in 10, well it's been in Spring for over 3 years now, so how long should we wait?
Plus wasn't it in 9 already or did TomEe put something premature into 9?
Interesting, I think TomEE did something wrong there.
This particular version I started with Gaurav in August 2018, so close to 4 years ago. I'd love to have an even wider group of people validate it, but realistically I think that's just not going to happen.
Kind regards,
Arjan Tijms
