X

Blogs about Deep Learning, Machine Learning, AI, NLP, Security, Oracle Traffic Director,Oracle iPlanet WebServer

  • May 16, 2006

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.