On February 22, 2015 at 11:00:32 AM, Brian Demers ([email protected]) wrote: To follow up on this I created a JIRA: https://issues.apache.org/jira/browse/SHIRO-526 and linked it to this thread. Cool, will watch.
BTW this is what I ended up doing: https://github.com/sonatype/nexus-oss/blob/master/components/nexus-security/src/main/java/org/sonatype/nexus/security/authz/AnonymousFilter.java Its not finished yet, but was the simplest solution I could find that seemed to work. Wondering if you can see anything inherently wrong with this and/or if you think Tamas’ much more complex solution (with customized factory, and customized subject impls) has less wrinkles or more merit? I went with the simple 1 class/filter that did the job. And I think if the default Subject had a concept of isAnonymous() then it would work even better, as now if you want to check if the subject is anonymous you must know to check the subject.principal to the configured anonymous user principal (not really a horrible/hard thing). Anyways, if you have a few to peep and let us know if this is good/bad/crazy/excellent I’d appreciate it :-) —jason 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!
