> Date: Fri, 19 Apr 1996 12:04:18 -0700
> From: David Carrel <carrel@cisco.com>
> 
> > What is the justification for trying to use this "fbtab replacment"
> > as an extension for new authentication controls?  If you want to
> > have more control over how authentication is done, I think that
> > should be dealt with separately from the "fbtab replacment" on
> > the grounds of orthogonality.  (Unless somebody can show a good
> > reason why they should both be done by one mechanism - doubtful.)
> 
> Gordon,
> 
> Ahhh, now you're on territory that I am very familiar with.  But, please be
> careful with terms.  It is very important to separate authentication from
> authorization.  Authentication is the tast kf determining who a user is.
> Login alone should be responsible for that.  Authorization determines what
> get's done by who and how.  This whole thread is basically one of designing
> a versitaille authorization engine for login.  Basically this callout is

That was not my understanding.  I guess we first need to decide which
problem(s) we are trying to solve.  (i.e. What are the requirements?)

I thought we were trying to `provide a flexible way to do things like
change the ownership of "related devices" at login/logout time.'

It sounds like others want a different problem solved, that of
`allowing additional authorization checks at login time.'

The two problems seems quite separate to me.  The first one does
things that depend on what tty is involved but NOT what user is
logging in (the same action will happen for any user).

The second (authorization) problem typically depends on site
policy, where inputs to that policy may include a long list
of things as you have suggested.

Allowing extensions to the authentication and authorization policies
is a much more difficult problem, and it would really need hooks in
different (earlier) places in login to have full flexibility.
These same hooks are needed in places like su, ftp, ...

You might want to say that certain ttys have a "wide open" policy
(for the tty that is locked in the computer room) and that lines
with "wide open" policy never prompt for a password.  You might
want a very restrictive policy for other lines that says only
kerberos is an acceptable authentication method.  You might want
to have certain user IDs require stronger authentication...

Anyway, those are some of the reasons I believe we should deal
with these two sets of requirements with different solutions.

Gordon