----- Original Message -----
From: "Anton Ushakov" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, April 02, 2004 10:46 AM
Subject: Re: Coyote's ServerSocketFactory problem
> First I must say you've been extremely helpful, thank you for your
> prompt responses! I hate to bug you but I had another implementation
> question. I looked at JSSESocketFactory and how SSL is done in the
> connector, but it doesnt address one particular issue I'm having.
>
> Basically I have JAAS (GSSAPI) authentication done inside the Socket
> that my SocketFactory makes. Let's call it GssSocket, and it uses
> GssInputStream GssOutputStream for the authenticated & encrypted
> communication. Inside the GssSocket I establish the identity
> (principal) of the incoming request, but have no way to set it into the
> CoyoteRequest so it can get passed to the target Servlets through the
> HttpServletRequest. Since all the servlet sees is the
> CoyoteRequestFacade, I cannot get access to either the GssSocket, or the
> GssStreams - the only places where the principal of the user is known.
>
> It looks like I can't avoid extending one of the Coyote classes after
> all. What would you suggest to override to be able to extract a string
> from the Socket and set it as an attribute for the servlets to get at?
> I'm sorry if this is getting too hairy, but any advice would be great.
>
It's probably possible to do what you want without much, if any, modifying
of Tomcat code. If you were to setup a full "SSLImplementation" to
implement your socket factory, then you could have your code return the
identity information in response to
'request.getAttribute("org.apache.coyote.request.X509Certificate")'. This
should work because nothing in Tomcat outside of the SSLImplementation
understands anything about SSL, so it won't really care that you aren't
implementing real SSL. This method is a little hackish, but it has the
advantage that you don't have to modify any of Tomcat's code to get it to
work. The downside is that you have to implement a minimum of three
classes, even if you can make most of the methods to be dummies. You'd also
need to worry about the scheme getting set to "https", but I could be talked
into modifying that.
Otherwise, you'd probably have to modify Http11Processor (about the only
class that has access to both the Request and the Socket :) to set the
attributes you want on the Request.
> thanks
> -anton
>
>
> On Thu, 2004-04-01 at 13:32, Bill Barker wrote:
> > ----- Original Message -----
> > From: "Anton Ushakov" <[EMAIL PROTECTED]>
> > To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> > Sent: Wednesday, March 31, 2004 10:59 PM
> > Subject: Re: Coyote's ServerSocketFactory problem
> >
> >
> > > Alright, thanks Bill. I have nothing against Tomcat5 and indeed the
> > > socketFactory="my.factory" attribute works. But is there any way to
pass
> > > custom parameters to the factory from the conf file? With a <Factory>
> > > element it was possible but with a single attribute am I out of luck?
> > > All this IntrospectionUtils business is confusing...
> > >
> >
> > The way this works is that all of the <Connector> attributes are passed
on
> > to the Protocol. In the case of the Http11Protocol, the attributes are
then
> > passed on to the SocketFactory (via calling the setAttribute method of
> > o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your
> > parameters on the <Connector>, and they will end up passed to your
> > SocketFactory. You can look at JSSESocketFactory to see how Tomcat
handles
> > this for the default SSL connector.
> >
> > >
> > > On Fri, 2004-03-26 at 18:03, Bill Barker wrote:
> > > > ----- Original Message -----
> > > > From: "Anton Ushakov" <[EMAIL PROTECTED]>
> > > > To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> > > > Sent: Friday, March 26, 2004 4:24 PM
> > > > Subject: Re: Coyote's ServerSocketFactory problem
> > > >
> > > >
> > > > > Should I make a bug entry for this? I wanted to get someone from
the
> > > > > tomcat dev team to see if I was missing something before flagging
this
> > > > > as a bug.
> > > > >
> > > >
> > > > The Catalina SocketFactory is deprecated for use with Coyote in 5.x,
and
> > it
> > > > would probably should be for 4.x as well except for the fact that it
is
> > > > still required to set SSL attributes. This means that anything
> > involving
> > > > this SocketFactory will just get marked as WONTFIX.
> > > >
> > > > Passing the socketFactory attribute on to the Protocol might be
> > something
> > > > (except for the fact that it is working in 5.x means it may not get
a
> > lot of
> > > > attention :).
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> > ______________________________________________________________________
> > This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is PRIVILEGED
and CONFIDENTIAL. If you are not an intended recipient, you may not read,
copy, or distribute this message or any attachment. If you received this
communication in error, please notify us immediately by e-mail and then
delete all copies of this message and any attachments.
> >
> > In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
> >
> >
> > ______________________________________________________________________
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
