Access Control In Sun Java System Web Server 7.0 - II

Access Control In Sun Java System Web Server 7.0 -II

After my first blog about Access Control in general, let me try to talk about some more ACL related topics.

Access Rights in Access Control Lists in Sun Java System Web Server 7.0

Access rights that can be used to set access control in ACL file in Sun Java System Web Server 7.0 - are
  • all
  • read
  • execute
  • info
  • write
  • list
  • delete
  • http_<method>
  • dav:read-acl
  • dav:read-current-user-privilege-set
If we want to grant write,delete,list rights ONLY to authenticated users but grant read, execute, info rights to all users (authenticated as well as unauthenticated users), we need to have an ACL like.

#default.acl
...

acl "default";
authenticate (user, group) {
  prompt = "Sun Java System Web Server";
};
allow (read, execute, info) user = "anyone";
allow (list, write, delete) user = "all";

This is already set by default in <WS_INSTALLATION_DIR>/https-<servername>/config/default.acl file.

If we want to grant write,delete,list access to a set of high privileged users only (users alpha,beta and gamma) and grant read,execute,info rights to ONLY authenticated users, set the following ACL in <WS_INSTALLATION_DIR>/https-<servername>/config/default.acl file in the end.
(We can also add this in that Virtual Server's ACL file if we are using multiple virtual servers.)

#default.acl
...
acl "uri=/"
deny (all) user="anyone";
allow (read, execute, info) user = "all";
allow (list, write, delete) user = "alpha" or user = "beta" or user = "gamma";

Note that the first ACE (ACE starting with deny)  MUST BE added. It denies all rights to "anyone" i.e. all users (both authenticated and unauthenticated users).
Second ACE,  grants read,execute and info rights to authenticated users only.
Third ACE,  grants list, write, delete rights to alpha, beta or gamma only.

Instead of adding individual users, we can also create a group (lets say "premium") in authentication database and add these three users  alpha, beta and gamma in the group. The new ACE will be

#default.acl
...
acl "uri=/"
deny (all) user="anyone";
allow (read, execute, info) user = "all";
allow (list, write, delete) group = "premium";

Mapping between rights and HTTP Methods

Rights
Maps to HTTP Methods
read
GET, HEAD, TRACE, OPTIONS, COPY, BCOPY
write
PUT, MKDIR, LOCK, UNLOCK, PROPPATCH, MKCOL, ACL, VERSION-CONTROL, CHECKOUT, UNCHECKOUT, CHECKIN, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY, BPROPPATCH
execute
POST, CONNECT, SUBSCRIBE, UNSUBSCRIBE, NOTIFY, POLL
delete
DELETE, RMDIR, MOVE, BDELETE, BMOVE
info
HEAD, TRACE, OPTIONS
list
INDEX, PROPFIND, REPORT, SEARCH, BPROPFIND
Note that to get directory listing we need "list" rights.
Note that we have HEAD, TRACE and OPTIONS map to both read and info rights.
\* Will discuss dav:read-acl and dav:read-current-user-privilege-set  later.

We can also set these http_<method> into ACL file for finer access control.

#default.acl
...
acl "uri=/dirGETNotAllowed";

authenticate (user, group) {
  database = "mykeyfile";
  method = "basic";
};
deny (http_GET) ip = "123.45.\*";

ACL Evaluation

The server goes through the list of ACEs to determine the access permissions. Attribute pattern anyone means all users. If that ACE's attribute is user or group and it does NOT contain pattern anyone, the server first authenticates the user. The first ACE is evaluated and it denies/allows access to the current user. The server then checks the second ACE in the list, and if it matches, the next ACE is used. The server continues down the list until it reaches the end or it reaches an absolute ACE\*. The last matching ACE determines if access is allowed or denied.
\*absolute ACE is an ACE that contains absolute keyword.

Lets take the example of a simple ACL file and lets see how they are effective for some requests.

#default.acl
version 3.0;
acl "default";
# call it ACE#1
allow (read, execute, info) user = "anyone";
# call it ACE#2
allow (list, write, delete) user = "all";
...
acl "uri=/file.html";
# call it ACE#3
deny (info) user = "alpha";

Request
Server reads ACEs from ACL file
Server Evaluates ACEs in this order
Result
HEAD /
Reads all ACEs containing "all", "read", "http_head" and "info" rights applicable for this resource.

(It reads ACE#1 in the ACL file above)
ACE#1 is evaluated, operation is allowed. HEAD request is allowed.
GET / or GET /file.html
Reads all ACEs containing "all", "read" and "http_get" rights applicable for this resource.

(It reads ACE#1in the ACL file above)
ACE#1 is evaluated, operation is allowed. GET request is allowed.
HEAD /file.html as user alpha Reads all ACEs containing "all", "read", "http_head" and "info" rights applicable for this resource.

(It reads ACE#1 and ACE#3 in the ACL file above)
  1. ACE#1 is evaluated, operation is allowed.\*
  2. ACE#3 is evaluated, operation is denied (for alpha).
HEAD request is denied.
HEAD /file.html as user beta
  1. ACE#1 is evaluated, operation is allowed.\*
  2. ACE#3 is evaluated, operation is allowed (for beta).
HEAD request is allowed.
HEAD /file.html\*\*
  1. ACE#1 is evaluated, operation is allowed.\*
  2. ACE#3 is evaluated, operation is denied (for unauthenticated users).
HEAD request is denied.
\* It continues to the next step as "absolute" keyword is not found.
\*\* Although we do not have any deny ACEs for "anyone" (unauthenticated users), having a deny or allow ACE for a particular user implicitly denies access to unauthenticated users.

Absolute ACE

ACL Evaluation stops if an "absolute" ACE is found. For example if we have ACEs like

#default.acl
version 3.0;
acl "default";
# call it ACE #1
allow absolute (read, execute, info) user = "anyone";
# call it ACE #2
allow (list, write, delete) user = "all";

acl "uri=/file.jsp";
# Call it ACE #3 is ignored
deny (info) user="all";
...

For HEAD request for /file.jsp, request is allowed for all users even though ACE#3 sets a deny.  During the evaluation of ACE#1 as it encounters absolute keyword, it never evaluates ACE#3 and other ACEs below it.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

Meena Vyas

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today