User:SamHartman/KIM UI - Revision history

SamHartman: add platform integration guide as a deliverable

2008-03-20T19:56:37Z

add platform integration guide as a deliverable

SamHartman: add non-use-case and discussion of sample ui

2008-03-20T19:41:14Z

add non-use-case and discussion of sample ui

SamHartman: use cases for KIM UI work

2008-03-18T21:23:19Z

use cases for KIM UI work

New page

This page proposes product requirements for '''[[Kerberos Identity Management|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

@@ Line 84: / Line 84: @@
 ==Deliverables==
 * 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.

@@ Line 37: / Line 37: @@
 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.
+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===
@@ Line 48: / Line 48: @@
 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==
@@ Line 53: / Line 61: @@
 * 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 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