There are a couple of different items in one 1.) using JWTs to hold authentication data. How are you minting the original token? are you getting it from a request header (i.e. bearer token)
Thoughts (possibly unrelated) Shiro probably should support some sort of JWT bearer token out of the box similar to support OAuth IdPs that use JWT for access tokens. (the tricky thing is there is no spec around this so each vendor could be doing something slightly different) 2.) Authorizing vs Authenticating realms While this is possible today it probably isn't as easy or as obvious as it could be. As you mentioned the AuthZ realm extends the AuthC realm. Right now you can probably do this by creating a custom auth strategy + ModularRealmAuthorizor. Maybe adding an AuthZ strategy to the ModularRealmAuthorizor would help here? (and providing default implementations so this could be configured with minimal effort) 3.) JWT Authc realm. I'm really hesitant on making Shiro mint JWTs (except maybe in the case of the RemembeMeManager). As you mentioned there is a lot around JWTs that need to be considered: https://developer.okta.com/blog/2017/08/17/why-jwts-suck-as-session-tokens But if you are talking about OAuth2 Resource Server use cases (where Shiro would be validating an JWT), I do think that should be on the table. You also bring up the point about getting everything out of the authentication token (authz info as well), this is possible today, but again it is less obvious how to do it, and this is NOT an uncommon use case. This is related to another comment about getting at other attributes from a user. Maybe a Shiro Subject/PrincipalCollection should hold a set of attributes? ``` Subject.getAttribute("givenName") == "Brian ``` (something similar could be used when building a set of roles: ``` principalCollection.get("groups") ``` Thoughts? On Mon, Apr 6, 2020 at 2:53 AM Benjamin Marwell <bmarw...@gmail.com> wrote: > I want to throw in JSON web tokens (JWT). > > It is a mess to work with them right now. > > JWT can also be very complicated. They can only hold Authentication data, > or they can hold roles, or even permission (if it is not getting too long). > I settled to create another realm. If the JWT contains EVERYTHING, the > other realms must be skipped (that's the whole point). If it does only > contain authc, there must be a possibility to search either the other > realms or a special authz-only-realm. The latter is not possible atm > because AuthorizingRealms extend AuthenticatingRealm. > > It is not hard to create a JWT Authc realm, though. As the Token class is > different, login will just skip the JWT realm. > > … and there is so much more to it! > > > Am Mo., 6. Apr. 2020 um 07:27 Uhr schrieb Jean-Baptiste Onofre < > j...@nanthrax.net>: > >> Yeah, it seems to be the same indeed. >> >> Regards >> JB >> >> > Le 5 avr. 2020 à 13:38, Francois Papon <francois.pa...@openobject.fr> >> a écrit : >> > >> > I found this one: >> > >> > >> https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming >> > >> > It seems to be the same :) >> > >> > regards, >> > >> > François >> > fpa...@apache.org >> > >> > Le 05/04/2020 à 13:32, Brian Demers a écrit : >> >> This one? >> >> >> >> >> https://github.com/apache/shiro-site/blob/master/version-2-brainstorming.md >> >> >> >> -Brian >> >> >> >>> On Apr 4, 2020, at 8:28 PM, Les Hazlewood <lhazlew...@apache.org> >> wrote: >> >>> >> >>> >> >>> I wrote a whole wiki page on 2.0 design changes, but I can't find it >> now 🤔 >> >>> >> >>>> On Sat, Apr 4, 2020, 5:17 PM Brian Demers <brian.dem...@gmail.com> >> wrote: >> >>>> +1 >> >>>> >> >>>> Off the top of my head we have (I'm sure there is more, but ): >> >>>> >> >>>> * Package name / artifact structure cleanup (breaking change, but >> minor impact) >> >>>> * Remove CAS modules >> >>>> * Replace deprecated code (or move to an implementation/private >> package, for anything still needed) >> >>>> * Support javax.annotation.security annotations (or whatever they >> are now under Eclipse). These annotations work a little different from the >> Shiro ones. >> >>>> * Update to Jakarta dependencies (or figure out a way to work with >> both, abstracting the HTTP logic), bigger lift (or maybe two different >> 'web' packages?) >> >>>> >> >>>> The Jakarta ones have me a little worried though, I think many of >> the current Shiro users would have a hard time making the switch anytime >> soon. Which could kill the adoption of a 2.0. >> >>>> We could (and probably should) abstract the web specifics out in >> order to support the _current_ API, Jakarta EE, and other non-servlet >> stacks (reactive). >> >>>> That said, it's a likely a bunch of work (and again, I'm guessing >> most of the user base would use the current API), so this _could_ be a 3.0 >> item. >> >>>> >> >>>> Thoughts? >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>> On Sat, Apr 4, 2020 at 8:29 AM Francois Papon < >> francois.pa...@openobject.fr> wrote: >> >>>>> Hi, >> >>>>> >> >>>>> I would like to start a thread about the next major release: 2.0.0. >> >>>>> I think we should move forward on it and only fix bug on the 1.x >> branches. >> >>>>> >> >>>>> There is always some issues related to the version in Jira: >> >>>>> >> >>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12315455 >> >>>>> >> >>>>> We can move also the issues list from the 1.6.0 to the 2.0.0: >> >>>>> >> >>>>> https://issues.apache.org/jira/projects/SHIRO/versions/12346916 >> >>>>> >> >>>>> I noticed an existing branch about api changes on github: >> >>>>> >> >>>>> https://github.com/apache/shiro/tree/2.0-api-design-changes >> >>>>> >> >>>>> I propose to update master to 2.0.0-SNAPHOT and create a 1.5.x >> branch (from tag shiro-root-1.5.2) for maintenance. >> >>>>> >> >>>>> Because of some api break, package refactor, deprecated modules or >> components, we also should start a migration guide in the website. >> >>>>> >> >>>>> It's also time for anyone to bring some ideas about the next Shiro >> features/improvements, feel free to share :) >> >>>>> >> >>>>> We could start a formal vote to validate the plan. >> >>>>> >> >>>>> Feedback are welcome! >> >>>>> >> >>>>> regards, >> >>>>> -- >> >>>>> François >> >>>>> fpa...@apache.org >> >>
