Am So 30.Juni 2002 17:01 schrieben Sie:
> Is it possible for passport to store ACLs for the user as well - and if
> so, how configurable is this? Currently, my class assumes that access
> rights are stored in the same data container as the user information
> itself (name, password, email adress ...). If Passport doesn´t allow to
> store access rights as well, a driver class for it could mean that
> there´s a need to split rights management from actual authentication,
> which would be a major drawback.
For a clean implementation you would need to split authentication and
authorisation anyway. Literature distinguishes Identification, Authentication
and Authorisation as different phases of a login. In the identification phase
a user identity (a unique name or token, usually called "principal") is
determined. In the authentication phase this princial is being validated,
usually by knowledge (knowing a password, for example), by possession (of a
certain cookie, of a chipcard, or another item) or using individual
characteristics (using biometrics).
After authentication, the validated principal is being authorised, where
authorisation comes from a rights matrix.
The rights matrix may be twodimensional (with (user, object) pairs, in
operating the objects are often filenames) or threedimensional (with (user,
tool, object) tuples, where a tool is often a program, and objects are files,
again. Threedimensional access is being simulated with twodimensional access
matrices in Unix using SUID binaries and with two passes through the
twodimensional matrix.). Depending on where the access rigths are stored, you
get vertical or horizontal slices through the rights matrix: In one case,
access rights are stored with the objects, giving a permission system with
ACLs as in Unix or Windows NT. In the other case, access rights are stored
with the principals as in PHPLIB or Windows 2000 group policies, giving a
capabilities system. A more detailed explaination of all this and much more
can be found in
http://www.amazon.de/exec/obidos/ASIN/0471389226/kristiankohntopp ("Security
Engineering", Ross Anderson, Wiley & Sons, 0471389226, €74.65)
My point is that identification, authentication and authorisation are
different things, and should be implemented in such a way that they can come
from different sources. Let me explain, but first let me introduce some
vocablary in order to identify the parties involved.
PEAR is the code provider of a kind of passport system (PEAR::Passport). The
actual database with user data is being run by many different PASSPORT DATA
SOURCE PROVIDERS (PDSP). There probably is a central PASSPORT REGISTRY (PR)
which lists all PDSPs known to PEAR::Passport.
Some Developer uses PEAR::Passport to implement some means of login on a site.
An end user logs into this site, and PEAR:Passport queries one or multiple
PDSPs for user information.
PEAR::Passport needs different modes of operation, of which I can see at least
three, with two of them being actually useful. A pure identification mode
would identify the user by querying PDSPs for the required user information,
but would not do any authentication or authorisation. Such a mode simply
saves a lot of typing for the end user, as the site can present a properly
filled out login, delivery or order form to the end user, which the end user
just checks, and validates by typing in some password. The password and the
authorisation data would not come from a PDSP in this case, but would be
provides locally to PEAR::Passport.
I imagine that this is the most common use of PEAR::Passport for order and
shop systems, as most shop owners would be very reluctant to share actual
order data or even customer lists with some arbitrary remote registry. Also,
since only identification data is being shared, but transaction are not
authorised from the PDSP without manual, local user interaction, not much
trust is being placed into PEAR::Passport. Trust is being put into the PDSP,
see privacy options below, and trust is being put into the site, see privacy
below, again.
A second mode of operation would be idenfication and authentication. Here,
PEAR::Passport transparently logs in an end user coming to this site from a
remote location. The user is on the site with an identity, but is not
bothered with login forms. Authorization comes from a local data source, and
may even be bypassing PEAR::Passport, as authorization is often very site
specific (see PHPLIB::Perm for a very bland and stupid, but reasonably
flexible capability system -- I have described more sophisticated system
using properly normalized groups and permissions on the PHPLIB mailing list).
Here, PEAR::Passport is trusted with the entire yes/no decision of letting
users into the site, thus the class operates at a higher trust level.
The third mode of operation I cannot see in deployment very often. This is
where the PDSP also provides authorisation data, which would most often have
the form of "has an account with us, and that account covers the transaction
value of €x you request. Since in this case actual money is moved (within the
PDSP, from the end users account to the site owners account, or even between
PDSPs) that would require a great amount of trust to be placed into the PDSP
and the PEAR::Passport implementation.
Regarding privacy, it is clear to me that PEAR::Passport cannot stand alone.
It needs a supporting application or infrastructure at the PDSPs side. Users
putting personal data into a PDSPs data vault should be able to get
transaction journals from the PDSP (what data has been handed to which site
for what purpose at what point in time?) and should be able to determine
which sites shall get what information.
Also, a PDSP should be able to handle multiple identities (principals) and
data sets for the same person, allowing for different pseudonyms. My former
wife Marit Hansen, who works with the local privacy commisioner and is part
of the P3P team, has a number of papers on identity management on her site.
You might want to have a look at
http://www.koehntopp.de/marit/pub/anon/Anon_Terminology.txt,
http://www.koehntopp.de/marit/pub/anon/Anon_Terminology.pdf, for definitions
of the terms and concepts related to that
(http://www.koehntopp.de/marit/pub/idmanage/index.html is the parent page of
that paper).
Kristian
--
http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
|
