Hi Shay, Daniel is correct. Data models (users, groups, roles, permissions, etc, etc) vary widely across applications - JSecurity can't, and shouldn't, expect or enforce data model APIs on framework end-users.
So, the Realms perform simple translation from an application's data model to what JSecurity expects, in the form of AuthenticationInfo and AuthorizationInfo return values that JSecurity does understand. When writing an application, I do all CRUD operations for security data - users, roles, etc in a different place - e.g. a UserManager. The Realm implementation just delegates to the UserManager (or similar) to get the data necessary for JSecurity, then transforms it as necessary, and returns it. It stays read-only while the UserManager does read/write/update. Your Realm can interact with a datasource directly too if you want - it is up to you. I just choose to delegate since the UserManager already has a DAO that interacts with the datasource - no need for me to use the datasource APIs in two different places. But it is still your choice dependening on your needs/desires. If you want a head-start in creating your own data model that will work very well, either with or without JSecurity, take a look at the Spring/Hibernate sample application that ships with JSecurity's distribution. It has User, Role, and Permission objects all queried/saved by Hibernate. Even if you don't use Hibernate, the data model in that sample app will give you ideas. Cheers, Les On Thu, Feb 26, 2009 at 10:50 AM, Daniel J. Lauk <[email protected]>wrote: > Hello, Shay. > > AFAIK the JSecurity framework only provides interfaces for "consuming" > (=reading) information. > (Side note: I'm not sure, if the DAO pattern considers write access in > the first place) > > Of course, when you write your implementation of the > org.jsecurity.realm.Realm interface you can add such functionality to > your implementing class. > > Cheers, > DJ > > 2009/2/26 Shay Matasaro <[email protected]>: > > Hi Les, > > > > Thank you for the prompt reply. > > > > i have been reviewing all Realm implementations , but I am obviously > missing > > something , since implementing a custom realm only requires implementing > 2 > > DB queries. > > > > what i don't see , is where does the DB persistence take place , i.e. > > persisting new users, roles, groups , permissions; I assume that i need > to > > implements all of these, by extending existing classes. > > > > do i have to implement my own token, user, account, role, group , etc..? > > or are there specific extension point that i can hook into , without > > overriding the whole model? > > > > > > Thanks, > > Shay > > > > > > > > Les Hazlewood wrote: > >> > >> Hi Shay, > >> > >> JSecurity can use any data source - it does that by wrapping access to > >> that data source in a Realm implementation: > >> > >> http://www.jsecurity.org/api/org/jsecurity/realm/Realm.html > >> > >> A Realm is essentially a security-specific DAO, so you can communicate > >> with any back-end you need. Check out the Sample applications in the > >> JSecurity distribution, as well as some of the Realm implementations > here: > >> > >> > >> > http://svn.apache.org/repos/asf/incubator/jsecurity/trunk/core/src/org/jsecurity/realm/ > >> > >> Look at the text, jndi, ldap sub packages for ideas, as well as the > sample > >> applications that ship with JSecurity's distribution. > >> > >> I hope that helps! > >> > >> Cheers, > >> > >> Les > >> > >> On Thu, Feb 26, 2009 at 8:53 AM, Shay Matasaro <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi All, > >> > >> I ran into JSecurity yesterday and it looks very promising, i'd > >> like to add it to my web service application. > >> > >> The only hurdle to cross is the fact that my app uses its own > >> "object oriented DB" ; i would therefore like to customize > >> Jsecurity to use our own data layer. > >> > >> is it possible to customize just the low-level db access , and > >> allow JSecurity to maintain all the great features that it offers > >> without rewriting all aspects? > >> > >> if so what is the bare minimum list of objects and interfaces that > >> i need to extend in order to achieve that goal (this is a new app > >> , so i don't have to align with any existing table schema). > >> > >> To the project developers , Great Job! , the library seems very > >> simple and easy to use, and after messing about with JAAS for > >> awhile , i can really value simplicity. > >> > >> Thanks, > >> Shay > >> > >> > >> > >> > > > > >
