RE: Cyrus SASL 2 is no good

["Howard Chu" <hyc@highlandsun.com>]

Most of the issues are now being handled. My patch for 1.5.27 is now in the
Cyrus CVS tree, and I've just submitted a patch for 2.1.2 that addresses my
concerns with the realm info.

The only outstanding issue is what is the real use of the CANON_USER
callback. My last patch to slapd works by ignoring the CANON_USER callback
and just doing the canonicalization in the authorize callback, like the 1.5
version. It's a rude hack though; I depend on knowing the size of the buffer
SASL allocated for the user names, because I overwrite it in the authorize
callback. The problem is that the CANON_USER callback is really unusable for
our purposes because it executes before the plugin authenticates the user.
We want to munge the name after SASL has already validated it, and at the
moment the only way is during authorization.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: Mark Adamson [mailto:adamson@andrew.cmu.edu]

> I can forward these issues to the guys here at CMU who wrote SASL 2.0
>
>   -Mark Adamson
>    Carnegie Mellon
>
>
>
>
> > The Cyrus SASL 2.1.2 library and current slapd do not get along
> well at all.
> > The Cyrus GSSAPI mechanism always returns NULL for authcid and
> authzid, and
> > appears to not be implementing all of the SASL2 plugin APIs
> correctly, so
> > that
> > mechanism is completely useless. I.e., it never calls the canonicalize
> > callback, which probably explains why  the authcid and authzid
> are always
> > NULL...
> >
> > Using MD5-Digest, I don't get a valid authzID input, so that
> fails as well.
> >
> > Also, for the record, Cyrus 1.5.27 has a bug in the GSSAPI
> plugin, it never
> > sets the realm in the connection context. I have a patch for this.
> >
> > Has anyone else been working with the Cyrus SASL 2.x libraries?
> Some of the
> > changes look pretty bogus. In particular, the library now only
> maintains a
> > single default user realm instead of a per-session realm. The plugins
> > themselves are no longer able to return any realm info. I
> believe this makes
> > it impossible to represent cross-realm Kerberos authentication
> in the GSSAPI
> > mechanism. (Somewhat of a moot point since their GSSAPI plugin never
> > returned realm info in the first place.)
> >
> > This is going to take some effort to get usable.
>