Some basic field-level security

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Some basic field-level security

Barry Davies
I've been investigating some security approaches I might use in the event that they are necessary within the scope of future development using Stripes and one of the issues for which I thought direct Stripes support would be of broad benefit was some sort of annotation, potentially a validation annotation, that lets Stripes know that no binding should be performed for certain properties of my entities.  In some application circumstances, it could well be the case that some people who know how to use TamperData and have some knowledge of my entity properties could coerce a page that isn't supposed to be able to change certain properties into changing any property, and I'm trying to prevent that as conveniently as possible.  Does this sound like a good idea to anyone else?

-BD aka RJ


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

John W Newman
Barry Davies <barry.davies7@...> writes:

>
>
> I've been investigating some security approaches I might use in the event that
they are necessary within the scope of future development using Stripes and one
of the issues for which I thought direct Stripes support would be of broad
benefit was some sort of annotation, potentially a validation annotation, that
lets Stripes know that no binding should be performed for certain properties of
my entities.  In some application circumstances, it could well be the case that
some people who know how to use TamperData and have some knowledge of my entity
properties could coerce a page that isn't supposed to be able to change certain
properties into changing any property, and I'm trying to prevent that as
conveniently as possible.  Does this sound like a good idea to anyone else?
-BD aka
>  RJ

This exact topic came up when stripernate was first released.  If you check
throught the archives there's a pretty good discussion on it.

But yes I think it is a good idea, stripes (& stripernate) makes my database so
easy to manipulate with a web browser it is kind of scary.





-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Barry Davies-2
In reply to this post by Barry Davies
Guh!  I'll look there for the discussion.  One thing, though:  did a clear verdict come out of that discussion?

-BD aka RJ

----- Original Message ----
From: John Newman <[hidden email]>
To: [hidden email]
Sent: Tuesday, October 17, 2006 2:08:49 PM
Subject: Re: [Stripes-users] Some basic field-level security

Barry Davies <barry.davies7@...> writes:

>
>
> I've been investigating some security approaches I might use in the event that
they are necessary within the scope of future development using Stripes and one
of the issues for which I thought direct Stripes support would be of broad
benefit was some sort of annotation, potentially a validation annotation, that
lets Stripes know that no binding should be performed for certain properties of
my entities.  In some application circumstances, it could well be the case that
some people who know how to use TamperData and have some knowledge of my entity
properties could coerce a page that isn't supposed to be able to change certain
properties into changing any property, and I'm trying to prevent that as
conveniently as possible.  Does this sound like a good idea to anyone else?
-BD aka
>  RJ

This exact topic came up when stripernate was first released.  If you check
throught the archives there's a pretty good discussion on it.

But yes I think it is a good idea, stripes (& stripernate) makes my database so
easy to manipulate with a web browser it is kind of scary.





-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Ben Gunter
I've already written and am using these access controls. I just haven't posted it for download because I keep getting distracted by stupid stuff. I will make source and binary packages available sometime tonight (US Eastern).

-Ben

Barry Davies wrote:
Guh!  I'll look there for the discussion.  One thing, though:  did a clear verdict come out of that discussion?

-BD aka RJ

----- Original Message ----
From: John Newman [hidden email]
To: [hidden email]
Sent: Tuesday, October 17, 2006 2:08:49 PM
Subject: Re: [Stripes-users] Some basic field-level security

Barry Davies [hidden email] writes:

>
>
> I've been investigating some security approaches I might use in the event that
they are necessary within the scope of future development using Stripes and one
of the issues for which I thought direct Stripes support would be of broad
benefit was some sort of annotation, potentially a validation annotation, that
lets Stripes know that no binding should be performed for certain properties of
my entities.  In some application circumstances, it could well be the case that
some people who know how to use TamperData and have some knowledge of my entity
properties could coerce a page that isn't supposed to be able to change certain
properties into changing any property, and I'm trying to prevent that as
conveniently as possible.  Does this sound like a good idea to anyone else?
-BD aka
>  RJ

This exact topic came up when stripernate was first released.  If you check
throught the archives there's a pretty good discussion on it.

But yes I think it is a good idea, stripes (& stripernate) makes my database so
easy to manipulate with a web browser it is kind of scary.





-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________ Stripes-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/stripes-users

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Ben Gunter
As promised, version 0.1 of Stripes Extras is now available. You can download it here: http://www.bengunter.com/stripex

All the documentation is in that zip file under doc. There's a guide that explains how to use the access controls. No doubt this document can be improved upon, but it should be good enough to get you going. There's also plenty of info in the Javadocs, which are also included. The source code is in src and the binary build is at build/stripes-extras-0.1.jar.

This code works for me as it is now. If you encounter any problems, let me know. I don't have a bug-tracker. I'll have to gauge interest to determine if that would be a worthwhile effort.

Hope this helps somebody out. As the plural name implies, this is intended to provide multiple enhancements, but right now all it provides is property binding access control.

-Ben

Ben Gunter wrote:
I've already written and am using these access controls. I just haven't posted it for download because I keep getting distracted by stupid stuff. I will make source and binary packages available sometime tonight (US Eastern).

-Ben

Barry Davies wrote:
Guh!  I'll look there for the discussion.  One thing, though:  did a clear verdict come out of that discussion?

-BD aka RJ

----- Original Message ----
From: John Newman [hidden email]
To: [hidden email]
Sent: Tuesday, October 17, 2006 2:08:49 PM
Subject: Re: [Stripes-users] Some basic field-level security

Barry Davies [hidden email] writes:

>
>
> I've been investigating some security approaches I might use in the event that
they are necessary within the scope of future development using Stripes and one
of the issues for which I thought direct Stripes support would be of broad
benefit was some sort of annotation, potentially a validation annotation, that
lets Stripes know that no binding should be performed for certain properties of
my entities.  In some application circumstances, it could well be the case that
some people who know how to use TamperData and have some knowledge of my entity
properties could coerce a page that isn't supposed to be able to change certain
properties into changing any property, and I'm trying to prevent that as
conveniently as possible.  Does this sound like a good idea to anyone else?
-BD aka
>  RJ

This exact topic came up when stripernate was first released.  If you check
throught the archives there's a pretty good discussion on it.

But yes I think it is a good idea, stripes (& stripernate) makes my database so
easy to manipulate with a web browser it is kind of scary.





-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________ Stripes-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/stripes-users

------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________ Stripes-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/stripes-users

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

VANKEISBELCK Remi
Thanks a lot Ben !

Tim, do you plan to include that (or something similar) in the stripes "core" ?

I definitly think it's a mandatory feature that should be available
out-of-the box... Property Binding without possible restrictions is
simply not usable in prod, and those annots look like a really nice
solution to this problem !

Maybe we (Stripes users) could test Ben's code for some time, in order
to check possible bugs, and then maybe you could integrate it to
stripes ??

My $0.02

Have fun,

Rémi

On 10/18/06, Ben Gunter <[hidden email]> wrote:

>
>  As promised, version 0.1 of Stripes Extras is now available. You can
> download it here: http://www.bengunter.com/stripex
>
>  All the documentation is in that zip file under doc. There's a guide that
> explains how to use the access controls. No doubt this document can be
> improved upon, but it should be good enough to get you going. There's also
> plenty of info in the Javadocs, which are also included. The source code is
> in src and the binary build is at build/stripes-extras-0.1.jar.
>
>  This code works for me as it is now. If you encounter any problems, let me
> know. I don't have a bug-tracker. I'll have to gauge interest to determine
> if that would be a worthwhile effort.
>
>  Hope this helps somebody out. As the plural name implies, this is intended
> to provide multiple enhancements, but right now all it provides is property
> binding access control.
>
>  -Ben
>
>  Ben Gunter wrote:
>  I've already written and am using these access controls. I just haven't
> posted it for download because I keep getting distracted by stupid stuff. I
> will make source and binary packages available sometime tonight (US
> Eastern).
>
>  -Ben
>
>  Barry Davies wrote:
>
>
> Guh!  I'll look there for the discussion.  One thing, though:  did a clear
> verdict come out of that discussion?
>
>  -BD aka RJ
>
>
> ----- Original Message ----
>  From: John Newman <[hidden email]>
>  To: [hidden email]
>  Sent: Tuesday, October 17, 2006 2:08:49 PM
>  Subject: Re: [Stripes-users] Some basic field-level security
>
>
> Barry Davies <barry.davies7@...> writes:
>
>  >
>  >
>  > I've been investigating some security approaches I might use in the event
> that
>  they are necessary within the scope of future development using Stripes and
> one
>  of the issues for which I thought direct Stripes support would be of broad
>  benefit was some sort of annotation, potentially a validation annotation,
> that
>  lets Stripes know that no binding should be performed for certain
> properties of
>  my entities.  In some application circumstances, it could well be the case
> that
>  some people who know how to use TamperData and have some knowledge of my
> entity
>  properties could coerce a page that isn't supposed to be able to change
> certain
>  properties into changing any property, and I'm trying to prevent that as
>  conveniently as possible.  Does this sound like a good idea to anyone else?
>  -BD aka
>  >  RJ
>
>  This exact topic came up when stripernate was first released.  If you check
>  throught the archives there's a pretty good discussion on it.
>
>  But yes I think it is a good idea, stripes (& stripernate) makes my
> database so
>  easy to manipulate with a web browser it is kind of scary.
>
>
>
>
>
> -------------------------------------------------------------------------
>  Using Tomcat but need to do more? Need to support web services, security?
>  Get stuff done quickly with pre-integrated technology to make your job
> easier
>  Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  _______________________________________________
>  Stripes-users mailing list
>  [hidden email]
>  https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>  ________________________________
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  ________________________________
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>  ________________________________
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  ________________________________
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>


--
Rémi VANKEISBELCK
[hidden email]
http://www.rvkb.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

paul.barry
One reason I think that we should add this to the Stripes core is that
other java web frameworks don't have it.  AFAIK, Struts, Webwork and
Spring MVC don't have it, not sure about any others.  I'm not sure
every web application needs this, but some will and having it built
right into the framework would be a compelling argument for someone
who needs this and is deciding on a framework.

Also, I assume if you bring it into the stripes framework, you could
do away with the Interceptor, you would just make it part of the
stripes binding process.  If you were to put it into stripes, you
would have to make the default access policy ALLOW, or else you would
lose backward compatibility.  I think a default access policy of DENY
makes sense for an add-on project, because it is explicit what
behavior you are adding.  But for making it part of  stripes, it needs
to be ALLOW.  It should have an init-param to allow you to set the
default policy to DENY.

Also, I would think that making this at the property level makes more
sense than at the class level.  I just read it over briefly, but I
think you would use it like this:

@BindAccess(allow="person**", deny="person.account**")
public class MyActionBean implements ActionBean {

    public Person person;

}

Whereas this seems a lot more natural, inline with @ValidateNestedProperties:

public class MyActionBean implements ActionBean {

    @BindAccess(allow="*", deny="account**")
    public Person person;

}

Although this doesn't happen a lot, imagine an ActionBean with several
properties:

@BindAccess(allow="person**", deny="person.account**",
allow="something.*", allow="somethingElse.*",allow="anotherThing.*")
public class MyActionBean implements ActionBean {

    public Person person;
    public Something something;
    public SomethingElse somethingElse;
    public AnotherThing anotherThing;

}

That looks ugly, this is more clear:

public class MyActionBean implements ActionBean {

    @BindAccess(allow="*", deny="account**")
    public Person person;

    @BindAccess(allow="*")
    public Something something;

    @BindAccess(allow="*")
    public SomethingElse somethingElse;

    @BindAccess(allow="*")
    public AnotherThing anotherThing;

}


On 10/18/06, VANKEISBELCK Remi <[hidden email]> wrote:

> Thanks a lot Ben !
>
> Tim, do you plan to include that (or something similar) in the stripes "core" ?
>
> I definitly think it's a mandatory feature that should be available
> out-of-the box... Property Binding without possible restrictions is
> simply not usable in prod, and those annots look like a really nice
> solution to this problem !
>
> Maybe we (Stripes users) could test Ben's code for some time, in order
> to check possible bugs, and then maybe you could integrate it to
> stripes ??
>
> My $0.02
>
> Have fun,
>
> Rémi
>
> On 10/18/06, Ben Gunter <[hidden email]> wrote:
> >
> >  As promised, version 0.1 of Stripes Extras is now available. You can
> > download it here: http://www.bengunter.com/stripex
> >
> >  All the documentation is in that zip file under doc. There's a guide that
> > explains how to use the access controls. No doubt this document can be
> > improved upon, but it should be good enough to get you going. There's also
> > plenty of info in the Javadocs, which are also included. The source code is
> > in src and the binary build is at build/stripes-extras-0.1.jar.
> >
> >  This code works for me as it is now. If you encounter any problems, let me
> > know. I don't have a bug-tracker. I'll have to gauge interest to determine
> > if that would be a worthwhile effort.
> >
> >  Hope this helps somebody out. As the plural name implies, this is intended
> > to provide multiple enhancements, but right now all it provides is property
> > binding access control.
> >
> >  -Ben
> >
> >  Ben Gunter wrote:
> >  I've already written and am using these access controls. I just haven't
> > posted it for download because I keep getting distracted by stupid stuff. I
> > will make source and binary packages available sometime tonight (US
> > Eastern).
> >
> >  -Ben
> >
> >  Barry Davies wrote:
> >
> >
> > Guh!  I'll look there for the discussion.  One thing, though:  did a clear
> > verdict come out of that discussion?
> >
> >  -BD aka RJ
> >
> >
> > ----- Original Message ----
> >  From: John Newman <[hidden email]>
> >  To: [hidden email]
> >  Sent: Tuesday, October 17, 2006 2:08:49 PM
> >  Subject: Re: [Stripes-users] Some basic field-level security
> >
> >
> > Barry Davies <barry.davies7@...> writes:
> >
> >  >
> >  >
> >  > I've been investigating some security approaches I might use in the event
> > that
> >  they are necessary within the scope of future development using Stripes and
> > one
> >  of the issues for which I thought direct Stripes support would be of broad
> >  benefit was some sort of annotation, potentially a validation annotation,
> > that
> >  lets Stripes know that no binding should be performed for certain
> > properties of
> >  my entities.  In some application circumstances, it could well be the case
> > that
> >  some people who know how to use TamperData and have some knowledge of my
> > entity
> >  properties could coerce a page that isn't supposed to be able to change
> > certain
> >  properties into changing any property, and I'm trying to prevent that as
> >  conveniently as possible.  Does this sound like a good idea to anyone else?
> >  -BD aka
> >  >  RJ
> >
> >  This exact topic came up when stripernate was first released.  If you check
> >  throught the archives there's a pretty good discussion on it.
> >
> >  But yes I think it is a good idea, stripes (& stripernate) makes my
> > database so
> >  easy to manipulate with a web browser it is kind of scary.
> >
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> >  Using Tomcat but need to do more? Need to support web services, security?
> >  Get stuff done quickly with pre-integrated technology to make your job
> > easier
> >  Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >  _______________________________________________
> >  Stripes-users mailing list
> >  [hidden email]
> >  https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >
> >  ________________________________
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >  ________________________________
> >
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >  ________________________________
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >  ________________________________
> >
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> > _______________________________________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >
> >
>
>
> --
> Rémi VANKEISBELCK
> [hidden email]
> http://www.rvkb.com
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Ben Gunter
In reply to this post by VANKEISBELCK Remi
That's exactly what I am hoping for :) I certainly wouldn't mind this project just being an incubator for features that might be merged into the Stripes core at some point.

The docs are now available on the web site: http://www.bengunter.com/files/stripex/0.1/doc/index.html

-Ben

VANKEISBELCK Remi wrote:
Thanks a lot Ben !

Tim, do you plan to include that (or something similar) in the stripes "core" ?

I definitly think it's a mandatory feature that should be available
out-of-the box... Property Binding without possible restrictions is
simply not usable in prod, and those annots look like a really nice
solution to this problem !

Maybe we (Stripes users) could test Ben's code for some time, in order
to check possible bugs, and then maybe you could integrate it to
stripes ??

My $0.02

Have fun,

Rémi

On 10/18/06, Ben Gunter [hidden email] wrote:
  
 As promised, version 0.1 of Stripes Extras is now available. You can
download it here: http://www.bengunter.com/stripex

 All the documentation is in that zip file under doc. There's a guide that
explains how to use the access controls. No doubt this document can be
improved upon, but it should be good enough to get you going. There's also
plenty of info in the Javadocs, which are also included. The source code is
in src and the binary build is at build/stripes-extras-0.1.jar.

 This code works for me as it is now. If you encounter any problems, let me
know. I don't have a bug-tracker. I'll have to gauge interest to determine
if that would be a worthwhile effort.

 Hope this helps somebody out. As the plural name implies, this is intended
to provide multiple enhancements, but right now all it provides is property
binding access control.

 -Ben

 Ben Gunter wrote:
 I've already written and am using these access controls. I just haven't
posted it for download because I keep getting distracted by stupid stuff. I
will make source and binary packages available sometime tonight (US
Eastern).

 -Ben

 Barry Davies wrote:


Guh!  I'll look there for the discussion.  One thing, though:  did a clear
verdict come out of that discussion?

 -BD aka RJ


----- Original Message ----
 From: John Newman [hidden email]
 To: [hidden email]
 Sent: Tuesday, October 17, 2006 2:08:49 PM
 Subject: Re: [Stripes-users] Some basic field-level security


Barry Davies [hidden email] writes:

 >
 >
 > I've been investigating some security approaches I might use in the event
that
 they are necessary within the scope of future development using Stripes and
one
 of the issues for which I thought direct Stripes support would be of broad
 benefit was some sort of annotation, potentially a validation annotation,
that
 lets Stripes know that no binding should be performed for certain
properties of
 my entities.  In some application circumstances, it could well be the case
that
 some people who know how to use TamperData and have some knowledge of my
entity
 properties could coerce a page that isn't supposed to be able to change
certain
 properties into changing any property, and I'm trying to prevent that as
 conveniently as possible.  Does this sound like a good idea to anyone else?
 -BD aka
 >  RJ

 This exact topic came up when stripernate was first released.  If you check
 throught the archives there's a pretty good discussion on it.

 But yes I think it is a good idea, stripes (& stripernate) makes my
database so
 easy to manipulate with a web browser it is kind of scary.





-------------------------------------------------------------------------
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job
easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 _______________________________________________
 Stripes-users mailing list
 [hidden email]
 https://lists.sourceforge.net/lists/listinfo/stripes-users


 ________________________________

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 ________________________________

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users

 ________________________________

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 ________________________________

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



    


  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Tim Fennell-3
In reply to this post by VANKEISBELCK Remi
Assuming that Ben is cool with it, I'd be more than happy to move  
this into the core of Stripes once it has been in use by several  
projects for a while.  My main concern is simply that because I have  
no use for this (that's not a swipe at it, what I'm working on these  
days is a set of internal apps for a small number of trusted users)  
I'm not in a good position to test it out and see what some of the  
more bizarre use cases for it might be.

That said, looking at Ben's implementation, it looks pretty slick :)  
The only thing I think I'd like to see, but I'll await others  
feedback, is the ability to put @BindAccess onto properties directly,  
e.g.:
     @BindAccess(deny="*") private Foo mySpringBean;

But then you end up with having to create precedence rules etc. so  
maybe it's not such a good idea?

Incidentally, I'm thinking about adding the following to  
ActionBeanContext for 1.5:
     Map<String,String[]> getParameters();
     void setParameters(Map<String,String[]> params);

The reason being that it would make it easier for things like stripes  
extras to modify the set of parameters without having to implement a  
request wrapper. (It'll also make the friendly URL stuff easier).  
Thoughts?

-t

On Oct 18, 2006, at 5:30 AM, VANKEISBELCK Remi wrote:

> Thanks a lot Ben !
>
> Tim, do you plan to include that (or something similar) in the  
> stripes "core" ?
>
> I definitly think it's a mandatory feature that should be available
> out-of-the box... Property Binding without possible restrictions is
> simply not usable in prod, and those annots look like a really nice
> solution to this problem !
>
> Maybe we (Stripes users) could test Ben's code for some time, in order
> to check possible bugs, and then maybe you could integrate it to
> stripes ??
>
> My $0.02
>
> Have fun,
>
> Rémi
>
> On 10/18/06, Ben Gunter <[hidden email]> wrote:
>>
>>  As promised, version 0.1 of Stripes Extras is now available. You can
>> download it here: http://www.bengunter.com/stripex
>>
>>  All the documentation is in that zip file under doc. There's a  
>> guide that
>> explains how to use the access controls. No doubt this document  
>> can be
>> improved upon, but it should be good enough to get you going.  
>> There's also
>> plenty of info in the Javadocs, which are also included. The  
>> source code is
>> in src and the binary build is at build/stripes-extras-0.1.jar.
>>
>>  This code works for me as it is now. If you encounter any  
>> problems, let me
>> know. I don't have a bug-tracker. I'll have to gauge interest to  
>> determine
>> if that would be a worthwhile effort.
>>
>>  Hope this helps somebody out. As the plural name implies, this is  
>> intended
>> to provide multiple enhancements, but right now all it provides is  
>> property
>> binding access control.
>>
>>  -Ben
>>
>>  Ben Gunter wrote:
>>  I've already written and am using these access controls. I just  
>> haven't
>> posted it for download because I keep getting distracted by stupid  
>> stuff. I
>> will make source and binary packages available sometime tonight (US
>> Eastern).
>>
>>  -Ben
>>
>>  Barry Davies wrote:
>>
>>
>> Guh!  I'll look there for the discussion.  One thing, though:  did  
>> a clear
>> verdict come out of that discussion?
>>
>>  -BD aka RJ
>>
>>
>> ----- Original Message ----
>>  From: John Newman <[hidden email]>
>>  To: [hidden email]
>>  Sent: Tuesday, October 17, 2006 2:08:49 PM
>>  Subject: Re: [Stripes-users] Some basic field-level security
>>
>>
>> Barry Davies <barry.davies7@...> writes:
>>
>>>
>>>
>>> I've been investigating some security approaches I might use in  
>>> the event
>> that
>>  they are necessary within the scope of future development using  
>> Stripes and
>> one
>>  of the issues for which I thought direct Stripes support would be  
>> of broad
>>  benefit was some sort of annotation, potentially a validation  
>> annotation,
>> that
>>  lets Stripes know that no binding should be performed for certain
>> properties of
>>  my entities.  In some application circumstances, it could well be  
>> the case
>> that
>>  some people who know how to use TamperData and have some  
>> knowledge of my
>> entity
>>  properties could coerce a page that isn't supposed to be able to  
>> change
>> certain
>>  properties into changing any property, and I'm trying to prevent  
>> that as
>>  conveniently as possible.  Does this sound like a good idea to  
>> anyone else?
>>  -BD aka
>>>  RJ
>>
>>  This exact topic came up when stripernate was first released.  If  
>> you check
>>  throught the archives there's a pretty good discussion on it.
>>
>>  But yes I think it is a good idea, stripes (& stripernate) makes my
>> database so
>>  easy to manipulate with a web browser it is kind of scary.
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> ----
>>  Using Tomcat but need to do more? Need to support web services,  
>> security?
>>  Get stuff done quickly with pre-integrated technology to make  
>> your job
>> easier
>>  Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>  _______________________________________________
>>  Stripes-users mailing list
>>  [hidden email]
>>  https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>>  ________________________________
>>
>> ---------------------------------------------------------------------
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>  ________________________________
>>
>> _______________________________________________
>> Stripes-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>  ________________________________
>>
>> ---------------------------------------------------------------------
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>  ________________________________
>>
>> _______________________________________________
>> Stripes-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>> ---------------------------------------------------------------------
>> ----
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>>
>> _______________________________________________
>> Stripes-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>
>>
>>
>
>
> --
> Rémi VANKEISBELCK
> [hidden email]
> http://www.rvkb.com
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Ben Gunter
In reply to this post by paul.barry
Paul Barry wrote:

> One reason I think that we should add this to the Stripes core is that
> other java web frameworks don't have it.  AFAIK, Struts, Webwork and
> Spring MVC don't have it, not sure about any others.  I'm not sure
> every web application needs this, but some will and having it built
> right into the framework would be a compelling argument for someone
> who needs this and is deciding on a framework.
>
> Also, I assume if you bring it into the stripes framework, you could
> do away with the Interceptor, you would just make it part of the
> stripes binding process.  If you were to put it into stripes, you
> would have to make the default access policy ALLOW, or else you would
> lose backward compatibility.  I think a default access policy of DENY
> makes sense for an add-on project, because it is explicit what
> behavior you are adding.  But for making it part of  stripes, it needs
> to be ALLOW.  It should have an init-param to allow you to set the
> default policy to DENY.
>  
I respectfully disagree with this statement. If the default policy is to
allow binding to anything, then it is left up to the developer to make
sure everything is locked down. But if access is denied by default, then
everything is protected unless you explicitly allow binding (through
@Validate or @BindAccess). Here's an example of why you want to deny by
default:

Type Person has property address of type Address and property
privateStuff of type String.
Type Address has property person, pointing back to the Person object
that owns it.
MyActionBean exposes a person property of type Person so that only the
address can be updated.

Say MyActionBean is annotated with @BindAccess(allow="person.address.*",
deny="person.*"). You might think in this case that person.privateStuff
would be protected, but it's not. Someone could post a request parameter
like person.address.person.privateStuff and write into that property.
The only way to address that would be to do
@BindAccess(allow="person.address.*", deny="**") or
@BindAccess(policy=DENY, allow="address.*"). But you would have to do
that for *every* ActionBean, and in doing so you are essentially making
the default policy DENY anyway. It's just a lot easier and safer for the
policy to be DENY.

There's another compelling reason, too. The access controls allow
binding to any property annotated with @Validate, which means you don't
even have to use any special-purpose annotations to control what can and
can't be bound. By setting the default policy to ALLOW, you are forcing
every ActionBean that needs protection to have @BindAccess attached to
it. I prefer to stick with the Stripes core annotations if possible.

Having said that, it's really simple to set the default policy to ALLOW
by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it would be
just as easy to set it to DENY if things were reversed. But I'm of the
opinion that unrestricted property binding is a bad thing, and I don't
want that kind of backward compatibility. Call me crazy.

> Also, I would think that making this at the property level makes more
> sense than at the class level.  I just read it over briefly, but I
> think you would use it like this:
>
> @BindAccess(allow="person**", deny="person.account**")
> public class MyActionBean implements ActionBean {
>
>     public Person person;
>
> }
>
> Whereas this seems a lot more natural, inline with @ValidateNestedProperties:
>
> public class MyActionBean implements ActionBean {
>
>     @BindAccess(allow="*", deny="account**")
>     public Person person;
>
> }
>  
This was mentioned when this topic first arose. I have no problem with
it, just haven't gotten around to doing it yet. This will probably be
available in a future release. But remember that if you do want this
type of behavior, it's probably better to use @Validate on the property
for two reasons: (1) most of the time you will have @Validate for the
property anyway and (2) it's safer to use explicit property names than
globs. This does work for nested properties in @ValidateNestedProperties
as well.

> Although this doesn't happen a lot, imagine an ActionBean with several
> properties:
>
> @BindAccess(allow="person**", deny="person.account**",
> allow="something.*", allow="somethingElse.*",allow="anotherThing.*")
> public class MyActionBean implements ActionBean {
>
>     public Person person;
>     public Something something;
>     public SomethingElse somethingElse;
>     public AnotherThing anotherThing;
>
> }
>
> That looks ugly, this is more clear:
>
> public class MyActionBean implements ActionBean {
>
>     @BindAccess(allow="*", deny="account**")
>     public Person person;
>
>     @BindAccess(allow="*")
>     public Something something;
>
>     @BindAccess(allow="*")
>     public SomethingElse somethingElse;
>
>     @BindAccess(allow="*")
>     public AnotherThing anotherThing;
>
> }
>  
Actually it would be more like this:

@BindAccess(allow="person**, something.*, somethingElse.*, anotherThing.*", deny="person.account**")

But your point is taken.

-Ben

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Ben Gunter
After writing all that, I've thought some more on it and decided you're right after all. If this were to be merged into the Stripes core, it would become a new feature that could be enabled on a per-class basis with @BindAccess( policy = DENY ) or enabled globally with BindAccess.DefaultPolicy = DENY. I guess I was more focused on what's more secure than what's the best behavior for the framework. It will be much easier for people to get their first Stripes app going and get hooked on it if they don't have to worry about security constraints from the get-go. In short: my bad :)

But for now, since it's in Stripes Extras and not Stripes itself, a default deny policy makes sense because if you didn't want the access protection you wouldn't have included the interceptor. And you can still change the default policy even so.

-Ben

Ben Gunter wrote:
Paul Barry wrote:
  
One reason I think that we should add this to the Stripes core is that
other java web frameworks don't have it.  AFAIK, Struts, Webwork and
Spring MVC don't have it, not sure about any others.  I'm not sure
every web application needs this, but some will and having it built
right into the framework would be a compelling argument for someone
who needs this and is deciding on a framework.

Also, I assume if you bring it into the stripes framework, you could
do away with the Interceptor, you would just make it part of the
stripes binding process.  If you were to put it into stripes, you
would have to make the default access policy ALLOW, or else you would
lose backward compatibility.  I think a default access policy of DENY
makes sense for an add-on project, because it is explicit what
behavior you are adding.  But for making it part of  stripes, it needs
to be ALLOW.  It should have an init-param to allow you to set the
default policy to DENY.
  
    
I respectfully disagree with this statement. If the default policy is to 
allow binding to anything, then it is left up to the developer to make 
sure everything is locked down. But if access is denied by default, then 
everything is protected unless you explicitly allow binding (through 
@Validate or @BindAccess). Here's an example of why you want to deny by 
default:

Type Person has property address of type Address and property 
privateStuff of type String.
Type Address has property person, pointing back to the Person object 
that owns it.
MyActionBean exposes a person property of type Person so that only the 
address can be updated.

Say MyActionBean is annotated with @BindAccess(allow="person.address.*", 
deny="person.*"). You might think in this case that person.privateStuff 
would be protected, but it's not. Someone could post a request parameter 
like person.address.person.privateStuff and write into that property. 
The only way to address that would be to do 
@BindAccess(allow="person.address.*", deny="**") or 
@BindAccess(policy=DENY, allow="address.*"). But you would have to do 
that for *every* ActionBean, and in doing so you are essentially making 
the default policy DENY anyway. It's just a lot easier and safer for the 
policy to be DENY.

There's another compelling reason, too. The access controls allow 
binding to any property annotated with @Validate, which means you don't 
even have to use any special-purpose annotations to control what can and 
can't be bound. By setting the default policy to ALLOW, you are forcing 
every ActionBean that needs protection to have @BindAccess attached to 
it. I prefer to stick with the Stripes core annotations if possible.

Having said that, it's really simple to set the default policy to ALLOW 
by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it would be 
just as easy to set it to DENY if things were reversed. But I'm of the 
opinion that unrestricted property binding is a bad thing, and I don't 
want that kind of backward compatibility. Call me crazy.
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

paul.barry
Yeah, I agree with both of those points.

On 10/18/06, Ben Gunter <[hidden email]> wrote:

>
>  After writing all that, I've thought some more on it and decided you're
> right after all. If this were to be merged into the Stripes core, it would
> become a new feature that could be enabled on a per-class basis with
> @BindAccess( policy = DENY ) or enabled globally with
> BindAccess.DefaultPolicy = DENY. I guess I was more focused on what's more
> secure than what's the best behavior for the framework. It will be much
> easier for people to get their first Stripes app going and get hooked on it
> if they don't have to worry about security constraints from the get-go. In
> short: my bad :)
>
>  But for now, since it's in Stripes Extras and not Stripes itself, a default
> deny policy makes sense because if you didn't want the access protection you
> wouldn't have included the interceptor. And you can still change the default
> policy even so.
>
>  -Ben
>
>  Ben Gunter wrote:
>  Paul Barry wrote:
>
>
>  One reason I think that we should add this to the Stripes core is that
> other java web frameworks don't have it. AFAIK, Struts, Webwork and
> Spring MVC don't have it, not sure about any others. I'm not sure
> every web application needs this, but some will and having it built
> right into the framework would be a compelling argument for someone
> who needs this and is deciding on a framework.
>
> Also, I assume if you bring it into the stripes framework, you could
> do away with the Interceptor, you would just make it part of the
> stripes binding process. If you were to put it into stripes, you
> would have to make the default access policy ALLOW, or else you would
> lose backward compatibility. I think a default access policy of DENY
> makes sense for an add-on project, because it is explicit what
> behavior you are adding. But for making it part of stripes, it needs
> to be ALLOW. It should have an init-param to allow you to set the
> default policy to DENY.
>
>
>  I respectfully disagree with this statement. If the default policy is to
> allow binding to anything, then it is left up to the developer to make
> sure everything is locked down. But if access is denied by default, then
> everything is protected unless you explicitly allow binding (through
> @Validate or @BindAccess). Here's an example of why you want to deny by
> default:
>
> Type Person has property address of type Address and property
> privateStuff of type String.
> Type Address has property person, pointing back to the Person object
> that owns it.
> MyActionBean exposes a person property of type Person so that only the
> address can be updated.
>
> Say MyActionBean is annotated with @BindAccess(allow="person.address.*",
> deny="person.*"). You might think in this case that person.privateStuff
> would be protected, but it's not. Someone could post a request parameter
> like person.address.person.privateStuff and write into that
> property.
> The only way to address that would be to do
> @BindAccess(allow="person.address.*", deny="**") or
> @BindAccess(policy=DENY, allow="address.*"). But you would have to do
> that for *every* ActionBean, and in doing so you are essentially making
> the default policy DENY anyway. It's just a lot easier and safer for the
> policy to be DENY.
>
> There's another compelling reason, too. The access controls allow
> binding to any property annotated with @Validate, which means you don't
> even have to use any special-purpose annotations to control what can and
> can't be bound. By setting the default policy to ALLOW, you are forcing
> every ActionBean that needs protection to have @BindAccess attached to
> it. I prefer to stick with the Stripes core annotations if possible.
>
> Having said that, it's really simple to set the default policy to ALLOW
> by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it would be
> just as easy to set it to DENY if things were reversed. But I'm of the
> opinion that unrestricted property binding is a bad thing, and I don't
> want that kind of backward compatibility. Call me crazy.
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Tim Fennell-3
In reply to this post by Ben Gunter
If/when merging into the core you could even go with a slightly more  
dynamic default policy of "if @BindAccess is present, default is  
deny, otherwise default is allow".  That way as soon as you try to  
start securing a bean, you flip to the strict policy, and are  
backwards compatible elsewhere....

-t

On Oct 18, 2006, at 8:52 AM, Ben Gunter wrote:

> After writing all that, I've thought some more on it and decided  
> you're right after all. If this were to be merged into the Stripes  
> core, it would become a new feature that could be enabled on a per-
> class basis with @BindAccess( policy = DENY ) or enabled globally  
> with BindAccess.DefaultPolicy = DENY. I guess I was more focused on  
> what's more secure than what's the best behavior for the framework.  
> It will be much easier for people to get their first Stripes app  
> going and get hooked on it if they don't have to worry about  
> security constraints from the get-go. In short: my bad :)
>
> But for now, since it's in Stripes Extras and not Stripes itself, a  
> default deny policy makes sense because if you didn't want the  
> access protection you wouldn't have included the interceptor. And  
> you can still change the default policy even so.
>
> -Ben
>
> Ben Gunter wrote:
>> Paul Barry wrote:
>>
>>> One reason I think that we should add this to the Stripes core is  
>>> that
>>> other java web frameworks don't have it.  AFAIK, Struts, Webwork and
>>> Spring MVC don't have it, not sure about any others.  I'm not sure
>>> every web application needs this, but some will and having it built
>>> right into the framework would be a compelling argument for someone
>>> who needs this and is deciding on a framework.
>>>
>>> Also, I assume if you bring it into the stripes framework, you could
>>> do away with the Interceptor, you would just make it part of the
>>> stripes binding process.  If you were to put it into stripes, you
>>> would have to make the default access policy ALLOW, or else you  
>>> would
>>> lose backward compatibility.  I think a default access policy of  
>>> DENY
>>> makes sense for an add-on project, because it is explicit what
>>> behavior you are adding.  But for making it part of  stripes, it  
>>> needs
>>> to be ALLOW.  It should have an init-param to allow you to set the
>>> default policy to DENY.
>>>
>>>
>> I respectfully disagree with this statement. If the default policy  
>> is to
>> allow binding to anything, then it is left up to the developer to  
>> make
>> sure everything is locked down. But if access is denied by  
>> default, then
>> everything is protected unless you explicitly allow binding (through
>> @Validate or @BindAccess). Here's an example of why you want to  
>> deny by
>> default:
>>
>> Type Person has property address of type Address and property
>> privateStuff of type String.
>> Type Address has property person, pointing back to the Person object
>> that owns it.
>> MyActionBean exposes a person property of type Person so that only  
>> the
>> address can be updated.
>>
>> Say MyActionBean is annotated with @BindAccess
>> (allow="person.address.*",
>> deny="person.*"). You might think in this case that  
>> person.privateStuff
>> would be protected, but it's not. Someone could post a request  
>> parameter
>> like person.address.person.privateStuff and write into that property.
>> The only way to address that would be to do
>> @BindAccess(allow="person.address.*", deny="**") or
>> @BindAccess(policy=DENY, allow="address.*"). But you would have to do
>> that for *every* ActionBean, and in doing so you are essentially  
>> making
>> the default policy DENY anyway. It's just a lot easier and safer  
>> for the
>> policy to be DENY.
>>
>> There's another compelling reason, too. The access controls allow
>> binding to any property annotated with @Validate, which means you  
>> don't
>> even have to use any special-purpose annotations to control what  
>> can and
>> can't be bound. By setting the default policy to ALLOW, you are  
>> forcing
>> every ActionBean that needs protection to have @BindAccess  
>> attached to
>> it. I prefer to stick with the Stripes core annotations if possible.
>>
>> Having said that, it's really simple to set the default policy to  
>> ALLOW
>> by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it  
>> would be
>> just as easy to set it to DENY if things were reversed. But I'm of  
>> the
>> opinion that unrestricted property binding is a bad thing, and I  
>> don't
>> want that kind of backward compatibility. Call me crazy.
>>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
> _________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

paul.barry
So I guess it's up to Tim whether or not something like this gets
added to the core.  How do we go about this?  Create a JIRA issue
requesting that it be added to the core?  Then, if someone were to
create a patch that makes it part of the core, would it be accepted?

On 10/18/06, Tim Fennell <[hidden email]> wrote:

> If/when merging into the core you could even go with a slightly more
> dynamic default policy of "if @BindAccess is present, default is
> deny, otherwise default is allow".  That way as soon as you try to
> start securing a bean, you flip to the strict policy, and are
> backwards compatible elsewhere....
>
> -t
>
> On Oct 18, 2006, at 8:52 AM, Ben Gunter wrote:
>
> > After writing all that, I've thought some more on it and decided
> > you're right after all. If this were to be merged into the Stripes
> > core, it would become a new feature that could be enabled on a per-
> > class basis with @BindAccess( policy = DENY ) or enabled globally
> > with BindAccess.DefaultPolicy = DENY. I guess I was more focused on
> > what's more secure than what's the best behavior for the framework.
> > It will be much easier for people to get their first Stripes app
> > going and get hooked on it if they don't have to worry about
> > security constraints from the get-go. In short: my bad :)
> >
> > But for now, since it's in Stripes Extras and not Stripes itself, a
> > default deny policy makes sense because if you didn't want the
> > access protection you wouldn't have included the interceptor. And
> > you can still change the default policy even so.
> >
> > -Ben
> >
> > Ben Gunter wrote:
> >> Paul Barry wrote:
> >>
> >>> One reason I think that we should add this to the Stripes core is
> >>> that
> >>> other java web frameworks don't have it.  AFAIK, Struts, Webwork and
> >>> Spring MVC don't have it, not sure about any others.  I'm not sure
> >>> every web application needs this, but some will and having it built
> >>> right into the framework would be a compelling argument for someone
> >>> who needs this and is deciding on a framework.
> >>>
> >>> Also, I assume if you bring it into the stripes framework, you could
> >>> do away with the Interceptor, you would just make it part of the
> >>> stripes binding process.  If you were to put it into stripes, you
> >>> would have to make the default access policy ALLOW, or else you
> >>> would
> >>> lose backward compatibility.  I think a default access policy of
> >>> DENY
> >>> makes sense for an add-on project, because it is explicit what
> >>> behavior you are adding.  But for making it part of  stripes, it
> >>> needs
> >>> to be ALLOW.  It should have an init-param to allow you to set the
> >>> default policy to DENY.
> >>>
> >>>
> >> I respectfully disagree with this statement. If the default policy
> >> is to
> >> allow binding to anything, then it is left up to the developer to
> >> make
> >> sure everything is locked down. But if access is denied by
> >> default, then
> >> everything is protected unless you explicitly allow binding (through
> >> @Validate or @BindAccess). Here's an example of why you want to
> >> deny by
> >> default:
> >>
> >> Type Person has property address of type Address and property
> >> privateStuff of type String.
> >> Type Address has property person, pointing back to the Person object
> >> that owns it.
> >> MyActionBean exposes a person property of type Person so that only
> >> the
> >> address can be updated.
> >>
> >> Say MyActionBean is annotated with @BindAccess
> >> (allow="person.address.*",
> >> deny="person.*"). You might think in this case that
> >> person.privateStuff
> >> would be protected, but it's not. Someone could post a request
> >> parameter
> >> like person.address.person.privateStuff and write into that property.
> >> The only way to address that would be to do
> >> @BindAccess(allow="person.address.*", deny="**") or
> >> @BindAccess(policy=DENY, allow="address.*"). But you would have to do
> >> that for *every* ActionBean, and in doing so you are essentially
> >> making
> >> the default policy DENY anyway. It's just a lot easier and safer
> >> for the
> >> policy to be DENY.
> >>
> >> There's another compelling reason, too. The access controls allow
> >> binding to any property annotated with @Validate, which means you
> >> don't
> >> even have to use any special-purpose annotations to control what
> >> can and
> >> can't be bound. By setting the default policy to ALLOW, you are
> >> forcing
> >> every ActionBean that needs protection to have @BindAccess
> >> attached to
> >> it. I prefer to stick with the Stripes core annotations if possible.
> >>
> >> Having said that, it's really simple to set the default policy to
> >> ALLOW
> >> by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it
> >> would be
> >> just as easy to set it to DENY if things were reversed. But I'm of
> >> the
> >> opinion that unrestricted property binding is a bad thing, and I
> >> don't
> >> want that kind of backward compatibility. Call me crazy.
> >>
> > ----------------------------------------------------------------------
> > ---
> > Using Tomcat but need to do more? Need to support web services,
> > security?
> > Get stuff done quickly with pre-integrated technology to make your
> > job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?
> > cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
> > _________________
> > Stripes-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Ben Gunter
In reply to this post by Tim Fennell-3
Now that I think about it, it already works that way. The default value for "policy" is DENY so you don't have to explicitly set it. The mere presence of @BindAccess would prevent binding.

One drawback is that if you're reading the source code for an ActionBean, an empty @BindAccess annotation doesn't clearly indicate what effect it will have. Like @DontValidate means "don't validate" and @DefaultHandler means "default handler." I originally named the annotation @BindAccess because it was intended to describe the "binding access" rules. But if it can also be used as a simple marker, then perhaps there is a better name. Any suggestions? Maybe @StrictBinding?

-Ben

Tim Fennell wrote:
If/when merging into the core you could even go with a slightly more  
dynamic default policy of "if @BindAccess is present, default is  
deny, otherwise default is allow".  That way as soon as you try to  
start securing a bean, you flip to the strict policy, and are  
backwards compatible elsewhere....

-t

On Oct 18, 2006, at 8:52 AM, Ben Gunter wrote:

  
After writing all that, I've thought some more on it and decided  
you're right after all. If this were to be merged into the Stripes  
core, it would become a new feature that could be enabled on a per- 
class basis with @BindAccess( policy = DENY ) or enabled globally  
with BindAccess.DefaultPolicy = DENY. I guess I was more focused on  
what's more secure than what's the best behavior for the framework.  
It will be much easier for people to get their first Stripes app  
going and get hooked on it if they don't have to worry about  
security constraints from the get-go. In short: my bad :)

But for now, since it's in Stripes Extras and not Stripes itself, a  
default deny policy makes sense because if you didn't want the  
access protection you wouldn't have included the interceptor. And  
you can still change the default policy even so.

-Ben

Ben Gunter wrote:
    
Paul Barry wrote:

      
One reason I think that we should add this to the Stripes core is  
that
other java web frameworks don't have it.  AFAIK, Struts, Webwork and
Spring MVC don't have it, not sure about any others.  I'm not sure
every web application needs this, but some will and having it built
right into the framework would be a compelling argument for someone
who needs this and is deciding on a framework.

Also, I assume if you bring it into the stripes framework, you could
do away with the Interceptor, you would just make it part of the
stripes binding process.  If you were to put it into stripes, you
would have to make the default access policy ALLOW, or else you  
would
lose backward compatibility.  I think a default access policy of  
DENY
makes sense for an add-on project, because it is explicit what
behavior you are adding.  But for making it part of  stripes, it  
needs
to be ALLOW.  It should have an init-param to allow you to set the
default policy to DENY.


        
I respectfully disagree with this statement. If the default policy  
is to
allow binding to anything, then it is left up to the developer to  
make
sure everything is locked down. But if access is denied by  
default, then
everything is protected unless you explicitly allow binding (through
@Validate or @BindAccess). Here's an example of why you want to  
deny by
default:

Type Person has property address of type Address and property
privateStuff of type String.
Type Address has property person, pointing back to the Person object
that owns it.
MyActionBean exposes a person property of type Person so that only  
the
address can be updated.

Say MyActionBean is annotated with @BindAccess 
(allow="person.address.*",
deny="person.*"). You might think in this case that  
person.privateStuff
would be protected, but it's not. Someone could post a request  
parameter
like person.address.person.privateStuff and write into that property.
The only way to address that would be to do
@BindAccess(allow="person.address.*", deny="**") or
@BindAccess(policy=DENY, allow="address.*"). But you would have to do
that for *every* ActionBean, and in doing so you are essentially  
making
the default policy DENY anyway. It's just a lot easier and safer  
for the
policy to be DENY.

There's another compelling reason, too. The access controls allow
binding to any property annotated with @Validate, which means you  
don't
even have to use any special-purpose annotations to control what  
can and
can't be bound. By setting the default policy to ALLOW, you are  
forcing
every ActionBean that needs protection to have @BindAccess  
attached to
it. I prefer to stick with the Stripes core annotations if possible.

Having said that, it's really simple to set the default policy to  
ALLOW
by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it  
would be
just as easy to set it to DENY if things were reversed. But I'm of  
the
opinion that unrestricted property binding is a bad thing, and I  
don't
want that kind of backward compatibility. Call me crazy.

      
---------------------------------------------------------------------- 
---
Using Tomcat but need to do more? Need to support web services,  
security?
Get stuff done quickly with pre-integrated technology to make your  
job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache  
Geronimo
http://sel.as-us.falkag.net/sel? 
cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ 
_________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
    


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
  

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Gary Moselen
In reply to this post by Barry Davies
Tim Fennell wrote:

>...
>
>That said, looking at Ben's implementation, it looks pretty slick :)  
>The only thing I think I'd like to see, but I'll await others  
>feedback, is the ability to put @BindAccess onto properties directly,  
>e.g.:
>     @BindAccess(deny="*") private Foo mySpringBean;
>
>But then you end up with having to create precedence rules etc. so  
>maybe it's not such a good idea?
>
>...
>
I would also be interested in putting @BindAccess on my model
objects/properties directly. I have rich domain model objects with heaps
of annotations and it would make sense to define @BindAccess on the
model objects themselves. So if the default policy was DENY then I would
go ahead and annotate my model objects with ALLOW access for the
properties that were editable from web forms.

class User {

    private Account account;

    @BindAccess(allow="*")
    private Address address;

}

@BindAccess(deny = "*")
class Account {
    //...
}

So the precedence would first check if there was a BindAccess on the
property itself, then the bean class, then the ActionBean property, then
the ActionBean class.

The benefit of doing it this way is that I can secure the model objects
themselves so when they are exposed in multiple ActionBeans I don't have
to repeat the BindAccess expressions.

Gary

>
>-t
>
>On Oct 18, 2006, at 5:30 AM, VANKEISBELCK Remi wrote:
>
>  
>
>>Thanks a lot Ben !
>>
>>Tim, do you plan to include that (or something similar) in the  
>>stripes "core" ?
>>
>>I definitly think it's a mandatory feature that should be available
>>out-of-the box... Property Binding without possible restrictions is
>>simply not usable in prod, and those annots look like a really nice
>>solution to this problem !
>>
>>Maybe we (Stripes users) could test Ben's code for some time, in order
>>to check possible bugs, and then maybe you could integrate it to
>>stripes ??
>>
>>My $0.02
>>
>>Have fun,
>>
>>R mi
>>
>>On 10/18/06, Ben Gunter <[hidden email]> wrote:
>>    
>>
>>> As promised, version 0.1 of Stripes Extras is now available. You can
>>>download it here: http://www.bengunter.com/stripex
>>>
>>> All the documentation is in that zip file under doc. There's a  
>>>guide that
>>>explains how to use the access controls. No doubt this document  
>>>can be
>>>improved upon, but it should be good enough to get you going.  
>>>There's also
>>>plenty of info in the Javadocs, which are also included. The  
>>>source code is
>>>in src and the binary build is at build/stripes-extras-0.1.jar.
>>>
>>> This code works for me as it is now. If you encounter any  
>>>problems, let me
>>>know. I don't have a bug-tracker. I'll have to gauge interest to  
>>>determine
>>>if that would be a worthwhile effort.
>>>
>>> Hope this helps somebody out. As the plural name implies, this is  
>>>intended
>>>to provide multiple enhancements, but right now all it provides is  
>>>property
>>>binding access control.
>>>
>>> -Ben
>>>
>>> Ben Gunter wrote:
>>> I've already written and am using these access controls. I just  
>>>haven't
>>>posted it for download because I keep getting distracted by stupid  
>>>stuff. I
>>>will make source and binary packages available sometime tonight (US
>>>Eastern).
>>>
>>> -Ben
>>>
>>> Barry Davies wrote:
>>>
>>>
>>>Guh!  I'll look there for the discussion.  One thing, though:  did  
>>>a clear
>>>verdict come out of that discussion?
>>>
>>> -BD aka RJ
>>>
>>>
>>>----- Original Message ----
>>> From: John Newman <[hidden email]>
>>> To: [hidden email]
>>> Sent: Tuesday, October 17, 2006 2:08:49 PM
>>> Subject: Re: [Stripes-users] Some basic field-level security
>>>
>>>
>>>Barry Davies <barry.davies7@...> writes:
>>>
>>>      
>>>
>>>>I've been investigating some security approaches I might use in  
>>>>the event
>>>>        
>>>>
>>>that
>>> they are necessary within the scope of future development using  
>>>Stripes and
>>>one
>>> of the issues for which I thought direct Stripes support would be  
>>>of broad
>>> benefit was some sort of annotation, potentially a validation  
>>>annotation,
>>>that
>>> lets Stripes know that no binding should be performed for certain
>>>properties of
>>> my entities.  In some application circumstances, it could well be  
>>>the case
>>>that
>>> some people who know how to use TamperData and have some  
>>>knowledge of my
>>>entity
>>> properties could coerce a page that isn't supposed to be able to  
>>>change
>>>certain
>>> properties into changing any property, and I'm trying to prevent  
>>>that as
>>> conveniently as possible.  Does this sound like a good idea to  
>>>anyone else?
>>> -BD aka
>>>      
>>>
>>>> RJ
>>>>        
>>>>
>>> This exact topic came up when stripernate was first released.  If  
>>>you check
>>> throught the archives there's a pretty good discussion on it.
>>>
>>> But yes I think it is a good idea, stripes (& stripernate) makes my
>>>database so
>>> easy to manipulate with a web browser it is kind of scary.
>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>----
>>> Using Tomcat but need to do more? Need to support web services,  
>>>security?
>>> Get stuff done quickly with pre-integrated technology to make  
>>>your job
>>>easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>>>Geronimo
>>>http://sel.as-us.falkag.net/sel?
>>>cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> Stripes-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>> ________________________________
>>>
>>>---------------------------------------------------------------------
>>>----
>>>Using Tomcat but need to do more? Need to support web services,  
>>>security?
>>>Get stuff done quickly with pre-integrated technology to make your  
>>>job
>>>easier
>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>>>Geronimo
>>>http://sel.as-us.falkag.net/sel?
>>>cmd=lnk&kid=120709&bid=263057&dat=121642
>>> ________________________________
>>>
>>>_______________________________________________
>>>Stripes-users mailing list
>>>[hidden email]
>>>https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>> ________________________________
>>>
>>>---------------------------------------------------------------------
>>>----
>>>Using Tomcat but need to do more? Need to support web services,  
>>>security?
>>>Get stuff done quickly with pre-integrated technology to make your  
>>>job
>>>easier
>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>>>Geronimo
>>>http://sel.as-us.falkag.net/sel?
>>>cmd=lnk&kid=120709&bid=263057&dat=121642
>>> ________________________________
>>>
>>>_______________________________________________
>>>Stripes-users mailing list
>>>[hidden email]
>>>https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>>---------------------------------------------------------------------
>>>----
>>>Using Tomcat but need to do more? Need to support web services,  
>>>security?
>>>Get stuff done quickly with pre-integrated technology to make your  
>>>job
>>>easier
>>>Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>>>Geronimo
>>>http://sel.as-us.falkag.net/sel?
>>>cmd=lnk&kid=120709&bid=263057&dat=121642
>>>
>>>_______________________________________________
>>>Stripes-users mailing list
>>>[hidden email]
>>>https://lists.sourceforge.net/lists/listinfo/stripes-users
>>>
>>>
>>>
>>>      
>>>
>>--
>>R mi VANKEISBELCK
>>[hidden email]
>>http://www.rvkb.com
>>
>>----------------------------------------------------------------------
>>---
>>Using Tomcat but need to do more? Need to support web services,  
>>security?
>>Get stuff done quickly with pre-integrated technology to make your  
>>job easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>>Geronimo
>>http://sel.as-us.falkag.net/sel?
>>cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Stripes-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/stripes-users
>>    
>>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Stripes-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/stripes-users
>  
>



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

paul.barry
In reply to this post by Ben Gunter
@DenyBinding, @AllowBinding?

On 10/18/06, Ben Gunter <[hidden email]> wrote:

>
>  Now that I think about it, it already works that way. The default value for
> "policy" is DENY so you don't have to explicitly set it. The mere presence
> of @BindAccess would prevent binding.
>
>  One drawback is that if you're reading the source code for an ActionBean,
> an empty @BindAccess annotation doesn't clearly indicate what effect it will
> have. Like @DontValidate means "don't validate" and @DefaultHandler means
> "default handler." I originally named the annotation @BindAccess because it
> was intended to describe the "binding access" rules. But if it can also be
> used as a simple marker, then perhaps there is a better name. Any
> suggestions? Maybe @StrictBinding?
>
>  -Ben
>
>
>  Tim Fennell wrote:
>  If/when merging into the core you could even go with a slightly more
> dynamic default policy of "if @BindAccess is present, default is
> deny, otherwise default is allow". That way as soon as you try to
> start securing a bean, you flip to the strict policy, and are
> backwards compatible elsewhere....
>
> -t
>
> On Oct 18, 2006, at 8:52 AM, Ben Gunter wrote:
>
>
>
>  After writing all that, I've thought some more on it and decided
> you're right after all. If this were to be merged into the Stripes
> core, it would become a new feature that could be enabled on a per-
> class basis with @BindAccess( policy = DENY ) or enabled globally
> with BindAccess.DefaultPolicy = DENY. I guess I was more focused on
> what's more secure than what's the best behavior for the framework.
> It will be much easier for people to get their first Stripes app
> going and get hooked on it if they don't have to worry about
> security constraints from the get-go. In short: my bad :)
>
> But for now, since it's in Stripes Extras and not Stripes itself, a
> default deny policy makes sense because if you didn't want the
> access protection you wouldn't have included the interceptor. And
> you can still change the default policy even so.
>
> -Ben
>
> Ben Gunter wrote:
>
>
>  Paul Barry wrote:
>
>
>
>  One reason I think that we should add this to the Stripes core is
> that
> other java web frameworks don't have it. AFAIK, Struts, Webwork and
> Spring MVC don't have it, not sure about any others. I'm not sure
> every web application needs this, but some will and having it built
> right into the framework would be a compelling argument for someone
> who needs this and is deciding on a framework.
>
> Also, I assume if you bring it into the stripes framework, you could
> do away with the Interceptor, you would just make it part of the
> stripes binding process. If you were to put it into stripes, you
> would have to make the default access policy ALLOW, or else you
> would
> lose backward compatibility. I think a default access policy of
> DENY
> makes sense for an add-on project, because it is explicit what
> behavior you are adding. But for making it part of stripes, it
> needs
> to be ALLOW. It should have an init-param to allow you to set the
> default policy to DENY.
>
>
>
>  I respectfully disagree with this statement. If the default policy
> is to
> allow binding to anything, then it is left up to the developer to
> make
> sure everything is locked down. But if access is denied by
> default, then
> everything is protected unless you explicitly allow binding (through
> @Validate or @BindAccess). Here's an example of why you want to
> deny by
> default:
>
> Type Person has property address of type Address and property
> privateStuff of type String.
> Type Address has property person, pointing back to the Person object
> that owns it.
> MyActionBean exposes a person property of type Person so that only
> the
> address can be updated.
>
> Say MyActionBean is annotated with @BindAccess
> (allow="person.address.*",
> deny="person.*"). You might think in this case that
> person.privateStuff
> would be protected, but it's not. Someone could post a request
> parameter
> like person.address.person.privateStuff and write into that
> property.
> The only way to address that would be to do
> @BindAccess(allow="person.address.*", deny="**") or
> @BindAccess(policy=DENY, allow="address.*"). But you would have to do
> that for *every* ActionBean, and in doing so you are essentially
> making
> the default policy DENY anyway. It's just a lot easier and safer
> for the
> policy to be DENY.
>
> There's another compelling reason, too. The access controls allow
> binding to any property annotated with @Validate, which means you
> don't
> even have to use any special-purpose annotations to control what
> can and
> can't be bound. By setting the default policy to ALLOW, you are
> forcing
> every ActionBean that needs protection to have @BindAccess
> attached to
> it. I prefer to stick with the Stripes core annotations if possible.
>
> Having said that, it's really simple to set the default policy to
> ALLOW
> by setting BindAccess.DefaultPolicy in web.xml. Admittedly, it
> would be
> just as easy to set it to DENY if things were reversed. But I'm of
> the
> opinion that unrestricted property binding is a bad thing, and I
> don't
> want that kind of backward compatibility. Call me crazy.
>
>
> ----------------------------------------------------------------------
> ---
> Using Tomcat but need to do more? Need to support web services,
> security?
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=120709&bid=263057&dat=121642______________________________
> _________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

VANKEISBELCK Remi
In reply to this post by Gary Moselen
On 10/18/06, Gary Moselen <[hidden email]> wrote:
> I would also be interested in putting @BindAccess on my model
> objects/properties directly. I have rich domain model objects [...]

There might be a misunderstanding here : we're talking about the
*ActionBean*'s properties, not the Domain Objects' !

Btw, IMHO, putting such stuff on a Domain Object is just not the right
place : it would mean that your object's *logic* is bound to a
*presentation* framework ?!?!
Binding control is specific to Stripes (and other auto binding stuff)
: Domain Objects don't care who sets their properties and how this is
done...

Have fun,

Remi

--
Rémi VANKEISBELCK
[hidden email]
http://www.rvkb.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

Gary Moselen
In reply to this post by Barry Davies
VANKEISBELCK Remi wrote:

>On 10/18/06, Gary Moselen <[hidden email]> wrote:
>  
>
>>I would also be interested in putting @BindAccess on my model
>>objects/properties directly. I have rich domain model objects [...]
>>    
>>
>
>There might be a misunderstanding here : we're talking about the
>*ActionBean*'s properties, not the Domain Objects' !
>
>Btw, IMHO, putting such stuff on a Domain Object is just not the right
>place : it would mean that your object's *logic* is bound to a
>*presentation* framework ?!?!
>Binding control is specific to Stripes (and other auto binding stuff)
>: Domain Objects don't care who sets their properties and how this is
>done..
>  
>
No, I understand fine. I expose my domain objects as ActionBean
properties, so if I expose User in 5 different ActionBeans I dont want
to lock down the relationship to the Account object 5 times for each
ActionBean.

Because I am exposing my domain objects, the security on the
relationships *is* part of the domain. I don't want anybody's code apart
from mine changing certain attributes on my domain objects. For example
I might serve and accept XML over HTTP, in this case  JAXB will do the
binding to the domain objects and I want to reuse the same @nnotations
in that case.

But you might be right that I should keep this seperate from Stripes and
build my own set of @nnotations and look at using the standard
SecurityManager stuff.

cheers,
Gary


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Some basic field-level security

VANKEISBELCK Remi
Hey Gary,

I understand your concern.

Have you had a look at Acegi ? As far as I understood your problem,
that could be the solution you need (without intrusion into your
domain model) !
It's actually much simpler than the security manager stuff, and works fine...

Cheers

Remi

On 10/23/06, Gary Moselen <[hidden email]> wrote:

> No, I understand fine. I expose my domain objects as ActionBean
> properties, so if I expose User in 5 different ActionBeans I dont want
> to lock down the relationship to the Account object 5 times for each
> ActionBean.
>
> Because I am exposing my domain objects, the security on the
> relationships *is* part of the domain. I don't want anybody's code apart
> from mine changing certain attributes on my domain objects. For example
> I might serve and accept XML over HTTP, in this case  JAXB will do the
> binding to the domain objects and I want to reuse the same @nnotations
> in that case.
>
> But you might be right that I should keep this seperate from Stripes and
> build my own set of @nnotations and look at using the standard
> SecurityManager stuff.
>
> cheers,
> Gary
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Stripes-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>


--
Rémi VANKEISBELCK
[hidden email]
http://www.rvkb.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
12