Hi Roy,
Did you try to use the end-entity cert (i.e. long-lived, non-proxy certificate) in your browser? Did it work?
First, I believe we can issue somewhat long-lived certificate for download for loading into client applications, such as a browser. This has always been in our plan. In general, it should not matter whether this is a proxy or an end-entity cert. The need for an end-entity cert would be interfacing non-VO services that don't know how to deal with proxies. Any new VO-compatible service MUST support proxies.
Second, I want to review the reasons why in both the HEP and SC communitites users are prompted for a password to create a proxy:
o someone that has access to your laptop/workstation does not have
access to your remote privileges. o creating a limited lifetime proxy limits what (e.g. damage) the
holder can do on your behalf.
The danger in loading a long-lived, end-entity cert into a browser is that anyone who has access to the open browser can access your assets. Is there a mechanism to protect against that?
Also, as a general practice, it also has the disadvantage that it's not a great solution for the broadest community. It's "complicated" for the naive user, and you have to deal with the plethora of browsers out there. Note that my credit card company and bank do not issue me a certificate for loading into my browser; rather they make me login over a secure channel.
When it comes to browser-based interfaces to services, I believe portal-managed certificate model is the safer approach and easiest for users; however, I think the direct approach you want to use is worth developing to see what it can do. In particular, I would like to understand under what conditions the latter model is particularly useful. (Do you see it as the most common mode of operation?)
Of course, the portal-managed certificate model shifts the complications to the portal (as I believe it should); in particular,
o the portal must track a session via a store of active proxies o if the service being accessed trusts VO certs, then the portal can
use the cert directly.
o if the service does *not* trust VO certs, the portal must use a
"community" cert that the service does trust. This in effect would
have to be a long-term and well-protected cert that can be used
by the web server without a password.
Finally, I feel that if we want our VO certs to be trusted both by our own service developers and the broader community (e.g. the grid community), then we need to take measures to establish secure practices.
> This note refers to:
> Single-Sign-On Authentication for the IVO: introduction and description of
> principles
> http://www.ivoa.net/Documents/Notes/SSO/SSO-introduction-20051002.html
All that said, I would have to admit that it may be unclear in the SSO document whether one is to interpret section 9, "Recommendations for the VO" as just recommendations or a set of compliance assertions. While some should be advisory ("Support external CAs"), others are more at the crux of interoperability ("Use X.509 certificates as warrants..."). I believe though that this is a principles document that more specific standards will base themselves on; but this could be made clearer.
In other words, I don't think this document says that you can't use long-lived credentials in a browser. However, it advises against this for the reasons reiterated above.
hope this helps,
Ray
Received on 2006-10-26Z00:52:12