Restricted pages
Control over who gets to see certain information or use a certain
service can be achieved in three ways; RXML, security patterns or
.htaccess files. All three ways have one thing in common, they make
use of an authentication module. The authentication module contains a
user database with user names, passwords and information about the
users. Challenger comes with three such modules, the User
database and security module, the SQL User
database module and the LDAP directory
authorization module.
In RXML, access control is achieved through use of the
<if> tag. It is possible to make a very fine-grained access
control system with this tag, since access to information on the
actual pages can be limited. See the If page in the Web Site
Creator manual for more information.
Security patterns are used to limit access to an entire module. For
example, it can be used to make sure only internal users can access
the Demo module.
.htaccess is a standard used by many web servers and can be used to
limit access to certain directories or files. It is implemented
through the .htaccess support module. More
information about .htaccess can be found in the security chapter in the "Web Site
Creator"-manual.
Security patterns
Security Patterns are one of the variables under Builtin
variables. They can be used to control who gets to access a
certain module.
If security patterns are not used, anyone can access the module.
Once a security pattern is entered only users who are matched by the
security pattern will be granted access.
The patterns are scanned from top to bottom. Each line contains a
rule with a pattern matching users who should be affected by the rule.
Rules
The rule determines what should happen in case the user or computer is
matched by the pattern. Should the request be denied or granted?
- accept
-
A user matched by an accept rule will be granted
access, unless she is matched by a deny rule further down. The
processing of patterns will continue, in order to determine if such a
deny rule exists.
- allow
-
A user matched by an allow rule will be granted
access. No further processing of the patterns is required.
- deny
-
A user matched by a deny rule will be denied
access. No further processing of the patterns is required.
Patterns
Each rule contains one of the following patterns, that are used to
match users that are to be affected by the rule:
- ip=IP/bits
-
Grant/deny access from a network, IP
specifies the network address, bits the size of the network. allow
194.52.182.0/8 will grant access to any machine who's IP-address
starts with 194.52.182.
- ip=IP:mask
-
Grant/deny access from a network, IP
specifies the network address, mask the subnet mask. allow
194.52.182.0:255.255.255.0 will grant access to any computer
whose IP address starts with 194.52.182.
- ip=pattern
-
Grant/deny access from a named network.
allow *.idonex.se will grant access to any computer who is
named something ending with idonex.se. * is used to match zero or more
letters while ? matches only one letter.
- user=username
-
Grant/deny access to a specified user.
The user will be authenticated using the authentication module or
.htaccess password file. This option is usually silent, that is, a
user will not be prompted for a user name and password if she fails to
authenticate properly.
user=any will grant/deny access to anyone with a valid
account.
Example
allow user=any
allow ip=194.52.182.0/8 |
Will grant access to any user who is authenticated or comes from
the network 194.52.182.0.
.htaccess support
Support for NCSA/Apache .htaccess files. See the security chapter in the "Web site
Creator"-manual for information about how to use .htaccess files.
- Cache the failures
-
This causes the .htaccess
support module to remember where it failed to find a
.htaccess file. This improves performance significantly, but users
must do a reload to get a new .htaccess file to take effect.
- Deny file list
-
Files to which access will always be
denied, no matter who tries to access them. Usually .htaccess related
files are protected this way to make it impossible for an external
user to get any information about how the access control system works.
User database and security
This module fetches user account information from the operating
system's user database. It is used when the users that should have
access to the web server already have accounts on the system.
This module must be used for modules enabled if the CGI scripting
support module or the Pike script support module are to
be able to run scripts as the user who owns the script.
Variables
- Password database request method
-
How to get account
information from the operating system. Choose one of the following
options:
- ypcat
-
Use the ypcat program. For systems that
use yp.
- file
-
Read accounts from the password file specified
in the Password database file variable.
- shadow
-
Read accounts on a system that uses shadowed
password files. You need to specify a password file in the
Password database file variable as well as a shadow password
file in the Password database shadow file variable.
- niscat
-
Use the niscat program. The same as
ypcat for Solaris systems, where yp has been renamed nis.
- getpwent
-
Use the system call getpwent to get
user information. This will work on all systems, but is slower than
the other methods.
- none
-
Don't import any user account information. Let
any username through no matter what password was submitted.
|