M.Sc. thesis 2006


Sebastian Wittler


Typically, access control is performed on existing resources taking such resources as whole pieces. Then, permissions or policies are assigned to the resource. Therefore, whenever there exists a request for a resource, the protection mechanism consists on retrieving the associated permissions or policies in order to decide whether access is granted or denied.

However, this mechanisms cannot be easily applied to current Web. Nowadays, a big part of the web pages available on the Web are not static. Instead, they are dynamically generated and may even depend on input parameters. That means that the final resource is not known in advance and therefore it is not possible to assign permissions or policies to it. An approach in which dynamic content can be protected or even generated according to policies is to be performed. This should include:

  • An HTML-compatible markup language for stating policies in JSP's
  • An implementation of a client with negotiation capabilities (e.g., by means of an applet)
  • The development of an editor to ease administrator and user specification of policies and its assignment
Policy Driven Negotiation
Web Servers & Web Page generation
Rich Client Platform
Other Links

Planning Overview

  • Reading papers and learning about the topics
  • No milestone nor output
  • Investigate how web servers work
  • Investigate the generation of new jsp tags for dynamic generation of web pages
  • Investigate how applets work
  • Investigate communication among applet and web servers via HTTP requests
  • Implementation of the communication between an applet and web server
  • Protection of web server files (you did it via filters)
  • Definition of a model for describing resource protection.
  • Software demo of the communication between applet and server
  • Generation of an example website (the one we talked) where some parts are protected. Negotiation is faked (not real) or it does not even exist (only simple communication).
  • Integration of the policy engine interface. If the engine does not yet fully work, fake its functionality.
  • Integrate the HTTP based communication with the policy engine interface
  • Develop a class at a web server which checks if an HTTP requests tries to access a protected resource and act accordingly:
    • If the resource is not protected, then return the resource as the web server would do
    • if the resource is protected apply the following 2 conditions (IMPORTANT: both conditions are applied):
      1. Protection as a whole
        1. If the resource is protected as a whole, then ask the policy engine. If the engine decides that it can be released, then go to step 2. If the engine decides it cannot be released, then provide an "access denied" page (later it will be an explanation).
        2. If the resource is not protected as a whole, then go to step 2,
      2. Dynamic protection
        1. if the resource is a dynamic generated page (that is, jsp), then generate the page. During the generation, the jsp tags may contact the policy engine and generate different content depending on the result. Return the final generated page as it would be done by a web server.
        2. If the resource is not a dynamic generated page, then return the resource as it would be done by a web server.
  • Website Demo with faked negotiations fully working
  • Integration of working policy engine
  • Improvement of the website functions with e.g. Javascript
    • Temporal page while negotiation takes place
    • Visualization of information disclosed and/or received
    • Others
  • Develop of an Eclipse RCP client in order to generate the files for web server resource protection. Two perspectives/focuses:
    • on the file system. Hierarchy/ontology is given by file system structure. Filters may be used in order to apply selections of resources in a folder.
    • on credentials. users can protect e.g. credit cards and they may build an ontology in order to assign policies to a superclass (e.g., CreditCard) and not to each subclass (e.g., VISA or Mastercard) or instances (e.g. my VISA card with # 12342).
    • in both cases, policies are composed. For example, policies in a folder /home/doc/ are composed with the ones in /home/doc/pdf/ when asking for a resource /home/doc/pdf/document1.pdf
  • First version of the client with full functionality (but without too many visual elements and fancy widgets)
  • Adding explanations (the code will be given to you by me and Juri). The explanation will be HTML code generated by the policy engine which will be added in case of:
    • if successful negotiation, add the why explanation
    • if unsuccessful negotiation, add the why-not explanation
  • Finish work on the client with more fancy issues in order to help the user
    • Toolbar
    • Tooltips
    • Visual widgets
    • Others
  • Debugging
    • Development of junit classes
    • Manual evaluation of the visual components with documented test plans.
  • Website with explanations running
  • Final version of the client
  • Document with test plans
  • Debugging
  • Work on code compliance with guidelines
    • Using log4j in order to log messages in a trace
    • Class and method headers
    • Javadoc
    • Others
  • Develop a full documentation
    • Test plans
    • User manual
    • Architecture overview and description (including open issues, assumptions made, problems found, challenges, etc...)
    • Javadoc
  • Final Software
  • Fully working website example
  • Documentation
    • Test plans
    • User manual
    • Architecture overview and description (including open issues, assumptions made, problems found, challenges, etc...)
    • Javadoc



Last update on 27-Jun-2007 0:11 AM Home