03.05.2015 Views

IBM WebSphere V5.0 Security - CGISecurity

IBM WebSphere V5.0 Security - CGISecurity

IBM WebSphere V5.0 Security - CGISecurity

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

If the user in role 'A' accesses /helloworld/helloEurope.html he will get an<br />

authorization error saying that the user is not in the role of 'B', but we defined that<br />

role ‘A’ should be able to access everything under /helloworld. The user in role ‘A’<br />

can still access the /helloworld/helloAfrica.html resource, and the user in role ‘B’<br />

can access /helloworld/helloEurope.html<br />

As you see, Constraint ‘Y’ overrules Constraint ‘X’ in this situation.<br />

The other approach would be to map roles to resources, and define the<br />

authorized roles for each resource. Obviously, this is not a possible solution<br />

since an application probably has more resources than we want to set up one by<br />

one.<br />

A solution, the same that we applied to the ITSOBank sample application, could<br />

be to reuse the use cases for the application and follow them to define security<br />

constraints. In this approach, each constraint covers a use case, the roles are<br />

the identified actors for the use case and the resources are the resources<br />

involved in the use case.<br />

For example, the ITSOBank sample application has a use case: customer<br />

transfer. The actors that can use this use case are manager and clerk. The<br />

resources are: transfer/customertransfer.html, servlet/Transfer,<br />

transfer/transferresults.jsp. The listed elements can define the appropriate<br />

resource collection for the right group of roles. Of course, this is only one<br />

approach and it might not be the best in every case.<br />

The purpose of this section is to point out the problem with the first two<br />

approaches and make you think about this issue.<br />

You can also protect your resources based on URL patterns using a security<br />

reverse proxy in your infrastructure, for example via Tivoli Access Manager’s<br />

WebSEAL.<br />

Struts security<br />

Struts is a very powerful framework to implement the Model-View-Controller<br />

design pattern for a Web application. The framework at this stage does not<br />

provide security functions, it leaves the issue to the J2EE Web module to handle<br />

security. Struts does not carry any security problems, but there are certain<br />

considerations you have to keep in mind.<br />

The reason why the security issue arises is because Struts is a single access<br />

point under the cover, for multiple application functions. One single servlet<br />

handles all actions implementing the command pattern.<br />

70 <strong>IBM</strong> <strong>WebSphere</strong> <strong>V5.0</strong> <strong>Security</strong> Handbook

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!