Well, maybe it's reasonable to create RFE for this and try to impelment extenstion prototype ?
> 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 > -- Regards, Evgeny Shepelyuk ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2385928
