-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ruchith Fernando wrote: | Sanjiva Weerawarana wrote: |> I don't think validation is what's needed .. if you validate it'll |> fail anyway. What we need to do is inform the user that the cert is |> "not good" (not signed by a trusted CA, expired, whatever) and let the |> user decide whether they want to go ahead anyway. | | Browser does this anyway ... if the users trust the external site they | can add the cert into trusted site lists in Firefox and IE7(using cert | stores in Windows), why do we need to duplicate that process? | But this particular work flow happens outside the browser, inside the Mashup Server. We have a user specific keystore stored in the registry, NOT in the OS or JVM. So it does make sense to inform the user if a certificate is not good, just like a browser would do. The question is, can the java security APIs provide us this functionality? If so, it would make life easier. Tyrell | Thanks, | Ruchith | |> |> Sanjiva. |> |> Tyrell Perera wrote: |> Good point Ruchith. We don't 'validate' the certificates at present. We |> just inform the user when there isn't a trusted certificate in his/her |> keystore for the site in question. |> |> The user can then go on to either download the public cert from the site |> and upload or type the URL of the site, in which case we obtain the |> certificate chain from the site and add it to the user keystore. |> |> Is there a way to validate a certificate using the Java Security APIs as |> well? If so I can add a verification/validation routine prior to cert |> addition to keystore. |> |> Tyrell |> |> Ruchith Fernando wrote: |> | Hi Tyrell, |> | |> | Tyrell Perera wrote: |> |> |> |> Update: |> |> |> |> Now a user can just type the URL of a trusted site and the certificate |> |> chain will be retrieved and added to the user keystore by the Mashup |> |> Server. |> |> |> | |> | IMHO the failure at this point is very important. Do we first show the |> | user that the site the user is trying access does not come with a valid |> | cert? Basically we should not automatically bypass any security |> provided |> | by the browser to reject invalid certificates. We can do so only if the |> | user really wants to access the site. IMHO in practice as long as the |> | users interact with legitimate sites this issue will not arise. |> | |> | Thoughts? |> | |> | Thanks, |> | Ruchith |> | |> |> |> |> Tyrell |> |> |> |> Tyrell Perera wrote: |> |> | FYI |> |> | |> |> | We now have a keystore per user along with keystore management |> |> | functionality exposed in the UI. It works as follows at present. |> |> | |> |> | ~ - A keystore is 'cloned' using the server keystore at user |> |> registration |> |> | and stored in the registry. |> |> | |> |> | ~ - A user can manage the certificates in his/her keystore using the |> |> | 'Certificate Manager' page, accessible through the 'Tasks' panel |> |> | |> |> | ~ - The management UI allows a user to add trusted certificates to |> |> sites |> |> | ans delete them if required |> |> | |> |> | ~ - A custom protocol handler is in place, which retrieves a user |> |> | keystore from the registry and uses the certificates stored |> within to |> |> | make https connections on demand (Currently the Sharing service uses |> |> this). |> |> | |> |> | |> |> | Example scenario |> |> | ---------------- |> |> | |> |> | - User tries to share a mashup to another server in a separate |> domain. |> |> | HTTPS is required and a certificate for that domain is not |> available in |> |> | the user keystore. |> |> | |> |> | - Sharing fails. The dialog informs the user the reason for the |> failure |> |> | along with a link to the 'Certificate Manager' page. |> | |> |> | |> |> | ~ - The User obtains the public certificate for this domain and |> adds it |> |> | to his/her keystore and retries. The sharing service picks up the |> new |> |> | certificate and successfully shares the mashup. |> |> | |> |> | |> |> | We can potentially extend this feature to obtain certificates |> just by |> |> | giving the URL of a site. The WSRequest host object, will have to be |> |> | changed to use the custom protocol handler as well. |> |> | |> |> | |> |> | Tyrell |> |> | |> |> | |> |> |> |> _______________________________________________ |> |> Mashup-dev mailing list |> |> [email protected] |> |> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev |> |> |> |> |> | |> |>> | _______________________________________________ | Mashup-dev mailing list | [email protected] | http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev |>> | | | - -- Tyrell Perera Senior Software Engineer; WSO2, Inc.; http://www.wso2.com/ email: [EMAIL PROTECTED]; cell: +94 77 302 2505 "Oxygenating the Web Service Platform." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIMEzVehFdPcgGx7oRAqVsAKC1SwKSV+NR1FLyfiyuzYkO9i1G5QCgo6i2 clmhM5i9EyjlL2JF3ADQTtg= =6UQQ -----END PGP SIGNATURE----- _______________________________________________ Mashup-dev mailing list [email protected] http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
