[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
>then
>we reject it because it doesn't have a "u:" or "dn:" prefix. I'm wondering
>if
>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
implementations.


>(re: the non-match case, sometimes I see authcid=hyc/authzid=hyc@my.realm.

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