Right now you can only get a Kerberos ticket in the session when using password authentication as the method we currently use is to feed the password to kinit using our SSO mechanism. If users authenticate using smart cards, then we have nothing to give kinit and hence no ticket. It should be possible to wire things up so kinit can use the smart card to authentciate and get a ticket. That assumes Kerberos is configured for smart card authentication, though, and that smart card SSO is enabled in the ThinLinc client.
If bug 2739 is implemented in a way that gives a Kerberos ticket, then it and bug 4712 might give us a way to get a ticket without a second authentication in the session startup.
In case it's not realistic to resolve bug 2739, perhaps we can still get a Kerberos ticket using the smart card. After authentication, vsmserver (or thinlinc-login) could get a ticket manually from the KDC by having some communication with the client to get the certificate and do the sign operation. We probably don't want to use the PC/SC tunnel as a) it isn't normally available in the master connection and b) it assumes there is some PKCS#11 middleware available on the server. So we should probably use some new XML-RPC requests. The Kerberos library seems to be designed around doing everything itself, so it isn't easy to extend the way we want. The only extension point it has is specifying a PKCS#11 library to access the certificate and key. We should be able to do some dummy library that interacts with the helper we need to write that does the low-level Kerberos calls. The big downside is that we need to do an extra authentication for the card, which can be a bit slow. An obstacle is also that the client normally initiates communication, but here the server will want to be the driver. A theoretical solution for this is: 1. Client sends a "scauth" capability to the server 2. Server checks that there wasn't already a Kerberos ticket by some other means 3. Server checks that the KDC supports pkinit (via krb5_responder_list_questions() helper?) 4. Server sends back its own "scauth" capability 5. Client sends a "get_sc_challenge" request, containing the certificate used to authenticate 6. Server starts authentication with KDC (through a helper and special PKCS#11 library?) 7. The Kerberos library will call back through the PKCS#11 library to get the certificate and to sign some challenge 8. The server passes on that challenge as a response to the "get_sc_challenge" request 9. Client signs the challenge using the smart card and the (still) cached PIN 10. Client sends "sc_response" with the signed response 11. Server feeds back the response to the Kerberos library via the PKCS#11 library 12. Server gets a TGT, responds success to "sc_response" and can continue as normal This also exposes a design problem. We don't have a state to associate requests with each other. This is rarely an issue as a user isn't normally doing multiple logins at the same time, but it might be worth solving that issue here.
