This is awesome. The existing Spring/Hibernate app has almost everything you need to start with, doesn't it? It just doesn't have a front-end. Could you just use that? Or would you want to make a different sample app entirely?
On Thu, Feb 26, 2009 at 2:34 PM, Jeremy Haile <[email protected]> wrote: > A bit OT, but I'm planning to create another sample app pretty soon > (hopefully this weekend) that I am going to use for a presentation at the > DevNexus conference in Atlanta. It's going to be a pure Spring/HIbernate > webapp that uses all the latest jazz - Spring, JPA, and JSecurity > annotations, wildcard permissions, etc. I would be happy to update the > existing sample app at the same time. > Jeremy > > > > On Feb 26, 2009, at 1:11 PM, Les Hazlewood wrote: > > 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 >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> >>> >>> >> > >
