On Wed, 10 Jul 2002, William A. Rowe, Jr. wrote:
> On Wed, 10 Jul 2002, Pier wrote:
>> ...
> Very cool.
>
> Are you also considering multiple 'user' identities? E.g., If I'm using client
> cert ssl auth [one identity], with basic encryption [a different identity], it
> would be nice to walk the 'identities' list.
>
> In that, you could have several types of 'identities' in a list, e.g. 'user',
> 'group', 'role', etc. The IP and DNS of the client themselves are also
> 'identities', although they are addresses.
I've done some commercial systems in the past which used a token based
evidence scheme. Which worked very well with apache and whcih allowed very
quick integration with apache/per-user-custimization and so on. I.e. along
the lines of:
connection->request-> [ token1 ]
[ token2 ]
...
where the list of tokens would a) increase as the request was more and
more authenticated and b) where the list of tokens collected could
be cached across requests under certain conditions.
tokenX -> value (*)
[ fact1 ]
[ fact2 ]
....
fact1 -> Username 'foo'
...more key valye pairs
evidence -> evidence3 (*)
fact2 -> Password '123'
...more key valye pairs
evidence -> evidence3 (*)
fact3 -> Group 'admins'
..more key valye pairs
evidence -> evidence3 (*)
-> evidence4
fact4 -> Group 'plumbers'
..more key valye pairs
evidence -> evidence3 (*)
-> evidence4
fact5 -> address, contract number
fact6 -> SIM card # of WAP-ing phone
fact7 -> background colour preference
fact8 -> 1200 airmiles and a gold pass
evidence3 -> Source BasicAuth (*)
Date (int) (*)
Expires (int) (*)
Use (flags) (*)
evidence4 -> Source /etc/group (*)
Date (int) (*)
Expires (int) (*)
Use (flags) (*)
key1 value1
key2 value2
key3 value3
key4 value4
key5 value5
Note: evidence is not recursive; i.e. evidence itself
is not based on evidence. Which may have been
a mistake. But instead something like a GroupAuther
would insist of evidence from BasicAuth (or other
constrained vocabulaire Source values) to be
present before it would run (another problem with
ordering here!).
Note: The entries marked '*' are mandatory and have
a controlled vocabulare/value set. The
rest are simply ascii-key and UTF8 value pairs.
Note: The USE flag was not really used - see below.
It worked quite well from the side of the admins and the folks who had to
configure the webserver/radius/tacacs and the systems which integrated
with SS7 telephony layer and the API into the communication with SIM
cards. I.e. they could express what sort of controls they wanted for a
specific directory or something (and some of those where time/resource
consumption depended) and found it easy to extract audit data. Or map out
who was responsible for bad data/deceisions when, say, a complaint came
in that some unwarranted transfer was done.
But... though easy - it was a very 'inefficient' to program modules
against. And occasionaly let to 'storms' of requests to auth backends for
something as silly as fetching a transparent gif spacer.
I.e. when you had to check a 'require' this-and-this property then you had
to go through the whole token->fact (if it is my type)->value sequence for
all the tokens collected.
It was found hard to optimize with, say, a per user property table due to
lot of overlap in KEY values but with different meanings and/or evidence.
Often one set of evidence was required before another set could be based
upon it. E.g. IP address -> Dail-in modem bank slot -> CallerID of calling
line -> entity-which-has-the-phone contract for that physical line.
This lead ultimately to a scheme where one would check for the presence of
a top level token (i.e. has this request got the 'foobar' token) and with
that in handl allow access into the over-18-only gambling site or collect
your airmiles site.
The use flag indicated if evidence could be kept cross request or even
across different servers based on a crypto cookie, SSL info, etc. But over
time the 'use' style flag was used less and less; and rather evidence was
simply destroyed or made inaccessible itself - and the code would detect a
dangling reference and not follow it (at the cost of a cheap in memory
berkely db lookup). I.e. rather than say 'this evidence can only be used
on properly SSL authed connections' one would say - only provide this
evidence to this webserver instance or this set of directories which we
know only allow SSL authed connections in.
There are some paralels with SAML as it is beeing proposed now - and I see
similar problems.
But it sure would be nice to have a ->notes table which is a bit more
fancifull and an apache which has a bit more of a registry behavour when
it comes to registering and coordinating controlled values (or per module
namespaces, etc).
Dw
