shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Demers <brian.dem...@gmail.com>
Subject Re: Can anonymous user have permissions?
Date Sun, 22 Feb 2015 18:59:17 GMT
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 <tamas@cservenak.net>
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 (jason.dillon@gmail.com) 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
>
>

Mime
View raw message