Projects/KIM UI plugins
Platform maintainers want to control the Kerberos UI on their platform. 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.
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?
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
What does this API need to do; how do we judge its success?
What use cases do we need to support?
Supporting library changes
- Provide tests for UI plugin providers to determine whether forward/backward compat is maintained?
- Provide a test UI provider for some platform?