+1 for API update. Thanks for the proposal.
Regards JB > Le 10 sept. 2020 à 22:21, Benjamin Marwell <[email protected]> a écrit : > > Hi everyone, > > I would like to adapt shiro to be able to read authentication and > authorization data from JWT tokens. > It is quite easy for authentication. Next to > UsernamePasswordToken.java, we could create an JwtToken.java class, > which holds Jwt Authorization Data (the signature) and Authentication > data (claims). Maybe by pulling in the MicroProfile JWT API [1], or > maybe just an abstraction of it. > > For the authorization, it gets a little more complicated. > At the moment we have this following method in the file AuthorizingRealm.java: > > protected AuthorizationInfo > getAuthorizationInfo(PrincipalCollection principals); > > It takes a PrincipalCollection, because the user can be part of > multiple realms. However, the authorization data is (possibly!) stored > in the JWT, which is not available anymore. However, a simple API > change could make it available. I would like change it to: > > protected AuthorizationInfo > getAuthorizationInfo(PrincipalCollection principals, > AuthenticationToken token); > > Of course, the implementations would still be able to pull even more > authentication data (e.g. additional roles not stored in the JWT) from > a database or other external source. However, currently there is no > non-hacky way to pull in the JwtToken in the AuthorizingRealm.java > class. > > -- > > Parsing of such a token is also necessary. While MP-JWT is just an > API, one implementation must either be shipped or chosen by the user. > Or maybe shipped, and if the user wishes to use another > implementation, it can be excluded and the other dependency will be > pulled in. > > The API is simple [2] and allows easy migration of to those who do not > need inbuilt authentication. > > However, there are still several use cases for JWT in shiro: > * multi-server-readable authentication/authorization using a JWT. This > would make shiro-apps totally stateless without any shared state (e.g. > a shared session cache in a DB or via a memory grid). > * allowing multiple login methods (JWT and other realms, like LDAP) in > combination with the FirstSuccessfulStrategy. > * Using another JWT library, the application could create a single or > multiple JWTs itself after a user LDAP login to replace the cookie and > associated sessions. But better have an external (trusted) service to > issue tokens. > > Please let me know what you think. > > [1] > https://www.eclipse.org/community/eclipse_newsletter/2017/september/article2.php > > [2] https://www.tomitribe.com/blog/microprofile-json-web-token-jwt/ > > Regards, > Ben
