logo_kerberos.gif

Difference between revisions of "Projects/KIM UI plugins"

From K5Wiki
Jump to: navigation, search
(New page: {{project-member}} Platform maintainers want to control the Kerberos UI on theirplatform. The Kerberos identity management API needs to interface with the platform specific UI cod...)
(No difference)

Revision as of 15:32, 15 January 2008

This is an early stage project that is currently accessible only to members of the MIT Kerberos Consortium. From time to time, the consortium staff and members will want to work on a project proposal before sharing it with the community. Note that the process of building consensus behind a project proposal cannot begin until the project has been made public.

Platform maintainers want to control the Kerberos UI on theirplatform. The Kerberos identity management API needs to interface with the platform specific UI code in order to ask for information from the user. This project proposes to create an interface between KIM and UI providers so that KIM can request user interaction.


Stability Requirement

In at least one case, the UI provider will be developed by a separate organization under disjoint time lines. For this to work, the interface needs to be very stable. Forward and backward compatibility between UI plugins and Kerberos will be required within a reasonably wide margin.

Questions to answer

How many prompter callbacks

Today the prompter function is called multiple times in hardware preauth cases. We can probably get a commitment at a protocol level that it is an error for this to be needed. However our code architecture would need to change for KIM to be able to take advantage of that. What is involved in this change and can we commit to accomplishing it?

Hard Issues

This section should describe the hard issues that influence the design. Probably each bullet should be expanded into a subsection.

  • When do you ask about a password; not needed for pkinit
  • Localization and strings from KDC
  • Multiple prompts if we don't solve that

Paths not taken

There are some obvious ways to approach this design that we've chosen not to take. Explain why so others can debate these choices with us and understand our approach.

  • An API with calls like get me the credentials that returns credentials and has another API for identity selection


Functional requirements

What does this API need to do; how do we judge its success?

What use cases do we need to support?


Design

API functions

Supporting library changes

Testing Plan

  • Provide tests for UI plugin providers to determine whether forward/backward compat is maintained?
  • Provide a test UI provider for some platform?
Retrieved from "https://k5wiki.kerberos.org./wiki?title=Projects/KIM_UI_plugins&oldid=125"