Difference between revisions of "User:SamHartman/KIM UI"

Latest revision as of 14:56, 20 March 2008

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. The platform will also need to provide platform-specific UI in the agent.

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.

Unsupported: Application Specific UI

Support for application-specific UI especially in the auto-prompting case is not a desired use case. If applications modify the UI then it will destroy any ability to train users about when they should enter their password and about when UI should be trusted. Note that such training is somewhat suspect [1].

However some platforms will take a different approach with regard to this use case. These platforms will decide that usability is more important than security and will make available mechanisms for application-specific auto-prompting UI.

What we want to avoid is a situation where applications bypass the identity selection mechanisms and treat use the login application mechanisms for application-specific UI. Designs responding to this use case need to e explain how a platform vendor could use the mechanisms in the design to enable application-specific UI if they desire and evaluate that against the complexity of using the login-specific mechanisms.

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.
• Mechanism for platform-specific UI.
• 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
• Sufficient support for third-parties to write UI for custom environments for auto-prompting (use case 2.5)

Testable when integrated into a platform

Our developers want to be able to build new versions of our software on a platform. For KFW, we expect to control all the components that make the KIM experience possible. For other platforms, components such as the agent and UI are expected to be platform-specific. We run into trouble when:

• Platform specific components depend on extensions to Kerberos that are in the platform but not in versions we supply
• We want to test extensions to KIM that are not yet supported by the platform.

There are two approaches to the KIM extensions problem:

• Don't expect it to work
• Design things in such a way that we can provide skeleton/sample/development versions of the platform components and that these can be used instead of the platform components for testing KIM extensions.

To allow skeleton components to replace platform components we'd need to make sure that applications at least minimally worked when the platform component was not used. For example, applications could not depend on symbols present in the platform component being present.

These issues generate several requirements:

• We must provide a platform integration guide that gives a clear definition of extension points and discusses the problems with using additional extension points.
• Designs must provide a strategy for how KIM extensions will be tested.

Deliverables

• A platform integration guide
• A design for KIM UI extensibility that responds to the use cases and requirements outlined.
• A sample UI and agent that shows platforms how to construct the components they need to supply.
• Eventually, a windows and Unix implementation of the agent and UI

Sample UI

In order to meet this deliverable we need to implement an agent and UI that is designed to illustrate our vision of best practices for how a UI and agent should behave. This needs to support all the features of KIM.

The question is whether the sample UI is separate or whether it is actually one of the UIs that we ship for Windows or Unix. Using one of the UIs we ship as a sample may reduce development effort. Also, it makes sure that the sample responds to real-world UIs and gets enough usage to generate usability feedback.

Writing a second sample may allow us to make faster progress with the development resources we have. In addition, the sample may be easier to understand and simpler.

We need to make sure that the sample does not violate the general principle of code reuse.