new authentication format coming; please read and comment

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm about to start work on porting a per-domain
authentication system to the
trunk.  Jacob Leaver and I had been working on this in the
midst of the stats
branch modifications that I then put on hold while
finalizing Maia 1.0.

I want to give everyone a heads up on what it does, and see
if there are any
aspects that I have missed.  The purpose is to allow each
domain to authenticate
 in its own way, and to provide more flexibility to the
address rewriting mess.

All authentication configuration will be moved to the
database, except for one
item. This configuration will be available to the admin via
web interface.

Since all authentication will be indexed by domain, it is
generally necessary
for logins to be the full email address.  This makes sense
for any installation
that has more than one domain. To facilitate some
installations where only the
username is used to log into Maia, a config item in
config.php ($default_domain)
may be used to tack onto the username, which will then allow
the login to be
routed to the correct authenticator.

Allow me to digress into a bit of technical stuff...
Previously, the login
username was matched against the maia_users table.  If there
was no match, it
would fall back to the users table, and update the
maia_users table to match the
login name.  Or something like that... I really don't like
the way it does that,
because it seems to change a maia_user entry to just a
username, even when
multiple domains are in use. Also, get_user_id() modifies
the database, which
seems like a big no-no to me.  get functions should not have
side-effects.  So
as part of this discussion, I'd appreciate it if anyone
sees something bad about
modifying this function.

So... to correct this, we made a patch in stats branch to
simply query off the
users table and return back the maia user associated with
it.   What this is
supposed to mean is that you can log in with any of the
email addresses
associated with your account, and still end up in the same
maia account.  This
alone doesn't solve the problem of automatically assigning
aliases to an
account, but it may make it easier... more on that later.

Now on to the good stuff.  Authentication mechanisms will be
defined on a
per-domain basis, with a web interface available to the
admin.  It will also
allow fall-through to other methods, and even the
system-wide (.)
authenticator.  Authentication methods can return one of
ACCEPT, REJECT, or DUNNO;

The checks are listed in the order they should be checked,
and if one of the
returns REJECT, then processing is stopped right then. DUNNO
means it was
inconclusive, and fall through to the next authenticator. 
This allows a domain
to have multiple methods specified.  ACCEPT is kinda
pointless as a failure
mode, other than to simply enable all logins.... but hey,
that can be useful
when IMAP crashes or something. 

Next, how to handle all the weird address rewriting stuff. 
This has been a
sticky situation in the past, and has been the cause of much
confusion and angst.

Each authenticator will have listed with it optional PRE and
POST regex filters.
 This will allow the admin to specify a tranformation filter
to make it match.
for example, if I have this right,  a user logs in as
userexample.com, and has
a filter of /$1_$2/ will cahnge it to user_example.com.  I
have to root around
in the code a bit to get the exact syntax that we had set.

The general idea is that a PRE filter changes the login name
to match the
correct form to send to the authenticator method.  It then
authenticates.  If
the authentication fails, it responds with whatever is
configured for this
mechanism's failure mode: ACCEPT, REJECT, or DUNNO.

If it succeeds, it then passes through an optional POST
filter.  Some
authenticators can return a rewritten address, such as ldap,
and others can't,
such as imap.  The POST filter is applied to either to the
original login form
or to the returned form as needed.  This is changes the
login form into the way
it is listed in the users table, which is then passed to
get_user_id() as
discussed above.  (Yay! I tied it back to the start of the
discussion!)

Finally, the fact that some login forms can return a
modified address means the
return value could possibly be an array of addresses, which
could all be linked
together into one maia user, automatically.

I think we had all of this actually working in the stats
branch; I want to
extract it and port it to the trunk. (I'm also extracting
the per-user stats
from that branch, but that's another email)

In addition, it just occured to me that it may be possible
to have multiple POST
filters which would then return an array of addresses and
thus we could
auto-link imap sources too. Greg Woods, this may be very
good for you. 

That was a lot of new information, and that's my first
attempt to document it.
It also just helped me get my mind around what all the
changes are, so thanks
for letting me sound off  y'all.  Does that
make sense?  Any questions, comments?

- --
David Morton
Maia Mailguard                        - http://www.maiamailguard
.com
Morton Software Design and Consulting - http://www.dgrmm.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFEmDvNUy30ODPkzl0RAi7UAKC9JHScNmqC4enS5xjCYUaW6nI70gCf
bmyB
/0bzqvW6smccjv/4IRiA9kc=
=jU7M
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

On Tue, 2006-06-20 at 13:17 -0500, David Morton wrote:

> In addition, it just occured to me that it may be
possible to have multiple POST
> filters which would then return an array of addresses
and thus we could
> auto-link imap sources too. Greg Woods, this may be
very good for you. 

It's not clear to me why you mention me in this context,
but I presume
it is because I was the one who wanted to be able to write a
customized
authentication method (now known as auth_external). In fact,
we are
pretty much a single-domain shop. We do have a few auxiliary
domains
that accept a small amount of mail, and those domains have
administrators, but the majority of our mail is through one
domain. I
think it likely that we would continue to use a single
authentication
method even if you do implement the PAM-like system you
discussed.

What I use external authentication for is to permit
sysadmins to
authenticate as users under their jurisdiction without
allowing them to
log in as anybody else's users. Certain master users (like
me) *can* log
in as anybody. Who is authoritative for which users is
controlled by
information in our LDAP database, but we are not allowed for
security
reasons to store actual passwords in LDAP (the protections
are too
weak). And even if I could, it wouldn't meet the above
requirements to
use simple LDAP authentication

We have a central authentication server where all usernames
and
passwords are stored, and I wanted to hook this into our
Maia system (so
that users wouldn't have yet another password stored in yet
another
database). All of this is way too complex and way too
dependent on the
particulars of our environment here to try and modify the
Maia code to
use it, so I settled for modifying the PHP scripts to permit
calls to an
external program to do the authentication. That program can
look up the
username and the divisional affiliation of the user, and it
can accept a
password of the form "%sysadmin%password", and
if the sysadmin has a
role field that matches the divisional affiliation field for
the user,
and if "password" is the correct password for
user "sysadmin", then the
authentication is allowed. Users can also authenticate
directly with
their own username and password. In other words, as sysadmin
can
authenticate as one of his own users without knowing the
user's
password, using the *sysadmin's* password provided in a
special format.

The problem we have is that our user sophistication level
runs the full
gamut. We have experienced web programmers as users, who
love to tweak
every setting. We also have some administrators on Windows
boxes who
know how to use Microsoft Office and that's the extent of
their computer
knowledge. But those people still get spam and viruses, so
we wanted
their sysadmins to be able to set up Mailguard for them. Our
user base
is just a little bit too big for the super-administrator to
do this kind
of stuff for every user, so we needed the local division
systems staff
to be able to help out.

--Greg


_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greg Woods wrote:
> On Tue, 2006-06-20 at 13:17 -0500, David Morton wrote:
> 
>> In addition, it just occured to me that it may be
possible to have multiple POST
>> filters which would then return an array of
addresses and thus we could
>> auto-link imap sources too. Greg Woods, this may be
very good for you. 
> 
> It's not clear to me why you mention me in this
context, but I presume
> it is because I was the one who wanted to be able to
write a customized
> authentication method (now known as auth_external). In
fact, we are
> pretty much a single-domain shop. We do have a few
auxiliary domains

Yes, but what I was looking at specifically was the regex
part, because it may
help to rewrite it to some other styles.  Maybe not. I could
be confused with
someone else; I just remember that you had the most esoteric
authentication system.

I see that there is an external authenticator in this source
tree, so that's
good so far. 

I think this will still provide a more flexible framework
for you.  For one
thing, the fall-through ability will help with letting the
admin log in as anyone.

Also, another facet of this new format makes it extremely
simple to add new
authentication types; just drop a file into the auth/
folder.  So if neded, one
could copy the ldap authenticator and modify it a little bit
to return what you
need.

I guess I didn't mention that in the other doc. This new
format is very modular.


- --
David Morton
Maia Mailguard                        - http://www.maiamailguard
.com
Morton Software Design and Consulting - http://www.dgrmm.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFEmFvQUy30ODPkzl0RApycAJ9zChleF4ySVtADWWM8R9qiaim+VACf
fXw5
tAMxyJBUAGWl0y6CRjSKaNo=
=hx2F
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

David Morton a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>   
--snip

This new way seems to be very flexible.

But, I didn't see any words about rights, sysadmin rights
and domain 
administrator rights.
And multiple account that share some email addresses should
be nice too; 
example is generic addresses (info, support, ...). Thoses
adresses are 
often read by more than one user, maia interface should be
able to do it 
too.

At last word, we are now in the process to integrate maia in
a full 
website, where client will authenticate once, then should
have access to 
all tools (maia, webmail, ticket account, ...). The new
authentication 
scheme should also let open to this kind of application
(cookies ??)

Anyway, thanks for sharing your ideas, and make this great
product.

--Alexandre
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users