You can use Shiro's support to Cache for storing authentication and authorization information. It can be enabled besides the use of session. Using some CacheManager will prevent your application to execute the authentication logic for every request.
I've developed the architecture of a JAX-RS project disabling Session and enabling Cache and it worked just fine. I was using Bcrypt too and I had configured for 100k iterations. Shiro has a default implementation of CacheManager using EhCache, EhCacheManager. I've used it. You can find everything on Shiro's documentation about how to enable Cache and how to disable Session. -- D. Reinert On Fri, Nov 8, 2013 at 12:57 AM, Josh Berry <[email protected]> wrote: > Is there an easy way to do that outside of just enabling short lived > sessions and not putting anything in them? (That is, only use them to > store a validated user?) > > > On Thu, Nov 7, 2013 at 9:30 PM, Jared Bunting <[email protected] > > wrote: > >> I believe that the common way for REST APIs to address this is to use >> short-lived auth tokens. This basically gives you the same thing as the >> sessions without the "stateful" part of sessions. >> On Nov 7, 2013 6:23 PM, "Josh Berry" <[email protected]> wrote: >> >>> One real quick suggestion, if you can, go ahead and enable sessions. I >>> believe that gets you basically what you want. When the user is >>> successfully authenticated, from that point on you will actually be relying >>> on the session cookie instead of the authentication cookie. If the >>> "session" is ever not found, you then create a new one and authenticate it. >>> >>> I realize this breaks the "stateless rest" backend, and I have far from >>> thought it through. Just an idea that occurred to me as being rather easy >>> to get running. >>> >>> >>> On Thu, Nov 7, 2013 at 6:08 PM, Josh Berry <[email protected]> wrote: >>> >>>> To be fair, more iterations is a good idea. I'll try and take a look >>>> this evening and see if i can figure something out. >>>> On Nov 7, 2013 4:04 PM, "saadmufti" <[email protected]> wrote: >>>> >>>>> Yes, I tried that and that worked!!! So you were right. Also stepped >>>>> throught >>>>> the code and verified: >>>>> >>>>> 1) the authentication info getting cached is the hashed version >>>>> 2) all the caching is saving is getting the info from disk, it is still >>>>> hashing the passed in auth info all over again to compare to the info >>>>> it >>>>> gets from the cache >>>>> >>>>> So yes reducing the number of iterations immensely speeds this up, I >>>>> vaguely >>>>> remember now that I used 500000 a couple of months ago after reading >>>>> some >>>>> blog post that recommended upping the iterations for more security. >>>>> Shows >>>>> you the perils of following advice without completely understanding. >>>>> >>>>> What would be ideal would be if the caching would work like how you >>>>> suggested, that is it would cache the plaintext after comparing and >>>>> use that >>>>> for the future as long as the cache entry existed. But right now it >>>>> does the >>>>> opposite, it caches the hashed info and hashes the plaintext >>>>> username/password passed in and then does the comparison. >>>>> >>>>> Any quick ideas on how to tweak this to do what you suggested? >>>>> Prefereably >>>>> not involving heavy duty subclassing etc. :-) >>>>> >>>>> Thanks for all your help. >>>>> >>>>> ---- >>>>> Saad >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://shiro-user.582556.n2.nabble.com/Shiro-Auth-On-REST-API-Killing-CPU-tp7579340p7579346.html >>>>> Sent from the Shiro User mailing list archive at Nabble.com. >>>>> >>>> >>> >
