OK, I think I understand, and am swinging back toward the way I was
originally using Shiro.
Originally, Shiro just worked with my authentication information, and I
stored other user details in an Account object keyed off of the
subject's ID.
Then I thought there might be some benefit to making most of these
values principals.
Now, from what you're saying, it makes sense to only store
authentication/authorization info in Shiro's objects. While the
documentation might indicate that names and other details can be
considered principals, that doesn't mean they should be so.
Thanks, I'll move my non-authenticating principals into a separate
object and stick with keeping only the authenticating/authorizing
details in Shiro.
On 03/13/2013 05:25 PM, Les Hazlewood wrote:
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?
