User:SamHartman/KIM UI

This page proposes product requirements for KIM and platform specific UI.

There are two cases where KIM presents UI to the user. The first is when the user is using a program like kinit or kerberos.app. In this case the user is attempting to get credentials for a specific principal. The second is when KIM is automatically prompting to choose and identity and potentially get credentials.

Principles

• We want a consistent UI experience for automatic prompting:
  • We want the UI to look the same to prevent phishing
• Long term, we want the automatic prompting UI to be presented by an agent that is trusted code.
• We want to minimize code reuse in applications:
  • Avoid bugs being copied
  • Add functionality

Use Cases

There are several use cases for KIM UI that need to be supported.

PAM Applications

On Unix, PAM is used to get credentials. There needs to be an implementation of pam_krb5 that backends into KIM. This pam module will be used in generally trusted applications such as gdm or login that are login applications. The PAM model has a conversation function that works similarly to the krb5 prompter interface. The conversation function is passed into pam_authenticate by the application. The pam module needs to be able to intercept the KIM UI requests and pass them to the conversation function.

It would be desirable if the PAM module did not need to come with some sort of KIM plugin, although that would be an acceptable strategy if absolutely required. People do need to be able to write third party pam modules that use KIM, so the support for the PAM module needs to be in public APIs and plugins.

It is reasonable for KIM to assume that only reasonably trusted applications will run the PAM module.

Login Applications

We need to be able to write login applications such as kinit that use KIM to obtain initial credentials. These applications need to be able to provide their own UI. They can be reasonably assumed to be trusted. It probably wouldn't be a problem if such applications did need to come with some sort of KIM plugin as they are part of the kerberos release.

Agents for Auto Prompting

KFM will use Kerberos Agent for auto-prompting. KIM will send it messages. Long term we want KIM to send a fairly general message and the agent to return a pointer to a credential cache and principal.

On Windows, NIM will prompt for credentials and need to receive messages from KIM. The UI will be more complicated than KFM. For example, long term, some component of NIM wants to provide hinting information on what certificate to use with a given identity. Consider how the agent interface works with the use cases discussed in the NIM 2.0 proposal. This probably does not affect things as far as KIM as concerned.

More generally, platforms will need to provide a component that interacts with KIM to perform auto-prompting. The transport will be platform specific, and that component may be a stand-alone agent or it may be part of some other credentialing system.

Specific Application Environments

KIM may be used in very specialized environments like a phone UI, or a voice response system, or some other system where the UI of some product is not the platform's native UI. We may want to support having some way to provide plugins in these environments for auto prompting. The key distinguishing feature is that some platform is being built on top of the OS by an application integrator and that a party other than the OS has a need to replace the UI for a class of applications. This is mostly an imbedded systems sort of application.

• It is reasonable to require that applications in this class select a specialized UI.
• Providing such a UI in a plugin rather than allowing the application to customize the UI is desirable for this use case. The plugins can be reused and the UI is tied to something broader than the application.

Unix desktop environments

There are multiple UI frameworks for Unix: KDE, Gnome, etc. It would be reasonable to provide a UI plugin for each framework and to provide a mechanism for selecting the default framework for the agent to use.

Requirements

• Mechanism for platforms to provide a transport that is platform-specific between KIM and the component in the platform acting as an agent.
• Design that supports easy construction of Kerberos-specific agents or integration of the agent into some platform-specific application.
• UI plugins
• Mechanism for building login type applications that are trusted and that have control over how the UI is presented.
• Sufficient plugin APIs that third parties can write PAM-like applications