Re: saslpasswd2 and virtdomains

Subject: Re: saslpasswd2 and virtdomains
From: Igor Brezac (igor at ipass dot net)
Date: Sat May 17 2003 - 14:52:16 EDT

On Sat, 17 May 2003, Jeremy Rumpf wrote:

> > >
> > > Please note, this is from a cyrus 2.1.x perspective. I have yet to start
> > > playing with cyrus 2.2. I'm also assuming that we put realms and domains
> > > into the same category. Hence, user at dom dot tld transposes into user=user
> > > realm/domain=dom.tld.
> >
> > domain != realm. saslauthd can put them into the same category, but
> > I do not think this is the right solution.
> >
> I agree, they are not the same thing, and that sometimes generates confusion
> :). It's an issue that probably would have to be handled on a mech by mech
> basis. Something like krb5 probably wouldn't have much problem with mapping
> the domain over to the realm, but PAM on the other hand would need some sort
> of intervention.
> > > Now the idea is to make saslauthd multi realm/domain aware. Currently
> > > saslauthd (primarily from an LDAP perspective) queries a single server
> > > regardless of the realm/domain specified during the authentication. In
> > > addition, saslauthd can only use one mechanism per instance. Ie. using
> > > either LDAP, krb5, etc. but not all or any combination of the available
> > > mechanisms.
> >
> > I like this idea. However, I think the biggest obstacle for the virt
> > support is the underlying auth mech. Most of them do not support
> > usernames in the form of an email address, pam and shadown come to mind.
> Since you brought that up, I've been wasting a few brain cycles on it. Perhaps
> it could be something configurable so the admin could somewhat tailor it to
> their needs.
> realm dom5.tld {
> mech pam
> realm_option [ pass | drop | char_replace ]
> }
> Since PAM only really deals with usernames, how would say foo at dom5 dot tld be
> interpreted?

One way to deal with this is via some kind of rewriting module.
Something like mod_rewrite in apache, but not as complicated.

> pass: literally passed through user=foo at dom5 dot tld (PAM may will probably
> throw an error on non appropriate usernames, would be an option though for
> folks who don't use domains in the login name).
> drop: drop the domain/realm, assume there's some upper level magic ensuring
> the namespace is unique (probably not too useful, maybe map in a default
> realm). user=foo
> char_replace: tweak the special characters to make it acceptable to PAM.
> user=foo_dom5_tld
> Just some ideas...

I like this. This addresses Henrique's idea. You can also add 'add' or
'append' option which would append realm/domain to unqualified usernames.

> >
> > This is nice, but what do you do if you have hundreds or thousands of
> > realms/domains? I like the current ldap solution because it forces you to
> > solve this problem with the ldap design.
> I also agree that the correct place to solve it is in the LDAP design. I've
> got some grey hairs from working and reworking my LDAP layout to be flexible
> in accommodating multiple realms/domains (even across organizations). But,
> even with such a design, it doesn't munge very well sometimes at the
> political layer. Remote departments manage their user bases, usernames, and
> passwords. All sometimes while wanting single sign on utilizing their
> credential stores.

Things are a bit easier for me, I do not have to deal with political
issues. ;)

> > I think efforts need to be redirected toward auxpropd.
> Could I have a brief synopsis of it and/or its goals? Search through the
> archives mentions it (saslauthd successor). Has coding/design started on it?


Hosted Email Solutions

Invaluement Anti-Spam DNSBLs

Powered By FreeBSD   Powered By FreeBSD