Secure application pages with tapestry5. Rethinking.

Continuing the theme started in my previous topic:
Secure application pages with tapestry5
Just rethink page security and marked some interesting moments.
Like in previous article let's imagine that we have some application with authentication and users separation by their authorities. There are also a set of allowed pages and a set of allowed actions on this pages for every such authority. So we can keep in mind such statements:

• All security checks for pages should happen before any business logic will take effect. So this business logic will always be protected from unauthorized access and we can sleep peacefully. The best place for that in tapestry5 applications is just before page activation.
• All security checks for page actions should happen after security checks for containing pages (as user to be authorized for page action should also be authorized for page containing this action) and before any business logic will take effect.

Let's start with page security.

Page security.

After thinking about it I've found such places where security checks can be placed:

• Outside tapestry5 flow in servlet filters, e.g. like spring security provides.
• The same as previous but inside tapestry5 flow via servlet filters adapted by tapestry5 HttpServletRequestFilter or RequestFilter implementations. I will not see this two variants in article as they doesn't depend on framework used and will be the same for all frameworks.
• Inside ComponentRequestHandler pipeline.
• Inside PageActivator service.
• Inside advised page activation event handlers

Annotation that will be placed on page classes (and event handler methods):
If such annotation presents on a page class, user will need to have defined authority to access the page. If such annotation presents on event handler method, the same behaviour to access page action.

Page security with ComponentRequestHandler pipeline.

This pipeline handles both page and component event requests. So it is a good place to keep security checks for pages. It will check user authorities for both situations: before page activation and before component event handler execution. Of course, we can place it inside PageRenderRequestHandler and ComponentEventRequestHandler pipelines but it is extra work.

It can also operate with page meta-data (Use MetaDataLocator with configured MetaDataExtractor) or some other security data provider instead of direct access to page class annotations.

Page security with PageActivator service.

This service is responsible for firing the activate event on the page. So if we will place security checks in this method, they will be triggered just before page activation. This approach is similar to previous as page activator service is triggered within PageRenderRequestHandler and ComponentEventRequestHandler pipelines.

Page security with advised page activation event handlers.

This way is the most tricky. We will advise dispatchComponentEvent method on a page classes and will check page authorities in method advice. Also this way is the slowest as it uses the most loaded page method (for almost all events it will just check if event handler matches activate event) and can check page authority for a lot of times(for every activate event handler presenting on the page class). But for most of applications this will not matter. This approach also has pros, e.g. as you will see later it can be combined together with page event handlers security.

NOTE: This is version for tapestry 5.3. For version 5.2 it will differ.

The similar approach is to use activate event handler advices. But this way has some cons. We have to advice all activate event handlers on a page as event handlers with one or more parameters will be executed before event handler with zero-count parameters. Or if it doesn't matter you can advise only one activate event handler.

Page actions security.

OK, our pages are safe from unauthorized access. But what about page event handlers? Now imagine that some event handlers need more authorities than a page. As you understand we need some more security checks for this.
So, places, where we can place security checks for event handlers:

• ComponentRequestHandler pipeline
• Event handlers advices

Event handlers security with ComponentRequestHandler pipeline.

It can be combined with the same approach as for page security. Just one note: adviced methods doesn't have annotations that original methods have. But we can use page meta-data for this purpose.

Event handlers security with advised methods.

It can also be combined with the same approach as for page security. The advantage is that security checks will always be executed just before event handlers with no matter what component initiates event within what method it was executed.