search

jakartaee / rest

Jakarta RESTful Web Services
Other
365 stars 121 forks source link

Deprecating SecurityContext in favor of Jakarta Security #971

Open keilw opened 3 years ago

keilw commented 3 years ago

This has been a painpoint since at least Java EE 8, so I hope if 4.0 aims to deprecate some legacy stuff the redundant SecurityContext may also be taken into consideration?

Jakarta REST since the very first release contained a https://jakarta.ee/specifications/restful-ws/3.0/apidocs/jakarta/ws/rs/core/securitycontext While Jakarta Security with JSR 375 defined a more powerful but essentially identical https://jakarta.ee/specifications/security/2.0/apidocs/jakarta/security/enterprise/securitycontext

Especially the isUserInRole() / isCallerInRole() and get*Principal() methods are precicely identical plus methods like hasAccessToWebResource​() Jakarta Security defines look like a match made in heaven for Jakarta REST.

So why keep them separate?

mkarg commented 3 years ago

Due to its limitations, the REST-variant is much easier to implement. In fact, our application is not using the security context the application server provides, but comes with its own implementation. That code will break and will be hard to fix when we make that move. So while I understand your idea, I just see the drawbacks currently and no benefits.

keilw commented 3 years ago

Wonder what @arjantijms has to say about that? There were calls for a "REST Light" in the Spec Committee already, so it also seems far from lightweight or easy, otherwise why bother to make it lighter? And I'm not saying there should only be a "REST Light" there is an equal need for a "Security Light" otherwise the Core Profile will be insecure. And if that's doable I see no reason to keep this reduncandy forever.

arjantijms commented 3 years ago

Due to its limitations, the REST-variant is much easier to implement

I wonder why that would be the case. Why exactly is the REST variant easier to implement exactly?

mkarg commented 3 years ago

Due to its limitations, the REST-variant is much easier to implement I wonder why that would be the case. Why exactly is the REST variant easier to implement exactly?

Our application implements two filters. One for authentication (we must authenticate against a proprietary solution), one for authorization (we must use a proprietary token system, not compatible with JWT). This was totally easy with REST's SecurityContext. If we switch to Security's SecurityContext, we have to implement more methods and I do not have a clue how to implement them (mostly because I had no time to think over). Maybe it is easy, but at least, it implies spending time into that. So even if its just few hours, it definitively is more work.

keilw commented 3 years ago

Well both are nearly identical, the get*Principal() and is*InRole() are precicely the same just with a slightly different name. The getAuthenticationScheme() method returns what seems mostly one of the predefined constants, I leave it to @arjantijms what problems the Security API and its implementations would have to offer that (otherwise there is still an option to extend the other and deprecate it that's what we did in JSR 385 with UnitFormatService before dropping it in favor of a more universal FormatService after MR1. isSecure() is also specific to REST but I frankly don't see that as a huge problem, again maybe Arjan has another angle to it. getPrincipalsByType​() complements getCallerPrincipal() and may return the exact same value or an empty set under certain conditions.

hasAccessToWebResource​() while it mentions the Servlet spec is fairly neutral and seems to wok well for Jakarta REST with URI resources and methods like PUT, GET, etc.