Difference between revisions of "Release Meeting Minutes/2012-06-05"
From K5Wiki
(New page: Steve Buckley, Thomas Hardjono, Sam Hartman, Greg Hudson, Simo Sorce, Zhanna Tsitkov, Tom Yu == Keytab based initiator creds == ;Greg: Keytab based initiator creds. :# when? :# princ? :#...) |
(No difference)
|
Revision as of 16:35, 6 June 2012
Steve Buckley, Thomas Hardjono, Sam Hartman, Greg Hudson, Simo Sorce, Zhanna Tsitkov, Tom Yu
Keytab based initiator creds
- Greg
- Keytab based initiator creds.
- when?
- princ?
- where to cache?
- Greg
- App might provide a desired principal name.
- Sam
- Not sure about using default ccache. If application A requests a principal, can unexpectedly change the behavior of application B which uses default creds but normally doesn't see any.
- Simo
- Thought keytab
- Sam
- Application can pass in a specific name.
- Simo
- If you want app to use a specific name, app should set ccname. Just doing automatic init without administrator configuration is undesirable.
- Sam
- Do if you have hint from either environment or app.
- Thomas
- Precedence?
- Greg
- Usually application, then environment variables, then config. If application provides a name is it a sufficient hint?
- Sam
- Application could start using Kerberos when not intended. Once you've got cache collection... makes sense to pass a name to init_sec_context. If you have something in .k5identity, then always do keytab initiator creds. Think about keytabs using MSLSA analogy... keytabs extended by ccaches.
- Simo
- Don't like blocking operations during enumeration.
- Greg
- Special cache.... interacts with some APIs, may not get destroyed when default cache does, etc.
- Sam
- If collection, then use it; otherwise memory.
- Simo
- Seeing as daemons would be OK with environment variables... have .k5identity later.
- Sam
- But there is a reasonable way to get portable...
- Simo
- Not easy to find example code. Don't want people to use gethostbyname.
- Tom
- Do they do that for initiators? More common to use gethostbyname for acceptor.
Import/export creds
- Greg
- GSS proxy... so every existing app...
- Simo
- Mostly for acceptors
- Greg
- But if S4U2Proxy, the app can also be an initiator. Acceptor cred. init. delegated cred. memory ccache.
- Sam
- Not sure marshalling makes sense. Have tried to make portable. Can move across privilege boundary, etc.
- Greg
- Context vs name. Can't do with KDB keytab. (but you probably don't want to do that)
- Sam
- When deferring credential resolution.
- Greg
- Default cred. Don't want people to depend on...
Sam wants it to be portable between versions. Some discussion. It could be hard. Is the lucid context good enough for most uses?
