Hi Shay - no, you don't have to implement Permission related aspects. You can just use Strings, and JSecurity's default PermissionResolver will translate those Strings into WildcardPermission objects ( http://www.jsecurity.org/api/org/jsecurity/authz/permission/WildcardPermission.html ).
You would only need to implement your own Permission class (or subclass WildcardPermission) if you wanted type-safety. I should update the Spring/Hibernate application to do this. Please add a Jira issue if you'd like to see type-safe subclasses - just so we have it tagged and not forgotton. Cheers, Les On Thu, Feb 26, 2009 at 12:41 PM, Shay Matasaro <[email protected]> wrote: > Thanks for the replies guys. > > so its up to me to implement all permissions related aspects including > wildcards , and instance levels ones, seems a bit tricky ? > > > I think that the end goal for a security framework should include top to > bottom interfaces and *Object *data model (definitely not table schemes , > just class and interface definitions) , this approach would still allow > developers to wire the framework to any data storage, but the model will > enforce proper architecture. > > for an experienced developer some of these design decisions , might look > simple , but junior and intermediate devs require some guidelines especially > when doing first time implementations. > > > Thanks, > Shay > > > Les Hazlewood wrote: > >> 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]<mailto: >> [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] >> <mailto:[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]> >> >> <mailto:[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 >> >> >> >> >> >> >> >> >> > >> > >> >> >> >
