Re: [Wicket-user] wicket security and acl files
A subject is the root/ abstract entity for a user, principals are views or identities of a subject Well I'm glad we all agree on that one :) However as Eelco said a principal can be much more than just a role. So i am a little reluctant to rename Principal to Role. If i wanted to i could even use the Swarm Subjects as Roles (although that would be a really long stretch, and certainly not recommended :) ). And although the fact that you can use principals / subjects in several ways might make it less clear from the start how to use them, that is also there power as it gives you greater flexibility on how to set up your security. That being said i am still open for renaming suggestions, i just don't think role should be it. an application that is more fluid and tenants can create their own structure of roles. I am sorry that you feel swarm does not accommodate you enough in this field. But I welcome you to build upon wasp and enrich the wicket community with your work. Looking at swarm should have given you a pretty clear picture of the security building blocks in wicket. Maurice On 6/29/07, Craig Lenzen [EMAIL PROTECTED] wrote: A subject is the root/ abstract entity for a user, principals are views or identities of a subject and in JAAS you would represent a role as a principal. I agree with your statement which leads me to the fact that the principal should really be a role in swarm and the hive file is a mapping of a role to given permissions and actions. So back to what I said before, swarm is really nice when you have an application with pre-defined roles instead of an application that is more fluid and tenants can create their own structure of roles. -Craig Eelco Hillenius wrote: Right now swarm operates the following way: A user is associated with 1 or more Subjects, each Subject has 0 or more Principals. This sounds right to me, and is like how JAAS works. A subject is the root/ abstract entity for a user, principals are views or identities of a subject and in JAAS you would represent a role as a principal. As JAAS is the default authorization mechnism in Java, it is arguably the 'industry standard' (for Java). Whether it is what you prefer is another question. I think people find users/ roles easier to understand, but personally I like the more abstracted model of JAAS; whether you want to model groups, roles a combination of the two or even something different, it fits seamlessly. My 2c, Eelco - 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#a11364093 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
Re: [Wicket-user] wicket security and acl files
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
Re: [Wicket-user] wicket security and acl files
take maurice's post and substitute word permission for word principal, define user/principal as an object that has a set of permissions, and it makes perfect sense. -igor On 6/28/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
Re: [Wicket-user] wicket security and acl files
Actually that is already how they work. Even though the Principal
class does not have methods for getting and setting the Permissions.
The mapping is done in the policy file like this.
grant principal ${RechtenSet} PageA.read
{
//read permission for all of page A
permission ${ComponentPermission}
nl.topicus.krypton.web.pages.PageA, inherit, render;
};
grant principal ${RechtenSet} PageA.write
{
//write permission for all form components on page A
permission ${ComponentPermission}
nl.topicus.krypton.web.pages.PageA:form, inherit, enable;
};
grant principal ${RechtenSet} PageA.delete
{
//allow separate delete links to be clicked
permission ${ComponentPermission}
nl.topicus.krypton.web.pages.PageA:deleteLink1, enable;
permission ${ComponentPermission}
nl.topicus.krypton.web.pages.PageA:deleteLink2, enable;
};
I know the api doc for principal states which can be used to
represent any entity, such as an individual, a corporation, or a login
id. I admit it is shamelessly copied from java.security.Principal :)
And now that i think about i can see the way we use principals like
permissions now actually comes from our dealings with jaas. But i
still feel it is not a big issue. I'll just rewrite the api doc ;)
Maurice
On 6/29/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
take maurice's post and substitute word permission for word principal,
define user/principal as an object that has a set of permissions, and it
makes perfect sense.
-igor
On 6/28/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
Re: [Wicket-user] wicket security and acl files
Just my two cents but I think the API should change, or I guess not really the API but the implementation(swarm) to better reflect industry naming standards which will hopefully cut down on the confusion and hopefully make it a little easier to integrate other security frameworks. I use acegi as an example, they have an Authentication object that has a method getPrincipal which if you read their javadoc makes it pretty clear that an authenticated entity has one principal, which also seems to fit with JAAS. -Craig Mr Mean wrote: 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
Re: [Wicket-user] wicket security and acl files
I am open to suggestions for alternate names, or if someone could point me to the naming standards :) Right now swarm operates the following way: A user is associated with 1 or more Subjects, each Subject has 0 or more Principals. Each Principal is mapped to 1 or more Permissions. Each Permission has 0 or more Actions. Permissions and actions are named pretty straight forward i think. Maurice On 6/29/07, craigdd [EMAIL PROTECTED] wrote: Just my two cents but I think the API should change, or I guess not really the API but the implementation(swarm) to better reflect industry naming standards which will hopefully cut down on the confusion and hopefully make it a little easier to integrate other security frameworks. I use acegi as an example, they have an Authentication object that has a method getPrincipal which if you read their javadoc makes it pretty clear that an authenticated entity has one principal, which also seems to fit with JAAS. -Craig Mr Mean wrote: 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
Re: [Wicket-user] wicket security and acl files
The way it sounds is that principal should really be renamed to role. Roles typically have 0 or more permissions. Although if you consider the hive as a mapping of roles to permissions then you are really back to what I said earlier where swarm is handy if your application pre-defines the roles that are available. -Craig Mr Mean wrote: I am open to suggestions for alternate names, or if someone could point me to the naming standards :) Right now swarm operates the following way: A user is associated with 1 or more Subjects, each Subject has 0 or more Principals. Each Principal is mapped to 1 or more Permissions. Each Permission has 0 or more Actions. Permissions and actions are named pretty straight forward i think. Maurice On 6/29/07, craigdd [EMAIL PROTECTED] wrote: Just my two cents but I think the API should change, or I guess not really the API but the implementation(swarm) to better reflect industry naming standards which will hopefully cut down on the confusion and hopefully make it a little easier to integrate other security frameworks. I use acegi as an example, they have an Authentication object that has a method getPrincipal which if you read their javadoc makes it pretty clear that an authenticated entity has one principal, which also seems to fit with JAAS. -Craig Mr Mean wrote: 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
Re: [Wicket-user] wicket security and acl files
Right now swarm operates the following way: A user is associated with 1 or more Subjects, each Subject has 0 or more Principals. This sounds right to me, and is like how JAAS works. A subject is the root/ abstract entity for a user, principals are views or identities of a subject and in JAAS you would represent a role as a principal. As JAAS is the default authorization mechnism in Java, it is arguably the 'industry standard' (for Java). Whether it is what you prefer is another question. I think people find users/ roles easier to understand, but personally I like the more abstracted model of JAAS; whether you want to model groups, roles a combination of the two or even something different, it fits seamlessly. My 2c, Eelco - 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
Re: [Wicket-user] wicket security and acl files
A subject is the root/ abstract entity for a user, principals are views or identities of a subject and in JAAS you would represent a role as a principal. I agree with your statement which leads me to the fact that the principal should really be a role in swarm and the hive file is a mapping of a role to given permissions and actions. So back to what I said before, swarm is really nice when you have an application with pre-defined roles instead of an application that is more fluid and tenants can create their own structure of roles. -Craig Eelco Hillenius wrote: Right now swarm operates the following way: A user is associated with 1 or more Subjects, each Subject has 0 or more Principals. This sounds right to me, and is like how JAAS works. A subject is the root/ abstract entity for a user, principals are views or identities of a subject and in JAAS you would represent a role as a principal. As JAAS is the default authorization mechnism in Java, it is arguably the 'industry standard' (for Java). Whether it is what you prefer is another question. I think people find users/ roles easier to understand, but personally I like the more abstracted model of JAAS; whether you want to model groups, roles a combination of the two or even something different, it fits seamlessly. My 2c, Eelco - 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#a11364093 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
Re: [Wicket-user] wicket security and acl files
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
Re: [Wicket-user] wicket security and acl files
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/
Re: [Wicket-user] wicket security and acl files
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:
[Wicket-user] wicket security and acl files
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
Re: [Wicket-user] wicket security and acl files
Any strategy you like. Check out IAuthorizationStrategy. Eelco 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
Re: [Wicket-user] wicket security and acl files
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
