Hi Willi, Just for future access, our reference guide starts here: http://incubator.apache.org/shiro/reference.html
1. The SessionManager by default is required because authentication state and identity information is stored in a session after login. This can be disabled with a little work if you want to manage authentication/identity state yourself however. The DefaultSecurityManager bind and unbind methods would need to be overridden to handle this yourself. 2. Background tasks are handled by manually creating a subject instance that represents the User you want, and then executing code as that Subject. That is documented here: http://incubator.apache.org/shiro/subject.html Look for the section entitled "Automatic Association". This is how you will want to execute work as a system/daemon user. 3. CacheManager - the CaheManager will be set on your realms automatically if you configure one on the SecurityManager instance and your Realm implementations extend CachingRealm (or one of its subclasses). 4. You can manage Subject instances and how you acquire them yourself (instead of using SecurityUtils) by using the Subject.Builder mechanism. If you would like to acquire/set Subject instances via SecurityUtils, please open a Jira issue and we can look in to adding that feature (e.g. maybe SecurityUtils uses a 'SubjectAccessor' or something like that). 5. By default you have to have some way of associating a Subject with authorization credentials. One way to solve this is to have an 'anonymous' user account that you assign roles and permissions to that all non-logged in users default to. There is another way that is a little more difficult that I can think of, but most people are fine with the shared account approach. If you have any good ideas and think this should be supported out of the box, please open a Jira feature request. HTH, Les 2010/2/19 Willi Schönborn <[email protected]>: > Hi, > > i am trying to integrate in our codebase and have > some questions i couldn't find answer in the documentation. > > Is the session manager a requirement for the security logic > to work properly? What if my application is not using sessions? > How are background tasks usually handled? Is there a "system" user, like > root under *nix? > The cache manager is explicitly used by my realms or is there some > "magic" involved? > Where do i store the subject/user in an environment where i cant > rely on threadlocals? > Can anonymous user have permissions? > > That's so far. If some of my questions are too simple > or just dumb, just point me to the documentation > that handles it. > > Greetings > W > > -- > Willi Schoenborn / Software Development > __ CosmoCode GmbH - http://www.cosmocode.de > __ Prenzlauer Allee 36, 10405 Berlin, Germany > __ Tel +49 30 814504087, Fax +49 30 28097093 > __ > __ Geschaeftsfuehrung (CEO): D. Huettemann, J. Riebesell > __ Amtsgericht Berlin-Charlottenburg, HRB 74063 >
