Hello, Jerome
Unfortunately i dont have enought knowledge on how htis SSL things are
working.
So taking care of such RFE is out of my possibilities :)
> Hi Evgeny,
>
> I think it is a good idea to create a RFE summarizing this discussion.
> Do you want to take care of it?
>
> As a solution, I was thinking about passing the SSLSession as a special
> request attribute ("org.restlet.https.sslSession" for example). Then you
> could retrieve it in your application, call the SSLSession#invalidate()
> method. However, I'm less clear about the next steps and how they could
> be supported in a connector independent way... Maybe we should introduce
> some kind of façade class, like SslContextFactory abstract class that
> you contributed Bruno?
>
> Another case where it is necessary to interact with the lower-level
> connections from the upper Restlet layer is for connection tunneling via
> the HTTPS CONNECT method. Maybe there is a common pattern that will
> emerge. See related RFE:
>
> "Support HTTP proxies and gateways"
> http://restlet.tigris.org/issues/show_bug.cgi?id=207
>
> Best regards,
> Jerome Louvel
> --
> Restlet ~ Founder and Lead developer ~ http://www.restlet.org
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com
>
>
> -----Message d'origine-----
> De : news [mailto:[email protected]] De la part de Evgeny Shepelyuk
> Envoyé : vendredi 21 août 2009 10:56
> À : [email protected]
> Objet : Re: Auth by client's certificate
>
> 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=2386988
