Talked to Geert a bit in IRC, but basically my question was about the domain model-based security in RIFE. My experience has been that typically offered role-based security is not flexible enough, but "owner-instance" (my concept) solves about 90% of the remaining cases. Basically, I want to be able to secure access to user's own profile or automatically get only things user owns (or is "associated with") from all things available, so I see no point trying to secure access to some specific urls as the permissions depend on the instance rather than type. I've implemented and used the concept very successfully with Trails (http://trailsframework.org/Security+module) - basically only requiring me to add a single annotation on my domain entity to establish a permission that allows only the current user to access the entity. Unfortunately for me, Tapestry (or any other standard framework) doesn't have a built-in support for conversations (of which I've also written about in http://docs.codehaus.org/display/TRAILS/2008/01/24/Full+Steam+ahead+with+Trails+2.0%21) which of course is the bread and butter in RIFE. So, I wonder if RIFE supports domain-model based security and how is it done in practice (e.g. can you add these rules to the metadata)? I didn't find anything much about it from the documentation, I'd appreciate a link if I missed it.
Kalle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
this is in interesting idea and there's no default support for what
Trail has. However, this doesn't mean that it wouldn't be easy to add
something similar. To be able to give you an educated response, would
you mind explaining me what happens when a user is accessing data that
he doesn't have access to? Does the functionality or the entity simply
disappear? If that's the case, it wouldn't be hard to add this to crud
features of RIFE. We could add meta data to the ConstrainedBean class
that would basically allow you to specify the same information, and
that would then be used by the crud functionalities when the view is
built or the operations are executed.
What do you think?
Best regards,
Geert
On 20 May 2008, at 20:03, Kalle Korhonen wrote:
> Talked to Geert a bit in IRC, but basically my question was about
> the domain model-based security in RIFE. My experience has been that
> typically offered role-based security is not flexible enough, but
> "owner-instance" (my concept) solves about 90% of the remaining
> cases. Basically, I want to be able to secure access to user's own
> profile or automatically get only things user owns (or is
> "associated with") from all things available, so I see no point
> trying to secure access to some specific urls as the permissions
> depend on the instance rather than type. I've implemented and used
> the concept very successfully with Trails (http://trailsframework.org/Security+module > ) - basically only requiring me to add a single annotation on my
> domain entity to establish a permission that allows only the current
> user to access the entity. Unfortunately for me, Tapestry (or any
> other standard framework) doesn't have a built-in support for
> conversations (of which I've also written about in http://docs.codehaus.org/display/TRAILS/2008/01/24/Full+Steam+ahead+with+Trails+2.0%21)
> which of course is the bread and butter in RIFE. So, I wonder if
> RIFE supports domain-model based security and how is it done in
> practice (e.g. can you add these rules to the metadata)? I didn't
> find anything much about it from the documentation, I'd appreciate a
> link if I missed it.
>
> Kalle
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
something similar. To be able to give you an educated response, would you mind explaining me what happens when a user is accessing data that
he doesn't have access to? Does the functionality or the entity simply disappear? If that's the case, it wouldn't be hard to add this to crud
On view/load, it "disappears", or simply isn't available if requested as the primary entity. We considered whether it'd be better to throw some kind of security exception if the data is available, but the user has no permissions to it, but since it really would require two operations on the database, we felt that by default it's better just to hide the data. We consider the situation to be somewhat similar to "username or password incorrect", i.e. security-wise it's better not to let the user know which case it is. On delete/update we throw a security exception if user doesn't have a permission to execute that operation.
In Trails, owner-instance security is on by default if user context is available and it can be "turned off" explicitly if the developer so wishes, but by default it's on if you use the security feature.
features of RIFE. We could add meta data to the ConstrainedBean class that would basically allow you to specify the same information, and
that would then be used by the crud functionalities when the view is built or the operations are executed. What do you think?
To me, it obviously sounds great; I think that domain model -based security is far more powerful and flexible than url-based. Also, the way metadata is specified in RIFE would in principle allow more complex domain-model rules to be specified than what can be achieved with annotations.
Kalle
On 20 May 2008, at 20:03, Kalle Korhonen wrote:
> Talked to Geert a bit in IRC, but basically my question was about
> the domain model-based security in RIFE. My experience has been that > typically offered role-based security is not flexible enough, but > "owner-instance" (my concept) solves about 90% of the remaining
> cases. Basically, I want to be able to secure access to user's own > profile or automatically get only things user owns (or is > "associated with") from all things available, so I see no point
> trying to secure access to some specific urls as the permissions > depend on the instance rather than type. I've implemented and used > the concept very successfully with Trails (http://trailsframework.org/Security+module
> ) - basically only requiring me to add a single annotation on my > domain entity to establish a permission that allows only the current > user to access the entity. Unfortunately for me, Tapestry (or any
> other standard framework) doesn't have a built-in support for > conversations (of which I've also written about in http://docs.codehaus.org/display/TRAILS/2008/01/24/Full+Steam+ahead+with+Trails+2.0%21)
> which of course is the bread and butter in RIFE. So, I wonder if > RIFE supports domain-model based security and how is it done in > practice (e.g. can you add these rules to the metadata)? I didn't
> find anything much about it from the documentation, I'd appreciate a > link if I missed it. > > Kalle > > >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
Domain-model based security. The owner instance one feels a bit bolted
on to me, not sure if it's worth explicitly supporting this. It seems
to me that by adding the domain-model based security to RIFE's meta
data system, the owner instance based one is covered too, since the
meta data is handled on an object instance base.
> something similar. To be able to give you an educated response, would
> you mind explaining me what happens when a user is accessing data that
> he doesn't have access to? Does the functionality or the entity simply
> disappear? If that's the case, it wouldn't be hard to add this to crud
>
> On view/load, it "disappears", or simply isn't available if
> requested as the primary entity. We considered whether it'd be
> better to throw some kind of security exception if the data is
> available, but the user has no permissions to it, but since it
> really would require two operations on the database, we felt that by
> default it's better just to hide the data. We consider the situation
> to be somewhat similar to "username or password incorrect", i.e.
> security-wise it's better not to let the user know which case it is.
> On delete/update we throw a security exception if user doesn't have
> a permission to execute that operation.
Sounds good. Can you please confirm that this is only active for crud
related stuff in Trails (not even sure if Trails even does something
else). I'm thinking that I might actually make this more generic and
add it both to crud for generating the interfaces and to the
GenericQueryManager when database operations are performed on the
domain model. This could make this security model more applicable in
general.
> In Trails, owner-instance security is on by default if user context
> is available and it can be "turned off" explicitly if the developer
> so wishes, but by default it's on if you use the security feature.
That will probably not be the case if this gets implemented by RIFE
since there's no standard concept of an owner or which instance is
owned by who.
> features of RIFE. We could add meta data to the ConstrainedBean class
> that would basically allow you to specify the same information, and
> that would then be used by the crud functionalities when the view is
> built or the operations are executed.
> What do you think?
>
> To me, it obviously sounds great; I think that domain model -based
> security is far more powerful and flexible than url-based. Also, the
> way metadata is specified in RIFE would in principle allow more
> complex domain-model rules to be specified than what can be achieved
> with annotations.
Would you mind adding this as an issue to Jira, with possibly some
ideas of how you would want to use this in RIFE (pseudo code samples).
Since you have first hand experience with domain-model based security
from Trails, you can probably suggest good approaches to do this with
RIFE from a user's perspective.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
just thought about this some more, and it seems to me that the domain-
base security could actually be a special use of instance-based meta
data that is created by inspecting the identity of an authenticated
user.
We could just added some constraints to ConstrainedBean, for instance
'visible', 'editable', 'removable'. These can then be added when the
meta data is constructed, based on for instance the role on an
identified user, or any other criteria. The crud layer can use these
constraints to adapt the interface, and the GenericQueryManager can
use them when executing queries to either reduce the results that are
returned, or to make update and delete statements no-ops.
What do you think?
Geert
On 22 May 2008, at 02:44, Kalle Korhonen wrote:
> On 5/21/08, Geert Bevin <gbevin@...> wrote: Hi Kalle,
> this is in interesting idea and there's no default support for what
> Trail has. However, this doesn't mean that it wouldn't be easy to add
>
> Which one you meant as an interesting idea - the whole domain model -
> based security or owner-instance? Based on http://rifers.org/wiki/display/RIFE/GuideAuthentication#GuideAuthentication-sect1authenticationsitestructure > , it sounds like currently it's not possible to set role-type
> permissions on the domain model either, is that right?
>
> something similar. To be able to give you an educated response, would
> you mind explaining me what happens when a user is accessing data that
> he doesn't have access to? Does the functionality or the entity simply
> disappear? If that's the case, it wouldn't be hard to add this to crud
>
> On view/load, it "disappears", or simply isn't available if
> requested as the primary entity. We considered whether it'd be
> better to throw some kind of security exception if the data is
> available, but the user has no permissions to it, but since it
> really would require two operations on the database, we felt that by
> default it's better just to hide the data. We consider the situation
> to be somewhat similar to "username or password incorrect", i.e.
> security-wise it's better not to let the user know which case it is.
> On delete/update we throw a security exception if user doesn't have
> a permission to execute that operation.
>
> In Trails, owner-instance security is on by default if user context
> is available and it can be "turned off" explicitly if the developer
> so wishes, but by default it's on if you use the security feature.
>
> features of RIFE. We could add meta data to the ConstrainedBean class
> that would basically allow you to specify the same information, and
> that would then be used by the crud functionalities when the view is
> built or the operations are executed.
> What do you think?
>
> To me, it obviously sounds great; I think that domain model -based
> security is far more powerful and flexible than url-based. Also, the
> way metadata is specified in RIFE would in principle allow more
> complex domain-model rules to be specified than what can be achieved
> with annotations.
>
> Kalle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
> Which one you meant as an interesting idea - the whole domain model - > based security or owner-instance? Based on http://rifers.org/wiki/display/RIFE/GuideAuthentication#GuideAuthentication-sect1authenticationsitestructure
> , it sounds like currently it's not possible to set role-type > permissions on the domain model either, is that right? Domain-model based security. The owner instance one feels a bit bolted on to me, not sure if it's worth explicitly supporting this. It seems
to me that by adding the domain-model based security to RIFE's meta data system, the owner instance based one is covered too, since the meta data is handled on an object instance base.
Yes, with owner (in owner-instance) I mostly refer to the current user; generic instance-based permission rules as just too hard; many have tried and failed. In Trails though, the current implementation is a bit bolted on since we are using JPA/Hibernate. However, the annotation-based rule declaration is simple and generic; for example @ViewRequiresAssociation, @ViewRequiresAssociation("owner") where "owner" refers to a property "owner" in that object. (Comparable to @ViewRequiresRole("admin") )
Sounds good. Can you please confirm that this is only active for crud related stuff in Trails (not even sure if Trails even does something
else). I'm thinking that I might actually make this more generic and add it both to crud for generating the interfaces and to the GenericQueryManager when database operations are performed on the domain model. This could make this security model more applicable in
general.
No, this is not for crud-only; you can use it with any persistent entity. Although, I'm not quite sure what you mean by "crud related stuff", what other operations are there in a database-driven web app? (Well, maybe CRUD+S - Trails offers Lucene integration, Hibernate's Criteria API and HQL/SQL for the last letter). But if you mean RoR-style starter pages and flows, then no, Trails doesn't generate any scaffolding. Trails provides usable defaults for component-oriented, domain-driven web development, but you can customize the CRUD operations to your heart's content. The caveat is that Trails is heavily Tapesty-centric; which some people like, some don't.
> In Trails, owner-instance security is on by default if user context > is available and it can be "turned off" explicitly if the developer
> so wishes, but by default it's on if you use the security feature.
That will probably not be the case if this gets implemented by RIFE since there's no standard concept of an owner or which instance is
owned by who.
In Trails, we really view it as an association; the instance-based permission model is based on assocating instances one way or another with the current user. For example; you can be allow to view your wife's data - you are not quite an owner :), but somehow associated with her. Anyway, that's what I was referring to earlier; arbitrary association-based permissions can be too complex to support in a generic way if you don't tie one end to the current user.
Would you mind adding this as an issue to Jira, with possibly some ideas of how you would want to use this in RIFE (pseudo code samples).
Since you have first hand experience with domain-model based security from Trails, you can probably suggest good approaches to do this with RIFE from a user's perspective.
Sure, that's probably a good starting point. And just a note; I didn't want to make this a blurb on Trails, but that's where I'm coming from. That said, I don't particularly care which web framework I use and while I'm very happy with my domain-based permission model in Trails, web conversations have proven to be a tough nut to crack generically with a conventional web framework. My three main issues with web development are security, ajax and conversations; and since RIFE uniquely and rather convincingly solves the last one, maybe I can find a decent solution for the other two in RIFE rather than trying to figure out elaborate, yet complicated solutions for conversations in conventional web frameworks (be it Tapestry, JSF, Seam or Spring WebFlow).
Kalle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
just thought about this some more, and it seems to me that the domain- base security could actually be a special use of instance-based meta
data that is created by inspecting the identity of an authenticated user.
Yes, that absolutely sounds like the right approach. Again in Trails, we figured we can divide (the security) meta data in three categories; static (such as role-type), instance-based (such as our owner-instance) and dynamic (new rules can be placed or removed; often application-specific ACLs). This is important (at least in Trails) so you know what part of metadata can be cached and when it needs to be re-built.
We could just added some constraints to ConstrainedBean, for instance 'visible', 'editable', 'removable'. These can then be added when the
meta data is constructed, based on for instance the role on an identified user, or any other criteria. The crud layer can use these constraints to adapt the interface, and the GenericQueryManager can use them when executing queries to either reduce the results that are
returned, or to make update and delete statements no-ops. What do you think?
Sounds good at least in theory, now somebody just need to implement it :) I'll take a look at these classes and open JIRA issues based on my experiences and how I could see it working in RIFE (without intimate knowledge of your framework).
Kalle
On 22 May 2008, at 02:44, Kalle Korhonen wrote:
> On 5/21/08, Geert Bevin <gbevin@...> wrote: Hi Kalle,
> this is in interesting idea and there's no default support for what > Trail has. However, this doesn't mean that it wouldn't be easy to add > > Which one you meant as an interesting idea - the whole domain model -
> based security or owner-instance? Based on http://rifers.org/wiki/display/RIFE/GuideAuthentication#GuideAuthentication-sect1authenticationsitestructure
> , it sounds like currently it's not possible to set role-type > permissions on the domain model either, is that right? > > something similar. To be able to give you an educated response, would
> you mind explaining me what happens when a user is accessing data that > he doesn't have access to? Does the functionality or the entity simply > disappear? If that's the case, it wouldn't be hard to add this to crud
> > On view/load, it "disappears", or simply isn't available if > requested as the primary entity. We considered whether it'd be > better to throw some kind of security exception if the data is
> available, but the user has no permissions to it, but since it > really would require two operations on the database, we felt that by > default it's better just to hide the data. We consider the situation
> to be somewhat similar to "username or password incorrect", i.e. > security-wise it's better not to let the user know which case it is. > On delete/update we throw a security exception if user doesn't have
> a permission to execute that operation. > > In Trails, owner-instance security is on by default if user context > is available and it can be "turned off" explicitly if the developer > so wishes, but by default it's on if you use the security feature.
> > features of RIFE. We could add meta data to the ConstrainedBean class > that would basically allow you to specify the same information, and > that would then be used by the crud functionalities when the view is
> built or the operations are executed. > What do you think? > > To me, it obviously sounds great; I think that domain model -based > security is far more powerful and flexible than url-based. Also, the
> way metadata is specified in RIFE would in principle allow more > complex domain-model rules to be specified than what can be achieved > with annotations. > > Kalle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users-unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~---
Some parts of this message have been removed.
Learn more about Nabble's security policy.
