User identities

Our user panel currently exclusively supports local accounts, which is the 90% use case for single laptop users. But when using GNOME in other environments, user identities may be centrally managed, via LDAP or Kerberos. These situations should be supported in some form. This includes:

• Showing whether the user is currently authenticated ('logged in') to any (and if so, which) domains.
• Notifying the user if a ticket or password expires and offering to renew it
• Offering a way to authenticate to a domain after logging in locally (ie 'kinit')
• Offering an API for applications to request the log in into a domain ('kinit')
• Authenticating to a domain when initially logging in

Some of this functionality is currently provided by the external krb5-auth-dialog, but it does not look great. This page is about providing the functionality in a nicely integrated way. The only way to obtain a 'secondary' Kerberos ticket is currently to use the kinit commandline utility. Renewal of the 'primary' Kerberos ticket also happens as a side-effect of re-authenticating, e.g. on the lock screen.

Participants

Matthias Clasen, Guido Günther

Status

• Needs design

  Design in progress

  Needs implementation

  Implementation in progress

  Stable

Use Cases

The key use case is to authenticate to be able to use the machine & network services. And do that only once a day, without sending passwords around nor bothering the user for authentication to use different services within the domain.

Scenarios:

• Corporate workstation. Network services available, Directory Service authenticaion (might even be Kerberos for local machine).

• Telecommuter. A machine with local accounts (/etc/passwds) requiring VPN to access corporate network.

Maintenance:

• Update name, avatar
• Change password

Non Cases

• Browse users
• Set language (for local users this is only done as an administrator tool for other than current account).
• Administrator tool to add/remove/configure/disable accounts.
• Setup ("here be dragons"). This is a user facing tool, either a workstation is preconfigured or user is given a "setup file" by an admin. Things like preauthentication, crypto settings are rocket science.

Relevant art

OS X

GNOME

System Settings

Passwords & Keys (Seahorse)

KRB5 Auth Dialog

Tentative Design

Warning: This is not a proposal yet.

Pre-configured system using Kerberos for login

• Admin sets up configuration file and enables service
• User signs in from the login screen as usual
  • Signing into an alternate realm can use the "Other..." prompt and enter a user@realm style name
• User stays signed into realm
• User is warned by an OS notification when ticket is about to expire
• ? Screen is locked when ticket expires? Credentials might have the kerberos password and get a new key from KDC instead?
• Realm that user is signed into is displayed in the User Accounts panel
• ? Can user sign out of realm without logging out? (probably not)
• ? Need to consider how the login will function if logged in, and then later the KDC cannot be contacted. Do we want to enforce the KDC policy, and deny access to the user's computer by requiring ticket renewal, maybe not. ?

Login using local auth with pre-configured Kerberos

• Admin sets up configuration file and enables service
• User signs in using local authentication
• When a site or service requests realm authentication in response to direct user activity an OS modal dialog can request credentials
• Probably shouldn't warn the user when ticket is about to expire since it can just be requested again?
• The user can see what realms are available in the User Accounts panel
• Realms can be signed into or signed out of in the User Accounts panel
• Explicit sign in requests show an OS modal dialog to request credentials

• Option to store credentials in Gnome keyring, so that on future logins this happens automatically. (? Credentials != Password ? (#659680))

• ? Refresh of AFS Tokens (via plugins) ?

Adding a Kerberos realm association to the account

• Can be done by going to the Credentials (Seahorse) utility and explicitly asking to add one
  • Or click "Manage Tickets" (or similar) in the User accounts panel
• User is prompted for an existing configuration file provided by the realm admin (? does this include PKINIT ?)
• A direct link or local file may be used
• An authorization dialog is used to ensure the user may associate to a realm.
  • ? What does this give us ?
• ? Should we support using Kerberos local login this way or just the opt-in case?
• ? Password changing ?
• Service is enabled

Removing a Kerberos realm association to the account

• User goes to User Accounts panel and clicks "Manage Tickets" (or similar)
• Select realm to disassociate
• Authorization dialog is presented
  • ? What does this give us ?

Related Documentation & Applications

• Seahorse

• System Security Services Daemon offers LDAP and Kerberos integration via a daemon, nss and pam module including offline operation.

• krb5-auth-dialog

• Cross Authentication

• Multiple ssh keys

• Storing Secrets

Comments, Questions

Coming back to look at this, finally. We had a few questions on the tentative design:

• Some questions about terminology: You say 'Accessible Realms' which seems to be somewhat Kerberos-specific, but 'Sign out' doesn't really match Kerberos terminology.
  • The genral thought was "allowed to access resources in thei network/domain". Not very happy with "accessible realms" either.
• The 'Accessible Realms' lists the tickets I have, correct ? Not the tickets I might be able to get ? 'Accessible' is not 100% clear there...
  • I am on a thin ice here, but you can have many 'lower importance' keys in kerberos, for accessing specific service on a specific server inside a network. I don't think those are important to expose here at all, they would be possible to look up in the Credentials app (see below). But a general access to the network (I believe that is called TGT, ticket to get tickets, issued by the CA for thatdomain)
• You say 'if renewal of the ticket fails, we request a new one' - that will presumably involve a notification and/or password dialog ?
  • In case you don't store it in the keyring, yes. But it may be possible to store kerberos credentials (including password) in Credentials, avoiding this completely. This is likely something to be part of lockdown, so that some enterprise environments can mandate authentication every time.
• In the part about the 'Credentials' app, you have two columns - the mockups in the left are all titled 'Credentials', the ones on the right all 'Seahorse'. Oversight, or are these two different apps, or two modes ?
  • The right column is a fallback, if we dont have time/resources to build a new Credentials app. It's just a gradual addition to the existing Seahorse app.
• The first screen of the 'Credentials' app that you show is not really clear to us at all - it seems to have online accounts stuff in it, like twitter and gmail. Is that like an 'empty welcome screen' ? or what is it ?
  • Credentials also functions as a "keyring". It's not web accounts, those happen to be website passwords. Those are credentials for websites that Web app itself doesn't manage.
• You seem to offer to create both 'kerberos principals' and 'kerberos tickets' - what is that distinction ? Normally, you would only ever 'get a ticket', right ?
  • You don't create tickets indeed. But you do store them in the keyring.
• I guess accessible realms should only be available for "My Account" and not "Other Accounts". What kerberos (or whatever) realms other users on ths system are logged into aren't really interesting.