home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Spezial
/
SPEZIAL2_97.zip
/
SPEZIAL2_97.iso
/
ANWEND
/
ONLINE
/
SREFV12J
/
ADDPRIVS.DOC
< prev
next >
Wrap
Text File
|
1997-02-28
|
7KB
|
159 lines
Description of SRE-Filter's "additional, dynamic" privileges. 11/96.
The "SEL-specific" access control facility of SRE-Filter is based on
matching "client privileges" to the "resource privileges"
list associated with the "request selector". This document describes
this process, with a focus on the use of "additional, dynamic" privileges.
In short: Privileges are granted to a client through several
"static" mechanisms, and a dynamic mechanism.
These privileges are compared against the "resource
privileges" list.
A) Static client privileges
Assignation of static client privileges is a multi-step process:
i) OWNERS (with IP addresses specified in the OWNERS variable)
are granted SUPERUSER privileges
ii) Clients with an IP address that matches (possibly using wildcards)
an INHOUSEIPS. stem variable are granted INHOUSE privileges, and
are granted privileges contained in the matching INHOUSEIPS. entry.
Actually, they are granted the priviliges listed in the
INHOUSE_PRIVS variable (by default, INHOUSE_PRIVS="INHOUSE")
iii) If neither i or ii apply, then USERS.IN file is examined. USERS.IN
contains, on a username/password specific basis, a privilege list.
If this step is required, the client may be sent an authorization
request (depending on whether an authorization request header
was recieved).
iv) Everyone (who is given logon access) is granted privileges
in the PUBLIC_PRIVS variable.
v) If ADD_USER_NAME='YES', then the "username" (or first portion of
an INHOUSEIPS. IP address) is added to the client privilege list.
For a given client, static privileges are always the same. In contrast,
dynamic privileges are granted on a short term basis, perhaps as a function
of transient events. But before describing dynamic privileges,
a few words on "resource privileges" are in order.
B) Resource Privileges
Regardless of the source of each of a client's privileges, SEL-specific
access control requires that the resource privileges are satisfied
by the client's privileges. This "satisfaction" is based on two tests:
i) Any of the "ONE_OF" resource privileges are satisfied
ii) All of the "MUST_HAVE" resource privileges are satisfied.
Basically, the ONE_OF resource privileges are "or" conditions, and
the MUST_HAVE are "and" conditions. Satisfaction of all the
MUST_HAVE resource privileges is a necessary, but not sufficient,
condition -- at least one of the ONE_OF resource privileges are required.
Note: if there are no ONE_OF conditions, it is assumed that the
"ONE_OF conditions are automatically satisfied" (the same can be
said if there are no MUST_HAVE conditions).
As an aside:
The "resource privileges" are determined using:
"SEL-specific" entries, and
"REALM-specific entries"
in the ACCESS_FILE (see ALL_FILE.CTL for details).
In addition:
If ADD_RESOURCE_NAME='YES', the "action" portion of the
"request selector" is added,
(the "action" portion is the part of the request selector before
the first ? character).
Thus, a request selector of STARS/RIGEL.HTM would yield a "resource
privilege" of STARS/RIGEL.HTM.
C) Dynamic Client Privileges
Now, let us consider dynamic privileges. The notion underlying
dynamic privileges is that one might wish to grant conditional
access to server resources, where the condition is a function of
recent history. For example:
i) you want clients to fill out a registration form before giving them
access to a set of data files, with the registration good for a limited
time span (say, 30 minutes).
ii) you wish to enforce a particular order in viewing linked
documents, with no "skipping ahead".
iii) you have an images archive you're happy to give away, but
you don't want lazy websters to include links to these images
in their web pages.
All these cases can be easily handled through the use of dynamic privileges.
Dynamic privileges are granted by adding entries to a "dynamic privileges"
cache. To use this cache, you first have to make sure that the SRE-Filter
variable CHECK_ADD_PRIVS='YES'. This tell SRE-Filter to "store, and check,
additional privileges".
Assuming that CHECK_ADD_PRIVS='YES', entries can be added to the "dynamic
privileges" cache in two ways:
1) Inclusion of a <!-- INTERPRET FILE ADDPRIVS.RXX new_privs , duration -->
keyphrase in a server-side-include capable HTML document, where:
new_privs : a space delimited list of the "dynamic privileges" you wish
to add
duration : number of minutes these dynamic privileges will be
available.
Basically, for the next "duration" minutes the "new_privs" privileges
will be added to the "client privileges".
These dynamic privileges are cumulative -- the client
can accumulate a number of "dynamic privileges" by requesting
documents containing varying INTERPRET FILE ADDPRIVS.RXX statements.
2) Calling the SREF_ADD_PRIVS procedure from an external procedure.
SREF_ADD_PRIVS should be called as:
status=sref_add_privs(new_privs,duration)
Where new_privs and duration are as above.
In both cases, when the client makes a subsequent request, the
"dynamic" new_privs are added to her static privileges.
*** Actually, the dynamic privileges are based on the client's IP address.
*** Therefore, they can be assigned to any individual -- even if there is
*** no entry in SRE-Filter's username database for the client.
Note: for security reasons, a slightly modified version
of the new_privs are added -- the ADD_PRIVS_PREFIX is appended
to the front of the new_privs. This is done to prevent unscrupulous
individuals with limited access to your site (i.e.; the right to put
documents in "personal" directories) from subverting access controls by
sneakily requesting documents that contain:
<!-- INTERPRET FILE ADDPRIVS.RXX SUPERUSER ,1000 -->
D) Examples
An Example (assuming that ADD_PRIVS_PREFIX='!'):
Assume the following access-control entries (in ALL_FILE.CTL)
TEST/F1.HTM !P1
TEST/F2.HTM !P2
and a T1.HTM file which includes the statement:
<!-- INTERPRET FILE ADDPRIVS.RXX P1 , 10 -->
and a T2.HTM file with
<!-- INTERPRET FILE ADDPRIVS.RXX P1 P2 , 20 -->
A request for T1.HTM will cause a !P1 "dynamic privilege" to be added to the
client's privilege list (for the next 10 minutes). Within this time
period, a request for F1.HTM will be honored, while a request for F2.HTM
will be not.
On the other hand, a request for T2.HTM will enable subsequent access
(for the next 20 minute) to both F1.HTM and F2.HTM.
Notes:
i) SREF_ADD_PRIVS also can be called with extra arguments,
such as other IP addresses. The full form is:
status=sref_add_privs(new_privs,duration,verbose,port,
host_nickname,user_address,enmadd)
ii) The dynamic privileges are stored in _ADDPRIVS.80 (or .nnn,
where nnn is the server port) in the GoServe "working" directory.