Bug 14928

How does that work?  Are you sharing the token with the login or getting a new token?

I believe none of the Telepathy upstream developers use Kerberos.

For the necessary D-Bus API changes, you or another Kerberos user would need to tell us what information needs to be transferred from the GUI to the implementation in order to do the login (if at all possible, we want all state transferred to the CM to be explicit, rather than picking it up from files/the environment/daemons/whatever).

Someone would likely also need to patch Loudmouth (the XMPP library we use) to be able to do Kerberos authentication.

(In reply to comment #1)
> How does that work?  Are you sharing the token with the login or getting a new
> token?

Yes, I have to run kinit before running IM client (unfortunately, I really hate it, but the only IM client which supports Kerberos is pidgin; yuck).

Matěj

I guess the best way would be to use some SASL library which abstract sign in mechanism.

I am not sure, which application (telepathy-gabble or IM client) would have to actually read kerberos token.

(In reply to comment #4)
> I guess the best way would be to use some SASL library which abstract sign in
> mechanism.

I heard a lot of good things about cyrus-sasl, which supports (among all other methods) also GSSAPI.

(In reply to comment #2)
> I believe none of the Telepathy upstream developers use Kerberos.

Would telepathy-haze be able to use gaim ability to use cyrus-sasl-gssapi?

Well, haze exposes (I believe) all of the account options you can set in Pidgin for each protocol.  So, if you use the exact same settings as you would in Pidgin to make an XMPP connection with haze, it should work.

The exception would be if Pidgin pops up extra dialogs during connection to request credentials or something – haze doesn't support that part of libpurple just yet, so the connection would never be established.  But, maybe it's worth a shot anyway.

*** Bug 18471 has been marked as a duplicate of this bug. ***

In Empathy you can't create an account without a password defined. If you could, then ma(In reply to comment #7)
> Well, haze exposes (I believe) all of the account options you can set in Pidgin
> for each protocol.  So, if you use the exact same settings as you would in
> Pidgin to make an XMPP connection with haze, it should work.

In Pidgin you set *no* password and then assuming you have cyrus-sasl-gssapi installed then it will attempt a GSSaPI/Kerberos login if the server supports it.

One problem is that Empathy does NOT support defining an account without a password. If a password is set (an incorrect one), it doesn't appear to then try GSSAPI.

> The exception would be if Pidgin pops up extra dialogs during connection to
> request credentials or something – haze doesn't support that part of
> libpurple just yet, so the connection would never be established.  But, maybe
> it's worth a shot anyway.

As long as you've done a "kinit" ahead of time to login to Kerberos (or used pam_krb5), then there are no extra dialog popups.

I've contributed GSSAPI support to loudmouth that's landed in the master branch and will hopefully end up in Loudmouth 1.5.

With GNOME 3.0 coming out soon and empathy being tightly integrated, I would REALLY love to see GSSAPI support.

It looks like the loudmouth GSSAPI support was to no avail as telepathy-gable is is where the XMPP action is nowadays.

Any update on this bug?

(In reply to comment #11)

> It looks like the loudmouth GSSAPI support was to no avail as telepathy-gable
> is is where the XMPP action is nowadays.

For folks that find this via google, "wocky" provides XMPP for Empathy via gable.

Returning to this a year later:

telepathy-gabble now supports offloading SASL to an external process (a Handler for SASLAuthentication channels). An Empathy component which uses gnome-keyring and/or an interactive prompt is more or less the reference implementation (I believe it's called empathy-auth internally). There's also one in Maemo/MeeGo Harmattan on the N9, and I believe there's another in Telepathy-KDE.

The purpose of offloading these things into an external UI is that that UI can prompt the user for passwords, tokens or whatever else they're expected to provide; if Kerberos/GSSAPI authentication is non-interactive, you could try it first without showing any UI, though.

Gabble is now almost entirely SASL-mechanism-agnostic: it just proxies the list of available SASL mechanisms, and the SASL handshake for the chosen mechanism, onto D-Bus. The exceptions are when you do simple password authentication, either by providing a password before you connect or using the X-TELEPATHY-PASSWORD pseudo-mechanism (designed to make implementation of trivial clients easier); in either of those cases, Gabble still does the SASL handshake internally, using one of its supported mechanisms (which I believe are still limited to PLAIN or DIGEST-MD5).

So, if your XMPP server exposes Kerberos or GSSAPI as an ordinary SASL mechanism, I believe it should now be possible to implement Kerberos or GSSAPI in the SASLAuthentication Handler (password-prompting UI), without changes to Gabble. I'd suggest modifying the SASLAuthentication Handler in Empathy as a good starting point.

(In reply to comment #13)
> So, if your XMPP server exposes Kerberos or GSSAPI as an ordinary SASL
> mechanism,

Is it how http://xmpp.org/rfcs/rfc6120.html#tls works?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/7.