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

Reply via email to