Once the Web server plug-in authenticates that a valid user is requesting access to a protected URL, it checks whether the user can access the URL based on the permissions that are assigned to the user’s roles.
If the user is allowed access to the URL, the plug-in returns control to the Web server so the server can process the HTTP request as usual.
If the user does not have permission to access the URL, the plug-in ends the HTTP request processing and redirects the user to an error page indicating access failure.
To perform access authorization, the plug-in must know exactly what to look for in the ACDB. If a given URL /A/B/C/D is not found in the ACDB, the plug-in searches in this order:
/A/B/C
/A/B
/A
When the URL is found, the plug-in checks access against the matching asset.
If a user does not have permission to access /A, but does have permission to access /A/index.html, the user must explicitly request /A/index.html to gain access to that page.
For example, let’s say you have a protected directory /ws_doc_root/DirA with these files in the directory: index.html, file1, file2, file3. You want to lock file1, file2, and file3 so that John cannot read them, but you want to give John permission to access index.html. Using Enterprise Security Manager, add the following URL assets:
/ws_doc_root/DirA /ws_doc_root/DirA/index.html
Then, assign READ permission to access /ws_doc_root/DirA/index.html to a role that John has. John can now access /ws_doc_root/DirA/index.html. If John tries to access /ws_doc_root/DirA/file1, /ws_doc_root/DirA/file2, or /ws_doc_root/DirA/file3, an access forbidden message displays in the browser.
If John tries to access /ws_doc_root/DirA or /ws_doc_root/DirA/, the plug-in determines that John does not have permission to access the directory and ends the request processing.
The security plug-in ignores the query string in
a URL when performing authorization checks. For example, to determine
whether /index.html?arg=value is
secure, the plug-in checks the ACDB for /index.html.
