[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
upon further consideration I think you're right(sorta). pkcs11 is not
really what I want here. it's more likely that what I want is actually
simply a engine_myproxy.sa that provides ENGINE_load_private_key, and
ENGINE_load_public_key, and ENGINE_ctrl_cmd(e, "LOAD_CERT_CTRL" ...
Matthew N. Andrews wrote:
> Douglas E. Engert wrote:
>>> Just in case anyone cares, my goal here is to have a pkcs11 software
>>> token that requires login to retrieve a user key/cert pair, and to
>>> upon "login" to actually acquire the key/cert from a globus myproxy
>> So how are you authenticating to the myproxy?
>> It is not clear why you are trying to do all of this from the the pkcs11.
>> It sounds like it should be multiple operations. Maybe via PAM.
>> Are going to use the "pin" to authenticate to the myproxy?
> Yes I plan on using the pin. my rational for going the pkcs11 route is
> that it means that users will be able to acquire new credentials post
> login simply by running kinit. The password to the myproxy server is
> validated against an OTP server. If/when sometime down the road we shift
> to using smart cards for authentication rather than OTP fobs, it simply
> means that we swap out the myproxy/soft-pkcs11 library for one that
> actually interfaces with whatever smartcard we end up standardizing on.
> multi module pam stacks work fine for initial login, but I don't know of
> a generic pam aware "acquire new credentials" application.
> I'm open to alternate suggestions, but I think that the user experience
> of having kinit do the right thing without needing the user to
> explicitly take the myproxy step will be a win. I could just replace
> kinit with a script that does both kinit and myproxy, however if I can
> come up with a solution that just requires configuration changes to what
> will ultimately be the standard heimdal code/apps rather than replacing
> them with wrappers I'll be happier.