[Date Prev][Date Next]
RE: Cyrus SASL 2 is no good
At 10:42 PM 2002-04-19, Howard Chu wrote:
>I've noticed that the Cyrus 2 GSSAPI plugin tends to always send a non-NULL
>authzid with its requests.
Which is broken. They should not send an authzid unless the
user is attempting proxy authorization.
>Generally this will be identical to the authcid,
>and we handle that case ok. But sometimes the two names don't match, and
>we reject it because it doesn't have a "u:" or "dn:" prefix. I'm wondering
>we shouldn't just always treat authzid's as userids, unless they have an
>explicit "dn:" prefix. Essentially this means allowing the "u:" prefix to be
>optional. Any objections?
At least in 2.0, an authcid of "user" was allowed to assert
"u:user" or "user". The latter for compatibility with broken
>(re: the non-match case, sometimes I see firstname.lastname@example.org.
If my.realm is the *default* realm, I wouldn't have a problem
with allowing that assertion. As you noted below, classify
what the default domain might be difficult if the default
SASL realm isn't the same as the Kerberos default realm.
>Usually I see both IDs in full user@realm format. It's all a weird mix of
>conditions depending on the default Kerberos realm name, the client's
>Kerberos realm name, and the sasl-realm configured in slapd.conf. There's a
>lot of unnecessary confusion here, which I've raised on the cyrus-sasl list,
>but I apparently haven't gotten the point across yet about how unmanageable
>the current behavior is...)
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support