Neither am i :) And you could be right about me misusing the principal, but using the actions of a permission for read write and then logically separating permissions with read from permissions with write in different principals does not seem like stretch to me.
Maurice On 6/29/07, craigdd <[EMAIL PROTECTED]> wrote: > > I understand what you are saying and I see how you have accomplished > something similar to what I'm trying to do, however it seems to me that you > are miss using the concept of a Principal. I'm not a security expert but a > principal seems to point to an individual and not with something called > write. Write fits a little better into the concepts of ACL. > > -Craig > > > Mr Mean wrote: > > > >> By the way, I'm not saying wicket security is bad, other than my example > >> I > >> think it is a well put together framework that beats the hell out of > >> using > >> JAAS. > > > > Thanks, i appreciate that :) > > > >> I've had a pretty good look at wicket security but the conclusion that > >> I've > >> come to with that is it only supports the fact that you have pre defined > >> roles within your application. > >> > > > > Well i am not saying it is impossible to declare and add new > > permissions / principals at runtime but i think it is generally > > undesirable to do so. Instead you should make your principals fine > > grained enough to be used as building blocks for roles. > > > >> I'm currently working on a multi tenant web application where the > >> application provided a set of permission, such and read / write access to > >> an > >> object and each tenant in the application defines their own role heirachy > >> based on those permissions. > > > > This is exactly what we are doing in our application. We have > > literally +- 1000 principals defined in our system. By allowing the > > users to group principals together they can build there own roles. We > > have multiple organizations in our application and each of them can > > completely redesign there user roles in the system (well only up to a > > point because we could not allow that, but that aside they could). We > > provide each organization with a set of default roles as we think will > > suit most of them but they are completely free to alter/ rename/ > > delete/ whatever do with those roles because we do not depend on the > > roles but on the underlying principals, which are controlled by us. A > > big help is the fact that we made our principals imply each other > > (write implies read, etc) So when a user designs there roles they > > don't have to check read access to page A and write access to page A > > but can suffice with write access to page A. Although most of our > > principals handle a couple of related pages we also have principals > > going as deep as individual components. For instance we have a large > > data grid, the principals are fine grained enough to give you read or > > write access up to the individual cell. > > > > Correct me if i am wrong but this seems to be what you want too. > > > > Maurice > > > > > > On 6/28/07, craigdd <[EMAIL PROTECTED]> wrote: > >> > >> I've had a pretty good look at wicket security but the conclusion that > >> I've > >> come to with that is it only supports the fact that you have pre defined > >> roles within your application. > >> > >> I'm currently working on a multi tenant web application where the > >> application provided a set of permission, such and read / write access to > >> an > >> object and each tenant in the application defines their own role heirachy > >> based on those permissions. > >> > >> We are currently using acegi and I'm trying to figure out the best way to > >> bake acl into wicket's components. Example, a link is set to invisible > >> if > >> the authenticated use doesn't contain a role with the given permission of > >> that link. So lets say the link is to delete an object, the user must > >> have > >> a role with the permission to delete that object or the link will not > >> show > >> on the page. > >> > >> By the way, I'm not saying wicket security is bad, other than my example > >> I > >> think it is a well put together framework that beats the hell out of > >> using > >> JAAS. > >> > >> -Craig > >> > >> > >> Mr Mean wrote: > >> > > >> > If you mean java Jaas like acl than swarm is what you are looking for. > >> > Optionally if you really want to use jaas and not some look alike i > >> > made up you could practically copy swarm and replace most objects with > >> > there jaas counterparts. > >> > However i chose not to use jaas because we are using that in one of > >> > our projects right now and although it works it is less than optimal > >> > :) As soon as we make the switch to wicket 1.3.0 jaas will be replaced > >> > by swarm. > >> > > >> > You can also check out the example project here > >> > > >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security-examples > >> > > >> > > >> > Maurice > >> > > >> > On 6/21/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > >> >> wicket's security model is completely generic > >> >> > >> >> see IAuthorizationStrategy - it is very abstract and thus can be used > >> to > >> >> implement any kind of authorization > >> >> > >> >> wicket-auth is just an example that implements basic role-based model > >> >> > >> >> see wicket-stuff wasp and swarm projects > >> >> > >> >> http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security > >> >> > >> >> -igor > >> >> > >> >> > >> >> On 6/21/07, craigdd <[EMAIL PROTECTED]> wrote: > >> >> > > >> >> > Is wicket security based only on role based authorization or could > >> it > >> >> somehow > >> >> > be used with a more traditional ACL type of file / logic. > >> >> > > >> >> > -Craig > >> >> > -- > >> >> > View this message in context: > >> >> > >> http://www.nabble.com/wicket-security-and-acl-files-tf3960558.html#a11239024 > >> >> > Sent from the Wicket - User mailing list archive at Nabble.com. > >> >> > > >> >> > > >> >> > > >> >> > >> ------------------------------------------------------------------------- > >> >> > This SF.net email is sponsored by DB2 Express > >> >> > Download DB2 Express C - the FREE version of DB2 express and take > >> >> > control of your XML. No limits. Just data. Click to get it now. > >> >> > http://sourceforge.net/powerbar/db2/ > >> >> > _______________________________________________ > >> >> > Wicket-user mailing list > >> >> > Wicket-user@lists.sourceforge.net > >> >> > https://lists.sourceforge.net/lists/listinfo/wicket-user > >> >> > > >> >> > >> >> > >> >> > >> ------------------------------------------------------------------------- > >> >> This SF.net email is sponsored by DB2 Express > >> >> Download DB2 Express C - the FREE version of DB2 express and take > >> >> control of your XML. No limits. Just data. Click to get it now. > >> >> http://sourceforge.net/powerbar/db2/ > >> >> _______________________________________________ > >> >> Wicket-user mailing list > >> >> Wicket-user@lists.sourceforge.net > >> >> https://lists.sourceforge.net/lists/listinfo/wicket-user > >> >> > >> >> > >> > > >> > > >> ------------------------------------------------------------------------- > >> > This SF.net email is sponsored by DB2 Express > >> > Download DB2 Express C - the FREE version of DB2 express and take > >> > control of your XML. No limits. Just data. Click to get it now. > >> > http://sourceforge.net/powerbar/db2/ > >> > _______________________________________________ > >> > Wicket-user mailing list > >> > Wicket-user@lists.sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > > >> > > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/wicket-security-and-acl-files-tf3960558.html#a11350022 > >> Sent from the Wicket - User mailing list archive at Nabble.com. > >> > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by DB2 Express > >> Download DB2 Express C - the FREE version of DB2 express and take > >> control of your XML. No limits. Just data. Click to get it now. > >> http://sourceforge.net/powerbar/db2/ > >> _______________________________________________ > >> Wicket-user mailing list > >> Wicket-user@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wicket-user > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > -- > View this message in context: > http://www.nabble.com/wicket-security-and-acl-files-tf3960558.html#a11352386 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user