[long reply - several points covered]
> I think that's OK - as you say, there's a principle that the users cert should
> remain somewhere they control (most obviously their local system).
I think we are in agreement.
All of need to be more precise about what we mean though.
I try (but don't always succeed) to say credential when I am talking about a cert with its private key.
Since cert is used for both with and without.
So your full credential (whether the .pem pair or single .p12) should remain within your
own administrative domain, filestore protected and password protected - note that there may well be
admins who have access to your filestore even if you set file perms and passwords so you have to accept that,
but hey - they are *your* admins. In your browser you should set a master password.
You shouldn't really have it elsewhere (like on a 3rd party UI), but having a password protected myproxy proxy
which doesn't last too long (1-4 weeks maybe) is probably OK.
Your public certificate (without the private key) can pretty much go wherever you want!
> Well, this process works now, I just tried it:
or maybe try
> - Start CertWizard,
And "install" your certificate
> - Create a grid proxy (a plain grid proxy, no VOMS),
> - Upload it to myproxy.ngs.ac.uk using CertWizard, setting a username and
> password,
You should be able to do this in one go using the myproxy part of CW, you don't need the grid proxy first.
> - SSH into a UI
> - Do 'myproxy-get-delegation -s myproxy.ngs.ac.uk -l username' to get a proxy
> - Do 'voms-proxy-init -n --voms name_of_your_vo' to add VOMS extensions to
> it.
I wouldn't use myproxy-get-delegation as it was deprecated something like 6 years ago, it is identical
to myproxy-logon however
Also, how about instead
# -s param can be set using an env var I think
# Why not use the UI username as you "username" when uploading your proxy then you can miss that off too
# -m / --voms option allows you to specify a VO
myproxy-logon -s myproxy.ngs.ac.uk -l username -m name_of_your_vo
> By-the-by, it turns out that GSISSH-Term still exists, and uses the same standard
> proxy locations as Certwizard does (of course),
It does - it also has built-in support for VOMS - the same plugin as is used in the MyProxyUploader
part of CW. This code might need work to work with SHA2 certs though so maybe the IGE-provided
(see EGCF website) version of GSI-SSHTERM might be a better bet
> so I'm hoping that with a gsi-ssh
> accessible UI, the user would be able to log in with that and their proxy, not a
> traditional username and password. At that point, all they'd need for a client
> system would be something capable of running two Java Web Start apps, and
> that'd be it. I don't have a gsi-ssh accessible immediately to hand to test it, but I
> think the principle is sound.
John Churchill's script on the NGS UIs did this - you logged on with your cert using GSI-SSHTERM or
similar and then HAD to select a proxy to continue and your login was execed - which I believe then
re-mapped your login to your a/c for that VO as defined using LCAS/LCMAPS.
JK
--
Scanned by iCritical.
|