To follow up on this I created a JIRA: https://issues.apache.org/jira/browse/SHIRO-526 and linked it to this thread.
Anyone else have thoughts on guest/anonymous user permission checking ? On Fri, Feb 13, 2015 at 7:36 AM, Tamas Cservenak <[email protected]> wrote: > Hi, > > Let me take another stab on this. Was a bit confused with Guice/Sisu/Karaf > binding in our app, that’s why I gave up on replacing SubjectFactory the > other day, but now I took an experiment with simpler Shiro Examples project > as Brian did. > > So, here is the result: > > https://github.com/cstamas/shiro/compare/cstamas:1.2.x...cstamas:1.2.x-anon-examples > > Is lacking WebSubject support, but is trivial to add it. > > Despite using custom subject implementation, casting it is needed at one > single place: the servlet filter (not on branch, TBD), that would just call > subject.setAnonymous() on enter, and subject.unsetAnonymous() on exit > (preHandle/afterCompletion if using Shiro AdviceFilter as basis). Ordering > of that filter is completely irrelevant (could be first, or could be after > some permissive authc filter), as even if subject set as anonymous, real > logins will still work, and subject will become authenticated. > > - enable/disable anonymous support completely (no need to change anything > in above mentioned servlet filter) > - allows to override session creation for anonymous users > - allows to customise principal used for anonymous, it can be “anonymous”, > “Guest”, “brian” or even “lonestar” ;) > - allows to set “originating realm”, in which case, the anonymous user > authorization will be delegated to that realm, basically “mapping” > anonymous user permission to some existing user in some realm > - allows to explicitly set roles/perms anonymous user has, if not mapped, > TBD. In our case, App does have RolePermissionResolver, but here I did > “hardwire” it just for sake of example. > > The branch above enables anonymous user, and just for fun uses principal > “darkhelmet” and maps anonymous user to “iniRealm” realm. This way, when > anonymous user permissions are evaluated, it actually receives same set of > permissions than darkhelmet has. Also, QuickStart modified by adding logs > where you can see is user anonymous, which principal it uses, and does it > have some needed perm. > > As I am aware of, this solution completely fits into Shiro concepts of > “guest” and rememberMe just fine, and anon user still have > subject.principal == null, and all the filters and annotations should just > work with it. > > I do find this interesting, and have to agree with Jason, that I feel like > Shiro should support this kind of use case. And it would just add new flag > to subject, along to existing: > - isAuthenticated (have principal and authenticated = true) > - isRemembered (have principal and authenticated = false) > - isAnonymous (have anonPrincipal and authenticated = false) > - isGuest (have nothing) > > Have fun! > > -- > Thanks, > ~t~ > > On 13 Feb 2015 at 06:14:15, Jason Dillon ([email protected]) wrote: > > Tamas tossed up this as an example: >> >> >> https://github.com/sonatype/nexus-oss/commit/ad1d703125ec1be1d0eae00492939d60de38a701#diff-c82a898a4ce4094080b2cb98d3567affR38 >> > > That should work, but it seems like a long way to go for something that > _should_ just work. > Another idea to consider, is just setting the default principal to > 'anonymous' via a SubjectFactory > > > https://github.com/bdemers/shiro/compare/bdemers:anonymous-user-roles...anon-take-2#diff-c592bbcd955d97db3e51216509533851R10 > > and then injecting that component: > https://github.com/bdemers/shiro/compare/bdemers:anonymous-user-roles...anon-take-2#diff-0d740ecf6abf4b36742a10db24b7b8c7R28 > > (i'm not sure how this plays with the rememberMe functionality, but adding > just adding this as a thought) > > FTR I had no idea there was a DefaultSubjectFactory. I think however > since that might be global, that a filter in this case may be better, but > have to think about it more now that I realize there is a feature to set > the default subject via factory. > > > Will this work and property get the anonymous subject managed so that >> the rest of Shiros systems behave properly? Tamas had another example >> below it that does a login() but I don't think that is proper, as well as >> its much more expensive as it dives into shiro frameworks, not something we >> want to do on each request w/o authentication. >> >> This branch also has a special realm, but I'm not sure if that is >> actually needed or something like "n/a" for realm-name as you have in your >> example w/o a realm bound to that name is sufficient? >> > > Yeah, the anonymous realm would be a better way to deal with that, that > way you could force this user to the anonymous realm (by making it first in > your realm list) which means you would not need to worry about the odd case > of a person trying to login with the 'anonymous' user and becoming > authenticated. > > Anonymous realm seems to also provide easy way to shut off anonymous, > another requirement/use-case we have. > > > And yes, generally we'd like to be able to have a way to grant >> _guest_ a set of roles/permissions but presently the shiro frameworks only >> can do this if a subject has a principal and a _guest_ is a subject w/o a >> principal. >> > > I'd like to hear other thoughts on this, because I've banged my head on > this before. I feel you should be able to assign roles/permissions to the > _guest_ user, currently the only way to do this is to force a fake > principal into the mix (and then you are no longer really a _guest_) > > Ya, it would be nice if the default delegating impl had some means to > say give me the permissions for _guest_ user. I think we could build that > ourselves, but it seems like something missing from the core framework. > Would be easier if the delegating took the subject instead of the the > subject.principal, and left that detail up to the securitymanager impl. > > > It may not matter however for our case, if you remember, we have to >> be able to allow the _anonymous_ username to be changed for some crazy >> reason, so we can not really use the _guest_ concept at all, but have to >> continue using an _anonymous_ (non-authenticated, non-remembered, >> non-logged-in) user. >> > > Yeah, in your case, that dated back to an old odd requirement (the idea > was to allow the anonymous user's info to be pulled from an external source > i.e. LDAP) > > Yar, we can’t even fully remember the details except for something like > “if you use active-directory the _anonymous_ user is called _guest_. But I > think we are on a path now to make this work in a simpler fashion, removing > the subject.login() should really help. > > I think though that shiro could really do with some proper api around is > subject.Guest() or subject.isAnonymous() (pick one they mean basically the > same thing), vs. assuming subject.principal=null implies this and has no > permissions. Many use-cases I think to want to use the permission system > to allow folks who are anonymous/guest to have access. Certainly we have > these use-cases. Needing to force in a fake non-authenticated user > complicates things, and voids some of the use of @RequireGuest apis. > > ATM if we progress we can’t use Shiro concept of _guest_ at all. And > would have to re-implement @RequiresGuest and @RequiresUser to be aware of > this special subject.principal=<anonymous>. Its do able, and we’ll likely > move forward to to this. But the framework itself IMO should cope with > this edge-case, which isn’t limited to use if you ask google. > > * * * > > FTR, shiro is very simple if you use it as explained in the limited > examples, but as soon as you get off the path, its vastly complex and hard > to comprehend. > > Anyways, we may need more input from you guys and I appreciate the > response with details. If there is anything we can contribute back, of > course, we’ll be more than happy to do so… but I think this specific issues > is a core design limitation to the framework/api that can as-is only be > worked around at present. > > —jason > >
