Sorry for the slow response. I think we can clear this up quickly though. The intent of the 'permissive' flag is to provide users with an authentication mechanism while not requiring authentication. The flag does indeed ignore the authc check - this is essentially delegated to another section of the application. Maybe if I illustrate a particular use case for this, it will make it more clear. I have a server application that uses http basic auth and has a pluggable "module" system. The modules are dynamically loaded at runtime, each to their own URL. Each of these modules defines its own security requirements via an AOP annotation. For some, this means requiring a specific permission. But others are intended to be open to anyone - even someone not logged in. Since modifying the shiro filter mapping to only point the authcBasic filter at certain modules would severely limit the flexibility of the module mechanism, the permissive flag makes this possible. Basically, with permissive set, the filter will log in any user who provides login info. All users will be forwarded to the application. Then, when the AOP authorization needs to do a permission check, it does it. If the user is not logged in, this permission check will throw an UnauthenticatedException. The filter (authc or authcBasic) will catch this exception and then notify the user of the required authentication (redirect to login page or 401 response, respectively). Basically, this allows the user to truly separate the authentication mechanism from the decision of whether or not to require users to be authenticated.
Now, all that being said, after some thinking I'm not convinced that the permissive flag is the right way to go about this. I suspect that this functionality could be much better provided with SHIRO-224 (which should probably also resolve SHIRO-321). I had hoped that this could solve SHIRO-283, but it's really only a partial fix. Again, SHIRO-224 could likely open up simple avenues to solve SHIRO-283. So all that being said, I suggest that we remove this functionality for 1.2 and talk about the use cases more with SHIRO-224. Thanks, Jared On Mon, Sep 19, 2011 at 8:48 PM, Les Hazlewood <[email protected]>wrote: > I'm revisiting this in an effort to resolve it for 1.2, but I have > some questions: > > It is not readily apparent to me why the 'permissive' flag exists (it > has been a month, forgive me). Doesn't it basically just ignore the > authc check and allow the request to pass through no matter what, > thereby invalidating its security purpose? If so, what is the benefit > of doing this? > > At the moment with my little understanding this has the feeling of a > workaround rather than a 'correct' solution (which is sometimes ok, > but I'd prefer to have the latter in an actual release if at all > possible). > > Thanks, > > Les > > On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting > <[email protected]> wrote: > > On 08/15/2011 11:48 AM, Les Hazlewood wrote: > >> It might also be helpful to think about this in a general sense, > >> without being too coupled to Form + BASIC. > >> > >> I believe the problem we're trying to solve is: > >> > >> 1. I don't care how my user is authenticated - just that they are > >> authenticated. > >> 2. If they're not authenticated yet, I want them to be authenticated > >> via one of X, Y or Z (or more) means. > >> > >> It might be better to come up with a mechanism for this rather than > >> focusing on Form + BASIC details specifically (e.g. throw X.509 into > >> the mix or something else). > > I agree on coming up with a more general solution. I feel like this > > problem is a subset of another problem, and perhaps related to yet > another. > > > > 3. At this particular filter level, I don't care if my user is > > authenticated. > > > > (I'm using AOP to do authorization in my application code, and there's a > > decent chance that certain required permissions are assigned to the > > anonymous-user or some functionality may not even have authorization > > requirements). > > > > I'm all for a general solution, and something composition-oriented > > sounds great. I think what I'm interested in is separating the logic of > > "authenticate" from "guarantee user is authenticated". > > > > Thanks, > > Jared >
