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

Access Control In Sun Java System Web Server 7.0


You can now download Sun Java System Web Server 7.0 for FREE from http://www.sun.com/download/index.jsp?cat=Web%20%26%20Proxy%20Servers&tab=3&subcat=Web%20Servers .

What Is Access Control?

Access control allows us to determine and manage

  • Who (subject) can access the resources
    on our web
    site
  • Which resources (like files or
    directories) 
    they can access
  • Which operations can they perform (like creating a file, POST-ing
    contents to the server).

We can allow or deny
access based on:

  • Who is making the request (for
    example, user or group
    using user, group
    attributes).
  • Where the request is coming from
    (for
    example, host or IP using ip, dns
    attributes).
  • When the request is happening (for
    example, time of day or day of week using timeofday, dayofweek
    attributes).
  • What type of connection is being used
    (for example, SSL using ssl
    attribute).
Authentication is the process
of acquiring and verifying the attributes of
the subject which help to identify the subject. For example,
authentication may involve prompting the user to login with a username
and password, and then looking in a database to verify that the user's
password is correct.

Authorization is the process of
checking the rights (or permissions) to the server resource that are
allowed for the subject. for example, a subject might be allowed read
access but not write access to a server resource.


An access control entry (ACE)
specifies the rules for accessing a given server resource. There are
two kinds of ACEs
  • Authentication ACE
    defines how subject(who is making the request) is identified. It can be
    used to set authorization
    method (Digest, Basic, SSL) or database names (like default, myldap,
    mykeyfile).
  • Authorization ACE defines
    the rights allowed or denied for a particular subject or a group of
    subjects.
ACL (Access Control List) is an
ordered list of ACEs. An ACL can contain both types of ACEs.

We can control access
to the entire server or to
parts of the server,
or the files or directories on our web site. 
When the server gets a request for a page, the server uses the rules in
the ACL file to determine if it should grant access or not. We create a
hierarchy
of
rules (called ACEs) to allow or deny access.
Each ACE specifies whether or not the server should check the next ACE
in the hierarchy. The collection of ACEs we create is called an access
control list (ACL).

Types Of ACLs

  • Named ACLs
  • URI (Uniform Resource Indicator)
    ACLs
    specify a directory or file relative to the server’s
    document root.
  • Path ACLs specify an
    absolute path to the resource they affect.
Path and URI ACLs can include wildcards
at the end of the entry. For
example: /a/b/\*.
Wildcards placed anywhere except at the end of the entry will
NOT work.

Examples of Named ACLs

Named ACLs are ACLs which have the
first line like acl
"<name>";
. It MUST
have a
corresponding check-acl
SAF entry in obj.conf. For example, named acl default or named ACL dav-src  for WebDAV
requests we add in Object named dav.

#default.acl

version 3.0;
acl
"default";

authenticate (user, group) {
  prompt = "Sun Java
System Web Server";

};
allow (read, execute, info)
user = "anyone";

allow (list, write, delete)
user = "anyone";

...
acl
"dav-src";

deny (all) user = "anyone";


Named ACL default 
has a corresponding check-acl
SAF in obj.conf.  Named ACL dav-src
has a corresponding check-acl
SAF in obj.conf.

#obj.conf

<Object name=default>

...

PathCheck fn="uri-clean"
PathCheck fn="check-acl"
acl="default"

...
</Object>

...

<Object name="dav">
PathCheck fn="check-acl"
acl="dav-src"


Service fn="service-dav"
method="(GET|HEAD|POST|PUT|DELETE|COPY|MOVE|PROPFIND|PROPPATCH|LOCK|UNLOCK|MKCOL)"

</Object>

Examples of URI based ACLs

URI based ACLs start with uri= prefix.
We can set ACLs for a particular resource or a directory and resources
inside it. For example, we can set URI based ACL for a particular file file.html

#default.acl
....
acl
"uri=/dir1/file.html";

authenticate (user,group) {
  method = "basic";
  database = "myldap";
};
deny (all) user = "anyone";
allow (all) user = "beta";


For setting a URI based ACL on a directory and all the files inside
that
directory, we can set ACEs like

#default.acl

...
acl "uri=/dir1/\*";

allow (all) dns=".sun.com";
Or
#default.acl

...
acl "uri=/dir1/";

deny (read) user="anyone";
allow (read) group="premium" and
dayofweek="Sat,Sun";

Example of Path based ACLs

Path based ACLs start with  "path="
prefix.

#default.acl
...
acl "path=/opt/Sun/Servers/docs/index.html";
deny (read) user="anyone";
allow (read)
timeofday<0800 or timeofday=1700;



The URI or path that preceeds the wildcard does NOT work properly if
the URI or path information is not a directory but is, instead, a file.
For example, the following ACL settings work. When /test/README is accessed,
access is allowed only for the user abc.

#default.acl

...

acl "uri=/test/\*";

authenticate (user) {

  prompt = "Test ACL.";

};

deny (all) user = "anyone";

allow (all) user = "abc";


But, the following ACL settings do NOT work. When /test/README is accessed the
request is allowed to everyone.

#default.acl

...

acl "uri=/test/READ\*";

authenticate (user) {

  prompt = "Test ACL.";

};

deny (all) user = "anyone";

allow (all) user = "abc";


Only tailing "/\*" is supported in ACL
file. ACLs with patterns XX\*, \*XXX\* are ignored. For such scenarios, declare it as a named ACL in obj.conf. For example,

#obj.conf

...

PathCheck fn="check-acl" fn=check-acl path="/pathtosomedir/tes\*.html"
acl="acl123"

...
Or
#obj.conf

...

<Object ppath="/pathtosomedir/tes\*.html" >

PathCheck fn="check-acl" acl="acl123"

</Object>


\*\* Note that check-acl usage has a limitation as ACLs are cached in memory. As long as the same ACLs are applied for a resource it is ok. You can not use check-acl for the case where different ACLs are supposed to be added for different condition. For a particular resource we have in obj.conf ,
<If $client-ip="1.1.1.1"> PathCheck fn="check-acl" acl="acl123" </If> it may or may not add this ACL depending on client's ip address. To make it work we have to disable acl-cache in server.xml (in Web Server 7.0 onwards).



One tip, whenever you want to set an ACL to allow access of a resource to a small audience, first add a deny ACE that would restrict the whole audience from accessing the resource and then add specific ACEs to allow access to the resource to the smaller audience.
Something like
#default.acl

...

acl ...

deny (all) user ="anyone";

allow (all) user="alpha,beta,gamma";

Or if you want to add allow ACE first use "absolute" keyword.
#default.acl

...

acl ...

allow absolute (all) user="alpha,beta,gamma";

deny (all) user ="anyone";

Refer my next blog for more information about this.

Join the discussion

Comments ( 5 )
  • guest Friday, November 2, 2007

    Thank you for the information! Wonderful.


  • Darren Tuesday, October 7, 2008

    If I am adding a uri-based acl, for instance:

    acl "uri=/temp/test1/test2/\*";

    allow (list, read, execute, info) user = "anyone";

    Do I need a corresponding SAF in the obj.conf? I have done some testing and it seems to work as expected without one.

    BTW, this is a great blog, I use it frequently.


  • Meena Tuesday, October 7, 2008

    No, you need not add SAF for uri or path based ACLs only name based ACLs needs check-acl SAF to be added in obj.conf.

    Thanx for using our Web Server and using my blogs. If you need information on anything else let us know in our Forum http://forums.sun.com/forum.jspa?forumID=759


  • ivo Wednesday, January 14, 2009

    thank you for informations, very helpfull!

    is there a CLI or WebInterface to add the PathCheck to the obj-conf?


  • meena Wednesday, January 14, 2009

    I am not good in Admin area. In Web Server 7.0, you can manually modify ACL file (and other configuration files) and do a pull-config from Admin CLI/GUI.


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