Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Hi,
I found this solution to the security elegant: simply putting a
@RequiresLogin in the page to be protected and let the
ComponentRequestFilter checks the annotation in the page. now if I need
something else, say @ReqiresOwner, say I'd allow the owner of inbox to go to
a Inbox page, I can pass the instance of Inbox page to authService：
if ( page.getClass().isAnnotationPresent(RequiresOwner.class)) {
if (!authService.checkPageOwner(page)) {
return false;
}
}
And condition to check if a logged in user is the owner of the said page
depends on situation, most of time it depends on the activation context
which might be the user, or some objects belong to the user, what will be a
generic way to take care of this situations? Thanks,
Angelo
Howard Lewis Ship wrote:
This subject still keeps coming up on the mailing list and I thought
I'd show a little bit about how I tackle this problem generally. People
have been asking for a single solution to handling security ... but I
don't see any single solution satisfying even the majority of projects?
Why? There are too many variables. For example, are you using LDAP,
OpenAuth or some ad-hoc user registry (in your database)? Are pages
accessible by default, or in-accessible? Are you using role-based
security? How do you represent roles then? Creating a single solution
that's pluggable enough for all these possibilities seems like an
insurmountable challenge ... but perhaps we can come up with a toolkit
so that you can assemble your own custom solution (more on that later).
One approach to security could be to define a base class,
ProtectedPage, that enforced the basic rules (you must be logged in to
use this page). You can accomplish such a thing using the activate
event handler ... but I find such an approach clumsy. Anytime you can
avoid inheritance, you'll find your code easier to understand, easier
to manage, easier to test and easier to evolve.
Instead, let's pursue a more declarative approach, where we use an
annotation to mark pages that require that the user be logged in. We'll
start with these ground rules:
- Pages are freely accessible by anyone, unless they have
a @RequiresLogin annotation
- Any static resource (in the web context directory) is accessible to
anybody
- There's already some kind of UserAuthentication service that knows if
the user is currently logged in or not, and (if logged in) who they
are, as a User object
So, we need to define a RequiresLogin annotation, and we need to
enforce it, by preventing any access to the page unless the user is
logged in.
That poses a challenge: how do you get inside Tapestry to enforce
this annotation? What you really want to do is slip in a little bit
of your code into existing Tapestry code ... the code that analyzes the
incoming request, determines what type of request it is (a page render
request vs. a component event request), and ultimately starts calling
into the page code to do the work.
This is a great example of the central design of Tapestry and it's IoC
container: to natively supporting this kind of extensibility. Through
the use of service configurations it's possible to do exactly that:
slip a piece of code into the middle of that default Tapestry code. The
trick is to identify where. This image gives a rough map to how
Tapestry handles incoming requests:
In fact, there's a specific place for this kind of extension: the
ComponentRequestHandler pipeline service1. As a pipeline service,
ComponentRequestHandler has a configuration of filters, and adding a
filter to this pipeline is just what we need. Defining the Annotation
First, lets define our annotation:
@Target( {
ElementType.TYPE }) @Retention(RetentionPolicy.RUNTIME) @Documented
public @interface RequiresLogin { }
This annotation is designed to be placed on a page class to indicate
that the user must be logged in to access the page. The retention
policy is important here: it needs to be visible at runtime for our
runtime code to see it and act on its presence.
An annotation by itself does nothing ... we need the code that checks
for the annotation. Creating a ComponentRequestFilter
Filters for the ComponentRequestHandler pipeline are instances of the
interface ComponentRequestFilter:
/** * Filter interface for {...@link
org.apache.tapestry5.services.ComponentRequestHandler}. */ public
interface ComponentRequestFilter { /** * Handler for a component action
request which will trigger an event on a component and use the return
value to * send a response to the client (typically, a redirect to a
page render URL). * * @param parameters defining the request * @param
handler next handler in the pipeline */ void
handleComponentEvent(ComponentEventRequestParameters parameters,
ComponentRequestHandler handler) throws IOException; /** * Invoked to
activate and render a page. In certain cases, based on values returned
when activating the page,
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni alexbott...@gmail.com wrote: Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following Unfortunately i can't see any code nor docs from you. Cheers -- Massimo - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Il 02/01/2010 20:18, Massimo Lusetti ha scritto: On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni alexbott...@gmail.com wrote: Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following Unfortunately i can't see any code nor docs from you. Massimo, of course you are right when you underline this but... Let's me play the Devil's advocate for a moment... :-) I'm not accusing any of the Tapesty/ChenilleKit guys of anything. I'm just trying to understand why Tapestry does not have the same level of appreciation by the large public as Wicket, despite its evident technical superiority. I'll be happy to contribute some code/docu when I'll be able to write it. Of course, the less docu I find, the less code and docu I'll be able to write in the short/medium term. :-) Cheers -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Some subjects are so serious that one can only joke about them. -- Niels Bohr - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
On Sun, Jan 3, 2010 at 4:40 AM, Alessandro Bottoni alexbott...@gmail.com wrote: Il 02/01/2010 20:18, Massimo Lusetti ha scritto: On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni alexbott...@gmail.com wrote: Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following Unfortunately i can't see any code nor docs from you. Massimo, of course you are right when you underline this but... Let's me play the Devil's advocate for a moment... :-) I'm not accusing any of the Tapesty/ChenilleKit guys of anything. I'm just trying to understand why Tapestry does not have the same level of appreciation by the large public as Wicket, despite its evident technical superiority. I'll be happy to contribute some code/docu when I'll be able to write it. Of course, the less docu I find, the less code and docu I'll be able to write in the short/medium term. :-) tapestry document are really less,and not fit with the friends from non-english country. code example were a little no practical .. it's my advice... so we should do more and complain less.. Cheers -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Some subjects are so serious that one can only joke about them. -- Niels Bohr - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- cleverpig(Dan) Location: Beijing Address: Room 4018,No.A2 South Avenue Fuxingmen Beijing,P.R.China Zipcode: 100031 MSN: great_liu...@hotmail.com QQ: 149291732 Skype: cleverpigatmatrix Facebook ID:cleverpig Blog: www.cleverpig.name Tags: del.icio.us/cleverpig Twitter: twitter.com/cleverpig 新浪微博: t.sina.com.cn/cleverpig Organization: www.beijing-open-party.org or...@facebook: http://www.facebook.com/group.php?gid=8159558294 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
sometimes i am wondered about people, the hopes, that they learn tapestry at their REM phase. with regards Sven Homburg Founder of the Chenille Kit Project http://chenillekit.codehaus.org 2010/1/2 cleverpig greatclever...@gmail.com On Sun, Jan 3, 2010 at 4:40 AM, Alessandro Bottoni alexbott...@gmail.com wrote: Il 02/01/2010 20:18, Massimo Lusetti ha scritto: On Thu, Dec 31, 2009 at 12:16 PM, Alessandro Bottoni alexbott...@gmail.com wrote: Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following Unfortunately i can't see any code nor docs from you. Massimo, of course you are right when you underline this but... Let's me play the Devil's advocate for a moment... :-) I'm not accusing any of the Tapesty/ChenilleKit guys of anything. I'm just trying to understand why Tapestry does not have the same level of appreciation by the large public as Wicket, despite its evident technical superiority. I'll be happy to contribute some code/docu when I'll be able to write it. Of course, the less docu I find, the less code and docu I'll be able to write in the short/medium term. :-) tapestry document are really less,and not fit with the friends from non-english country. code example were a little no practical .. it's my advice... so we should do more and complain less.. Cheers -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Some subjects are so serious that one can only joke about them. -- Niels Bohr - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- cleverpig(Dan) Location: Beijing Address: Room 4018,No.A2 South Avenue Fuxingmen Beijing,P.R.China Zipcode: 100031 MSN: great_liu...@hotmail.com QQ: 149291732 Skype: cleverpigatmatrix Facebook ID:cleverpig Blog: www.cleverpig.name Tags: del.icio.us/cleverpig Twitter: twitter.com/cleverpig 新浪微博: t.sina.com.cn/cleverpig Organization: www.beijing-open-party.org or...@facebook: http://www.facebook.com/group.php?gid=8159558294 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Il 29/12/2009 12:45, Vangel V. Ajanovski ha scritto: +1 from me for putting such article in the official documentation on the website, because blogs are (by nature) relevant for a moment in time and if it's put in the official documentation one would have to check and sign that this works on every new release. And +1 for me, as well. Such info should stay in plain sight in the HowTo section of the wiki and/or in the official docu. -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ If man hasn't discovered something that he will die for, he isn't fit to live. -- Martin Luther King - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Il 29/12/2009 21:32, Alex Kotchnev ha scritto: chenillekit-access, and a bunch more). As much as people have a tendency to complain that spring security is too complicated, it seems that any other solution (e.g. based on T5 IoC) that attempts to provide the same level of flexibility and generality will eventually end up with similar complexity ( and will most likely never have the mind market share of spring security). Thus, it seems to me that the effort to provide a new framework to do all of this is somewhat futile. Actually, maybe there is a need for TWO different solutions: 1) A quite basic module, or even a well-documented demo, that just takes into account the most common requirements and uses a set of sensible defaults. This basic package should not have to be extensible or flexible. It should just have to be usable and understandable. It would be mostly used to study this problem and to see how to solve it in a Tapestry-like way. It would also be used as a quickdirty solution for the most basic applications. IMHO, this solution should be developed with Tapestry annotations (see: http://tapestryjava.blogspot.com/2009/12/securing-tapestry-pages-with.html) and used as a demo of such programming technique, as well. 2) An enterprise-level module, like Spring Security. This solution should have to be flexible and extendible. It should be able to deal with LDAP, OpenID, JASIG CAS and other providers. It would be used for complex, enterprise-level apps. An alternative approach (which seems to be quite successful in Grails land) seems to be to provide integration simplification w/ existing security frameworks that already have all of the flexibility (and complexity) that you talk about . For example. in Grails using the spring security plugin comes down to installing the plugin and annotating your controllers w/ Roles - it certainly reduces the number of available options (thus making it less flexible) but the ease of getting started with it is quite attractive . This would a very good solution for this problem and I vote for it. Despite this, it would be very little tapestrystic (it rhimes with pythonistic)... I mean: it would miss the apportunity to contribute in making a more componentized, elegant working environment for all of us. If the desire is to provide a pure T5 based solution, why not take one of the existing security modules (e.g. chenillekit-access) and analyze its approach and improve it instead of starting from scratch (and use the forum as an opportunity to improve extend the same existing component) ? This approach is exactly what I would expect for the enterprise-level module I described above (case 2). It could/should be something like ACEGI or Swarm/Wasp and it should be very standardized, quite extensible/flexible and very well tested. It could be based on annotations or on other techniques, depending on the judgment of the developing community. Most likely, it would deserve a separated project. JM2C -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ Life is a sexually transmitted disease, and it's 100% fatal. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Il 29/12/2009 21:32, Alex Kotchnev ha scritto: approach. As Thiago already mentioned, there are at least a few more solutions that attempt to provide this (e.g. Thiago's own, chenillekit-access, and a bunch more). Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following quote Introduction ChenilleKit Access module sits in between your page processing logic and the client HTTP request, doing so it is able to decide when and how the request can pass through or not. For doing so it needs two different steps. First it put RestrictedWorker into the ComponentClassTranformWorker pipeline, this class is responsible to read the annotation class and store various meta information needed by AccessValidator. Second it put two Dispatcher into two different pipelines for intercepting page render and component event action requests to check if they're directed to restricted class/events and to apply the needed constraints. /quote I'm sorry but I have to say that many (or most?) new users will not have neither the time nor the patience to study the JavaDoc or the source code just to figure out how to use this (or any other) library, no matter how simple it can be. Moreover, in many cases it would be very hard to convince the project leader or the end user to accept a (sorry Thiago ) not-canonical, little known, little documented, maybe-risky library like this one. For what regards me, for example, I would be forced to look for a widely-recognized, well-tested, well-documented, standard module, inside or outside the Tapestry world (Acegi?) or, as an alternative, to demonstrate that ChenilleKit is the right tool for the task at hand (being ready to pay for any possible error about my judgment...). Just the voice of the Devil, anyway... ;-) PS: Yes, I'm aware of this article: http://www.equanda.org/templates/login.html . -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ They say if you play a Microsoft CD backwards, you hear satanic messages. That's nothing, cause if you play it forwards, it installs Windows. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Em Thu, 31 Dec 2009 08:44:00 -0200, Alessandro Bottoni alexbott...@gmail.com escreveu: 1) A quite basic module, or even a well-documented demo, that just takes into account the most common requirements and uses a set of sensible defaults. This basic package should not have to be extensible or flexible. A demo with this features would be a very good idea. 2) An enterprise-level module, like Spring Security. This solution should have to be flexible and extendible. It should be able to deal with LDAP, OpenID, JASIG CAS and other providers. It would be used for complex, enterprise-level apps. Re-implement something like Spring Security is not feasible, IMHO. It would need people who know a lot about security, and Tapestry is a Web framework. In addition, that's an awful lot of code to write and, AFAIK, very few projects use these security providers (besides OpenID). We should focus on what will be useful for the most people. I don't think using Spring Security the Tapestry security module because it forces the use of Spring. I still need to take a look at JSecurity/Apache Shiro, but I guess it would fill this need better. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Em Thu, 31 Dec 2009 09:16:15 -0200, Alessandro Bottoni alexbott...@gmail.com escreveu: Il 29/12/2009 21:32, Alex Kotchnev ha scritto: approach. As Thiago already mentioned, there are at least a few more solutions that attempt to provide this (e.g. Thiago's own, chenillekit-access, and a bunch more). Let's me play the Devil's advocate for a moment... I guess Alex suggested to start the development of a Tapestry security package based on some package that already exists, not adopting them as part of the Tapestry project as they are now. We all agree that documentation is key and should be improved. Moreover, in many cases it would be very hard to convince the project leader or the end user to accept a (sorry Thiago ) not-canonical, little known, little documented, maybe-risky library like this one. I never suggested that someone should use a little documented package, so I don't know why you're apologizing to me. :) Little-known library? Unfortunately, Tapestry is not a very well-known library AFAIK. :( -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Hi Allesandro, i totally agree with you. The documentation of the ChenilleKit-Modules is bad or lacks at some points. One of our good intentions for 2010 is to write more and better docs. with regards Sven Homburg Founder of the Chenille Kit Project http://chenillekit.codehaus.org 2009/12/31 Alessandro Bottoni alexbott...@gmail.com Il 29/12/2009 21:32, Alex Kotchnev ha scritto: approach. As Thiago already mentioned, there are at least a few more solutions that attempt to provide this (e.g. Thiago's own, chenillekit-access, and a bunch more). Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following quote Introduction ChenilleKit Access module sits in between your page processing logic and the client HTTP request, doing so it is able to decide when and how the request can pass through or not. For doing so it needs two different steps. First it put RestrictedWorker into the ComponentClassTranformWorker pipeline, this class is responsible to read the annotation class and store various meta information needed by AccessValidator. Second it put two Dispatcher into two different pipelines for intercepting page render and component event action requests to check if they're directed to restricted class/events and to apply the needed constraints. /quote I'm sorry but I have to say that many (or most?) new users will not have neither the time nor the patience to study the JavaDoc or the source code just to figure out how to use this (or any other) library, no matter how simple it can be. Moreover, in many cases it would be very hard to convince the project leader or the end user to accept a (sorry Thiago ) not-canonical, little known, little documented, maybe-risky library like this one. For what regards me, for example, I would be forced to look for a widely-recognized, well-tested, well-documented, standard module, inside or outside the Tapestry world (Acegi?) or, as an alternative, to demonstrate that ChenilleKit is the right tool for the task at hand (being ready to pay for any possible error about my judgment...). Just the voice of the Devil, anyway... ;-) PS: Yes, I'm aware of this article: http://www.equanda.org/templates/login.html . -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ They say if you play a Microsoft CD backwards, you hear satanic messages. That's nothing, cause if you play it forwards, it installs Windows. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Just to add my 2 cents ... imho it's best to build on an exiting framework like spring-security rather than trying to re-invent the wheel. acegi/spring-security has great traction in the market and it's very well documented. Recent versions are becoming much simpler due to sensible defaults but more esoteric use-cases are still supported. Toby 2009/12/31 Sven Homburg hombu...@googlemail.com Hi Allesandro, i totally agree with you. The documentation of the ChenilleKit-Modules is bad or lacks at some points. One of our good intentions for 2010 is to write more and better docs. with regards Sven Homburg Founder of the Chenille Kit Project http://chenillekit.codehaus.org 2009/12/31 Alessandro Bottoni alexbott...@gmail.com Il 29/12/2009 21:32, Alex Kotchnev ha scritto: approach. As Thiago already mentioned, there are at least a few more solutions that attempt to provide this (e.g. Thiago's own, chenillekit-access, and a bunch more). Let's me play the Devil's advocate for a moment... ChenilleKit-Access is an example of why the typical new user (like me) will NOT use such a solution, no matter how good and elegant it could be. The reason is that the ONLY official documentation you can find using Google is the following quote Introduction ChenilleKit Access module sits in between your page processing logic and the client HTTP request, doing so it is able to decide when and how the request can pass through or not. For doing so it needs two different steps. First it put RestrictedWorker into the ComponentClassTranformWorker pipeline, this class is responsible to read the annotation class and store various meta information needed by AccessValidator. Second it put two Dispatcher into two different pipelines for intercepting page render and component event action requests to check if they're directed to restricted class/events and to apply the needed constraints. /quote I'm sorry but I have to say that many (or most?) new users will not have neither the time nor the patience to study the JavaDoc or the source code just to figure out how to use this (or any other) library, no matter how simple it can be. Moreover, in many cases it would be very hard to convince the project leader or the end user to accept a (sorry Thiago ) not-canonical, little known, little documented, maybe-risky library like this one. For what regards me, for example, I would be forced to look for a widely-recognized, well-tested, well-documented, standard module, inside or outside the Tapestry world (Acegi?) or, as an alternative, to demonstrate that ChenilleKit is the right tool for the task at hand (being ready to pay for any possible error about my judgment...). Just the voice of the Devil, anyway... ;-) PS: Yes, I'm aware of this article: http://www.equanda.org/templates/login.html . -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ They say if you play a Microsoft CD backwards, you hear satanic messages. That's nothing, cause if you play it forwards, it installs Windows. -- Unknown - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
On 31.12.2009 11:44, Alessandro Bottoni wrote: 2) An enterprise-level module, like Spring Security. This solution should have to be flexible and extendible. It should be able to deal with LDAP, OpenID, JASIG CAS and other providers. It would be used for complex, enterprise-level apps. When you mention CAS, do you know that by using it you can in fact use both JDBC, LDAP, Active Directory, Radius, JAAS, Kerberos behind it all at the same time.. CAS can authenticate your users from many sources and they will see only a single login page. I have pretty positive experience with JASIG CAS and we have been using it for 4 years now. We use it for single-sign-on accross several applications (uPortal, Moodle, Trac, our Course Enrollment project based on Tapestry, another ASP.Net project, few other PHP apps etc). Why we decided on CAS. The userbase is mostly US universities with tens of thousands of students. If they trust it to keep users in or out of their services, why wouldn't we? 1. CAS has a service, which is a relatively small java web app (13MB war) that presents a login screen and redirects to your application if the user is authenticated. Very easy to configure. The setup is very very easy (XML based) and there are many configuration examples on the web and I was able to set it in under Tomcat and configure to connect to two active directory domains in just half an hour. So users from both domains can use my application and any other application that will be casified. 2. How to use it in the app? a. In your app you include a CAS client that checks the service if any user is logged in and what is the name of the user. This is again simple, you just read the username via some method from the client classes. b. If you don't like to put the client in your app, you can set it as a filter on the web server (in web.xml) to listen to several paths. So on each request if the user is logged in, a session variable will be set with the validated username. c. Both ways you get the username and you can then decide what to do about it. I think that's simple. Few XML configurations for the CAS service and a single line of code to get the username in your app. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
On 28.12.2009 23:49, Howard wrote: Instead, let's pursue a more declarative approach, where we use an annotation to mark pages that require that the user be logged in. We'll start with these ground rules: We changed several approaches since the start of our app, and this approach is the last we have. But as Howard discussed many times, such a solution is not fit for everyone, and we don't have that special requirements. We use this approach only for authorization, while the authentication is completely done by JASIG CAS client that sits configured as a filter in front of Tapestry. In this case, if the visitor is not authenticated, he will never be able to get a request thru to tapestry. For authorization we have several different page annotations (similar to the @RequiresLogin annotation) that we can combine and they tell us the groups of users that are allowed to access a page. Then a cross check is done in the requesthandler contribution whether the annotation on the page corresponds to some of the groups the user is member of read from the database. Before that we had spring-security and i didn't like it, although the point of it was that it already supported many type of authentication methods. But it turns out we don't need them now, and the change was not that big. The information on how to implement all this was already discussed on this mailing list, the wiki and other places and I managed to glue that up in our working solution in less than a week working in free time. Some of the wiki guides were outdated and hindered the process. With such a guide I would have finished in just 1 day. +1 from me for putting such article in the official documentation on the website, because blogs are (by nature) relevant for a moment in time and if it's put in the official documentation one would have to check and sign that this works on every new release. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Howard, having looked at the T5-spring-security code (and spring security itself) I see quite a number of similarities with what you describe as an approach. As Thiago already mentioned, there are at least a few more solutions that attempt to provide this (e.g. Thiago's own, chenillekit-access, and a bunch more). As much as people have a tendency to complain that spring security is too complicated, it seems that any other solution (e.g. based on T5 IoC) that attempts to provide the same level of flexibility and generality will eventually end up with similar complexity ( and will most likely never have the mind market share of spring security). Thus, it seems to me that the effort to provide a new framework to do all of this is somewhat futile. An alternative approach (which seems to be quite successful in Grails land) seems to be to provide integration simplification w/ existing security frameworks that already have all of the flexibility (and complexity) that you talk about . For example. in Grails using the spring security plugin comes down to installing the plugin and annotating your controllers w/ Roles - it certainly reduces the number of available options (thus making it less flexible) but the ease of getting started with it is quite attractive . If the desire is to provide a pure T5 based solution, why not take one of the existing security modules (e.g. chenillekit-access) and analyze its approach and improve it instead of starting from scratch (and use the forum as an opportunity to improve extend the same existing component) ? Regards, Alex K On Tue, Dec 29, 2009 at 6:45 AM, Vangel V. Ajanovski a...@ii.edu.mk wrote: On 28.12.2009 23:49, Howard wrote: Instead, let's pursue a more declarative approach, where we use an annotation to mark pages that require that the user be logged in. We'll start with these ground rules: We changed several approaches since the start of our app, and this approach is the last we have. But as Howard discussed many times, such a solution is not fit for everyone, and we don't have that special requirements. We use this approach only for authorization, while the authentication is completely done by JASIG CAS client that sits configured as a filter in front of Tapestry. In this case, if the visitor is not authenticated, he will never be able to get a request thru to tapestry. For authorization we have several different page annotations (similar to the @RequiresLogin annotation) that we can combine and they tell us the groups of users that are allowed to access a page. Then a cross check is done in the requesthandler contribution whether the annotation on the page corresponds to some of the groups the user is member of read from the database. Before that we had spring-security and i didn't like it, although the point of it was that it already supported many type of authentication methods. But it turns out we don't need them now, and the change was not that big. The information on how to implement all this was already discussed on this mailing list, the wiki and other places and I managed to glue that up in our working solution in less than a week working in free time. Some of the wiki guides were outdated and hindered the process. With such a guide I would have finished in just 1 day. +1 from me for putting such article in the official documentation on the website, because blogs are (by nature) relevant for a moment in time and if it's put in the official documentation one would have to check and sign that this works on every new release.
Re: [Tapestry Central] Securing Tapestry pages with Annotations, Part 1
Em Mon, 28 Dec 2009 20:49:09 -0200, Howard hls...@gmail.com escreveu: Instead, let's pursue a more declarative approach, where we use an annotation to mark pages that require that the user be logged in. We'll start with these ground rules: - Pages are freely accessible by anyone, unless they have a @RequiresLogin annotation That's exactly the approach used in my Tapestry Security package. It's not released yet nor it has documentation, but I'm already using it in production for a public Internet website (www.pronutricionista.com.br). Tapestry Security sources are available for browsing at http://ars-machina.svn.sourceforge.net/viewvc/ars-machina/tapestry-security/trunk/ and checkout at https://ars-machina.svn.sourceforge.net/svnroot/ars-machina/tapestry-security/trunk. There's a @NeedsLoggedInUser annotation that is processed by a Dispatcher. It throws an AnonymousAccessDeniedException when a not logged in user attempts to read that page. Tapestry Security is built on top of Generic Authentication and Generic Authorization, two other packages in the same repository. Generic Authentication defines User, Permission, PermissionGroup, and UserGroup classes. There's another annotation, @NeedsPermission, denies access to unlogged users and logged user that don't have the need permission(s). Generic Authorization defines a framework for controlling access to reading, creating, updating, and removing objects, both at object and class level. Then Tapestry CRUD (even another package inside the Ars Machina Project) uses them to automatically secure CRUD pages. I wish I had the opportunity the document and write unit test for them, so I could donate them to Tapestry, a project that requires very high quality code. Everyone is invited to checkout the code and post opinions and suggestions in the mailing list or send them to me directly. - There's already some kind of UserAuthentication service that knows if the user is currently logged in or not, and (if logged in) who they are, as a User object Tapestry Security has an UserService service that does exactly that. Maybe we could reuse it in Tapestry itself. application to continue after the user logs in. Finally, the AuthenticationService is not part of Tapestry ... it is something specific to the application. Tapestry could define an AuthenticationService interface and just provide a dummy one out-of-the-box. Other packages could overwrite the implementation of this service. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
