Hi, I'm not sure. If GrizzlyServerCall is running from the same thread the SSLReadFilter is used, SSLReadFilter.doPeerCertificateChain(...), with the selection key in the GrizzlyServerCall should work.
What you need ultimately is to get hold of the SSLSession (via SSLEngine or SSLSocket), invalidate this session, re-set the want/need parameter, re-start the handshake (and make sure it has completed before proceeding). I think the biggest problem, from the Restlet point of view, is that the higher level classes (Restlet/Resource/...) would need somehow to be able to get hold of the HttpServerCall to trigger this (and supporting this feature would also depend on the connector implementation). This would be something unusual compared with the rest of the architecture of the Restlet framework. I'm not sure what the rest of the community (in particular Jerome and Thierry) would think about that. I'd be happy to assist, but I'm not sure how big the modifications in the API and Restlet architecture would be. Best wishes, Bruno. Evgeny Shepelyuk wrote: > Hi > Thnx for this answert > I have one small request > Can you point to Grizzly classes how this goal can be achieved ? > > >> Hi Evgeny, >> >> Evgeny Shepelyuk wrote: >>> Hello, >>> >>> I'm using Jetty as restlet HTTP engine with SSL enabled and client's >>> certificate auth. >>> Probabaly it's more related to Jetty but is this possible to make server >>> only ask >>> for certificates only for certain URL. >>> >>> I'm NOT USING needClientAuthentication, so certificate is not mandatory, >>> but >>> what i want is following >>> >>> - for certain resources still use HTTPS, but never let browser to ask >>> for >>> client's certificate. >>> >>> Only way i сan see now - is creating 2 HTTPS connectors and run 2 server >>> sockets within restlet app. >>> >> >> In principle, this can be achieved by re-negotiating the handshake. >> >> This is something that Tomcat supports if the listening socket isn't >> configured to want or need authentication but CLIENT-CERT is used within >> the webapp. >> As far as I know, Jetty (as a container) doesn't support it. I don't >> think its API supports it either. The Grizzly library has some support >> for this mechanism. >> The Restlet API doesn't support it at the moment. Currently, the client >> certificate is populated when the handler is set up (when the socket is >> connected), after that, the upper layers (Application/Resource/...) >> can't talk back to the socket to tell it to re-negotiate. >> >> This is not impossible, but it would require some changes in the API, in >> particular HttpServerCall and the way the client certificate is then >> passed to the request attributes. >> >> I also reported a bug about this using Glassfish/Grizzly (nothing >> Restlet-specific) a few months ago; I haven't tried more recently. >> https://grizzly.dev.java.net/issues/show_bug.cgi?id=416 >> This would definitely be a problem to implement this feature in Restlet >> if the libraries used by the connectors don't support it. >> >> >> A possible workaround might be to use Restlet within Tomcat and to use >> CLIENT-CERT for the URI patterns (defined in web.xml) that you know will >> want client-certificate authentication. >> >> >> Best wishes, >> >> Bruno. >> >> ------------------------------------------------------ >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385222 >> > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385695
