So I propose the following.
replacement of the administrator servlet (Admin2.java)
- The master WebFlow server runs as a servlet (and not as a
stand alone application started by a servelt). I wrote the servlet,
it works fine.
- The ORB instantiated by that servlet is a static property
(so other servlets can use it). I tried, it works.
- Once the server is up and running the servlet adds UserContextManager
to it, and "publishes" its reference as a static property.
- Also the reference to the master is kept as a static property.
In this way, any servlet has easy access to orb and reference
to the master server. Methods of the UserContextManager returns
the references to user contexts. That is any servlet can work
as a CORBA (WebFlow) client without instantiating orb, or reading
IOR from files/urls. The difference wrt now is that only one master
server per web server is allowed (otherwise mess with the static
variables; anyway for ORBAsec only one ORB per JVM is allowed).
user context
The user context is lauched as a separate process (thus no
changes). At OSC by servlet (again no changes), at ASC by krsh.
User login procedure at OSC
- User points the web browser to url of the Gateway servlet
(https).
- The server responses with userid/password dialog (basic authentication).
- If accepted, the servlet is run.
- The servlet generates a user.conf file and starts the slave
server (using Runtime.getRuntime.exec(java WebFlow.Server user.conf)).
[Btw I already know how to modify the code of WebFlow to eliminate
necessity of generating the conf file: the only variable is userID
that can be passed as a parameter]. The userID is taken from
apache (basic authentication)
- Once the slave server is up and running, the servlet returns
the welcome page.
Difference: the servelt does not return reference to the user
context - there is no ORB on the user side.
User login procedure at ASC
- User generates forwardable TGT.
- User starts an application: CharonClient.
- The client instantiates a secure ORB (so TGT must be ready
at this time). This is user authentication.
- Client does krsh (either java application or perl script,
do not know yet) to generate user.conf [see remark above] and
to create the user context. UserID is extracted form CORBA credentials
object.
- Client retrives IOR from the Web Server, connects to the
master server, extracts reference to the user context, adds CharonServer
to the user context
- Client starts a browser, and points it to the welcome page
- Client opens a server socket and listens to requests from
the browser.
Processing users requests
- web pages (links to external servers). Handled by the browser
and external server. No securtity. Maybe it is a good idea alway
to open external links in a new browser.
- html forms.
- I assume that those are always generated on the fly. Action
attribute points to actual servlets (say, https://heeche.osc.edu:8002/servlets/PSEservlet)
while at ASC they point to the localhost (http://localhost:8085/servlets/PSEservlet)
- At ASC CharonClient forwards the request to the CharonServer;
the server extract userID from the CORBA credentials object and
appends it to the servlet arguments (for example, request
http://localhost:8085/servlets/PSEservlet?arg=value on the client
side becomes http://tade.asc.mil:8001/servlets/PSEservlet?arg=value&userid=userid
on the server side); the server opens URL connection to this
url.
- The named servlet starts. First, the user id must be extracted
(otherwise the servlet cannot connect to the user context). To
keep servlets identical at ASC and OSC, I suggest the following:
if((userid=req.getParameter("userid")==null) userid
=getBasicAuthentication();
- Now the servlet can talk to the user context: add/extract
data from the context data, add/remove context and modules, etc.
There is no loger distinction between "servlet functionality"
and "gw functionality". The servlet can delegate work
to WebFlow directly.
- Services. (file browser, job status, etc). I need more time
for that. The problem is of course, communication between an
applet and the server. It seems to me that best candidate is
an url connection (currently administrator and login applets
work this way). At ASC this should not be a problem. Charon client
intercepts the requests, and translate them to CORBA requests.
At OSC we will need do https requests, and I will have to learn
how to do that. I believe this is doable. At the begining, we
can use unsecure http, and the user id will be passed as the
applet parameter. There will be a special servlet to handle these
request.
Now I am waiting for comments. Unless I hear veto, I will prepare
action items.
Tom