We do in fact have a single signon for all our users. We have an app server hooked up
to a combined LDAP server/database server. From this we determine user authentication
and user role.
We have a separate server (physically), a forums application server. Because this is a
third-party product, it currently controls it's own authentication and access control.
We have the option to allow the forums to trust the webserver to authenticate users.
This option requires that the webserver that the forums application resides upon set
the remote_user variable to the userid of the forums user.
The reason we want to do this is because the forums product can synchronize its
internal database of users with an LDAP database. This would be nicely convenient, and
would eliminate a long, finicky, processor and i/o intensive batch update we run
nightly. We would also have the benefit of real-time updates to user information. All
of this requires that the forums application rely upon the webserver for
authentication, rather than its own internal method.
Because we got this product long before we ever had an application server, the userid
scheme, while related to a unique id in our database, is not the same as the id we use
site-wide. This is for various stupid technical and political reasons.
Determining this user id is no problem at all, it's just an internal customer number
prepended with a letter.
When a user logs on at our main site, gets a valid session, and then chooses to move
to our forums product, I need to be able to figure out what their forums id is (no
problem), tell the webserver upon which the forums resides who this user is, and get
the webserver (container) to set the remote_user variable to this forums id.
Because we use servlets to pass information from one server to another on our site, I
was originally hoping to use a servlet to set this variable, hence my first post on
this subject. I can see now that servlets alone can't do that. It looks to me like I
have to learn some webserver API programming.
We use Netscape Enterprise server for our webserver. NES allows for authentication of
various types. Basic, LDAP, and user-defined (programmed to the NES api spec) NES does
have a java api.
I'm going to also post this to the list, so that you won't have to go through this
again with someone else :)
>>> "Nic Ferrier" <[EMAIL PROTECTED]> 07/07/00 06:34AM >>>
>>> "Ed Wittmann" <[EMAIL PROTECTED]> 06-Jul-00 9:55:11 PM >>>
>Thanks for sending me the FAQ, I appreciate it.
s'ok.
>I'm sorry my question doesn't make sense perhaps I
>should have explained what I wanted in more detail.
Yes. /8->
>We have an forums application that can be configured to
>read the remote_user variable. Our application server can
>obviously have security "realms."
Ok.
>The problem is that what our app server sets as the
>authentication info for a user, and what the forums
>application requires are two different things.
>(It's a long story.)
Sounds to me that you should tell me the long story - I'm sitting
comfortably.
>Since the forums application is on another physical server,
>I was hoping to be able to "pass" this user information from
>the app server to the forums web server, and have the forums
>web server set the remote_user env variable.
I can't remember if the UA should pass the WWW-Authenticate header to
different servers.
I don't really understand what you're saying still (possibly because
I haven't heard the l,ong story).
Is the forum app on a completly seperate host or is it a host that is
part of the app-server cluster?
If the forum app is on a completly seperate host then how is the
request related to the app-server? Have you got some sort of single
signon system going on whereby the app-server authenticates all your
users?
And how would changing the value of the remote-user variable possibly
affect the request object in the app-server?
>We have a cheap hack around this right now that
>isn't real secure in my opinion.
Basic authentication isn't secure full stop.
>I realize now that the container (the web server?)
>must set the variable now.
Yes. But only because it's the only thing that can change the
request, we call it "presentation". The servlet has full access to the
data held in the request but only the container can "present" the
data.
This is not the same as "setting the remote-user" variable however...
which is not really possible at all. The container just "presents" the
remote-user variable.
>I apologize for snapping back but I really didn't find
>what I was looking for in the archives, hence the
>posting. I should have explained further.
It's obviously a tricky problem... if you try and explain again I may
be able to help.
Nic
PS: even on the list it takes several times before you are
understood... but a quick question like the one you posted is almost
invariably treated with disdain.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
