Re: saslpasswd2 and virtdomains


Subject: Re: saslpasswd2 and virtdomains
From: Jeremy Rumpf (jrumpf at heavyload dot net)
Date: Sat May 17 2003 - 13:56:44 EDT


> >
> > 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?

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...

>
> 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.

>
>
> 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?

Thanks,
Jeremy







Hosted Email Solutions

Invaluement Anti-Spam DNSBLs



Powered By FreeBSD   Powered By FreeBSD