Kerberos Notes

These are notes from a meeting between the IPA and Red Hat desktop teams before devconf 2016 with some updates since. They are pretty cursory and may not make sense to non-participants.

Underlying assumptions

We are assuming a use case of a user with a laptop that may or may not be self-managed, and is probably not perfectly set up to work in the corporate environment where the user needs to access various Kerberos enabled websites and services. (We could call it the "RH" use case...)

The user can obtain a Kerberos ticket from one (or possibly more than one) KDC. He may have set up his Kerberos account in goa.

Observations

The current state of the art in Single-sign-on support in applications is pretty terrible. For example in web browsers,

  • firefox:
    • Only sends a Kerberos ticket when specifically configured in about:config
    • Doesn't give clear feedback about this
    • Blocks in gssapi (https://bugzilla.mozilla.org/show_bug.cgi?id=890908)

    • Doesn't inform the user if a site could use a Kerberos ticket
    • Doesn't have any way to see which websites have used a Kerberos ticket in the history
    • There was a problem with credentials getting sent even in private browsing mode (now fixed)
  • epiphany (with gssapi-supporting libsoup):
    • Sends Kerberos ticket anywhere
    • Doesn't give any feedback about this
    • Doesn't inform the user if a site could use a Kerberos ticket
    • Doesn't have any way to see which websites have used a Kerberos ticket in the history
    • need to document the current whitelist/blacklist feature of libsoup
    • need a better api for affecting whitelist/blacklist
  • chrome
    • Has support for negotiate-auth, but only has a whitelist in /etc
    • There is likely little enthusiasm upstream for any sort of integration.

Desired goals for applications

  • Discover if a service can use Kerberos
  • Inform the user about this
    • If tickets are available, offer to use one of them
    • If goa accounts are set up, offer to obtain a ticket
    • If no accounts are ste up, offer to do that
  • Show the user which identify is currently in use, and possibly also which have been used in the past (e.g. browser history)

It would be good to have a more or less unified UX for this across applications.

Desired goals for overall system

  • Make it possible to discover which tickets have been used by what applications (a history, or log)
  • Enable Kerberos support in other goa account types, e.g. owncloud can use Kerberos (in its enterprise version, or in the hacked up version that Alexander runs)

Priorities

The 4 biggest wins for application support:

  1. web browser: epiphany, firefox (we still need UI ala aday's mockups: https://wiki.gnome.org/Design/Whiteboards/EnterpriseLogin )

  2. mail: evolution (works fine for imap, libsoup changes should make it easier to work for html linked resources, not sure what the story is with EWS and negotiate auth)
  3. files: nautilus (rishi is working on gvfs, some confusion with http versus webdav, gvfs samba support need work to support kerberos instead of username/password. we still need UI. OwnCloud is the initial target, after that: smb, nfs)

  4. printing (kerberos support in cups is there, we still need UI)

Other stuff:

Timeline

  • 3.20/F24: libsoup gssapi support, kerberized owncloud support
  • 3.22/F25: epiphany, firefox, nautilus, evolution, kerberized freerdp
  • After that: various login screen scenarios - azure login (with browser), vpn on the login screen

Implementation notes

gssapi is a blocking sync api, don't use it on your ui thread.

Different services indicate kerberos support in different ways. For http, it is the negotiate-auth header.

Important to follow redirects, and pick up negotiate-auth headers along the way.

For owncloud, should do an setup dialog similar to google, and show their web page.

MatthiasClasen/KerberosNotes (last edited 2016-05-29 10:47:18 by AlexanderBokovoy)