The SubjectDAO is for customizing Shiro's behavior only and is not intended to be used as part of your application's architecture. It is provided to allow those using Shiro to customize subject state storage techniques if desired (for example, maybe off-heap storage or an enterprise cache instead of the session). The large majority of apps never need to customize the SessionDAO though because they're fine using sessions. 100% stateless apps however might customize (or disable) the SessionDAO to retain statelessness.
If you have your own User object concept in your data model, you'll want to use that, using the Subject's primary principal as a handle/pointer to get to that object. Then you'll perform User CRUD operations as normal during your normal application workflow(s). To give a little color around this, Shiro is a read-mostly framework - it can look up security data and represent that data in a uniform way (Subject, roles, permissions, etc). But because data models vary dramatically across applications, Shiro doesn't do much 'writing' back into your application's data stores (because Shiro can't know what your User object looks like vs my User object, etc). Does this help? Best, -- Les Hazlewood | @lhazlewood CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282 Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk On Wed, Mar 13, 2013 at 2:29 PM, Nolan Darilek <[email protected]> wrote: > Another design question: > > I'm working on storing my account data into MongoDB. For a while, I've had > two Subject objects--Shiro's, and my own. > > This is getting ugly fast. I just refactored such that my app's primary > principal is the MongoDB ObjectId of the subject, and this vastly simplifies > many of my use cases. I no longer need my own Subject class to reference > subjects from other documents, and can just stash the primary principal or > use it for record lookups. My one remaining case is modifying subjects to > create a new account or change principal values, then saving the subject to > the database. > > I see there is a SubjectDAO with basic save and delete methods. > DefaultSubjectDAO appears to persist subjects in sessions though, and I'm > wondering if this DAO isn't intended to be modified for saving subjects in a > database? > > I was thinking of calling getSecurityManager().getSubjectDAO().save(subject) > rather than my Mongo-specific code. Then my app wouldn't really care what > persisted its subjects, and I could potentially migrate to something else in > the future. Is this not what SubjectDAO was intended for, though?
