[openroad-developer] RE: New OpenROAD HTTP Gatekeeper

Mon May 5 08:36:04 PDT 2008

Removing signatures... They take up too much space.  -Joe

________________________________

From: openroad-developer-bounces at lists.ingres.com
[mailto:openroad-developer-bounces at lists.ingres.com] On Behalf Of Bodo
Bergmann
Sent: Monday, May 05, 2008 8:22 AM
To: openroad-developer at lists.ingres.com
Subject: RE: [openroad-developer] RE: New OpenROAD HTTP Gatekeeper

Hello openroad-developers,

to give you some background information on the topic:

Currently the OpenROAD HTTP Gatekeeper is provided as source only
(SRS.java)

and is basically a demo code containing different (hard-coded) examples
on how things can be done.

That is you manually have to edit and compile it in order to get it
ready for production use.

========================================================================
======

The new gatekeeper (source: OrHttpGk.java) should provide an
out-of-the-box experience

by just using the two *.class files and configuration options, which can
be set in the web.xml file.

The new classnames have been used in order to keep the old SRS.* files
for reference (as they contain some configuration examples).

The servlet class itself should work with different web servers (for
JBoss, WebSphere, WebLogic, etc.),
no Tomcat specific Java functions have been used.

BASIC authentication should be supported by any web server, that's why
none of the more advanced options have been used.

Configuration files (web.xml for Tomcat >= 5.0) might be slightly
different, but it shouldn't be hard to convert them.

Preparations

1. Create a new subdirectory in $CATALINA_HOME/webapps, e.g. mkdir
$CATALINA_HOME/webapps/openroad

2. Create a subdirectory WEB-INF and copy the web.xml there

3. Create a subdirectory "classes" under WEB-INFand copy the
OrHttpGk*.class files there

4. If not done yet: Copy the $II_SYSTEM/ingres/orjava/openroad.jar file
into $CATALINA_HOME/shared/lib
5. Configure Tomcat - Authentication and Servlet Options - see
"Configuration" below

6. Restart Tomcat

Configuration

Authentication

The web.xml is configured to use BASIC web server authentication (with
username & password) with a role called "orspo_users".

A default Tomcat installation will use the
$CATALINA_HOME/conf/tomcat_users.xml file for authentication
information.

You will have to add this role and according user entries under the
<tomcat-users> tag in this file, e.g.

	<tomcat-users>
	  ...

	  <role rolename="orspo_users"/>
	  <user username="Bodo" password="xyz" roles="orspo_users"/>
	</tomcat-users>

Servlet Options

The servlet can be configured by the following two InitParameters within
web.xml file:

OpenROAD_ServerApp

It defines the name of the OpenROAD Server application the gatekeeper
connects to.
If this parameter is missing or if it set to * it allows providing the
application name by the "image" parameter of the Initiate request.

It is recommended to have different webapps for different OpenROAD
applications.

logcalls

Will log requests to the OpenROAD Gatekeeper to file
$CATALINA_HOME/logs/localhost_log.yyyy-mm-dd.txt when set to 1.

This is for testing purposes.

Some FAQs

Q:  How to provide the username & password on initiate?

A:

The username and password credentials can be provided in the flags
parameter of the RemoteServer.Initiate() method,

e.g. in the above case:

    rso.Initiate( ..., flags=':berbo01:xyz::');

If the username and password are not provided the user will be prompted
to provide the credentials (only on the first Initiate).

Q: How is security applied?

A:
Authorization is done using the web server.
An authorized user can call any SCP provided by the application(s)
configured by the OpenROAD_ServerApp config parameter.

Additional security should be provided by using SSL encryption - see
http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html
<blocked::http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html> .

Customized authentication/authorization can be accomplished by advanced
web server configuration and/or
customizing the Java source of the Gatekeeper (this will require a Java
SDK).

Q: Can the authorization be switched off ?

A:

The web server authentication can be switched off by removing the

<security-constraint>, <login-config> and <security-role> tags from the
web.xml file.

This can be useful for testing or if you use it in a trusted
environment.

Q: What is the URL of the gatekeeper?

A:

The URL is the address of the webserver extended by the name of the
directory for the web application,
e.g. <blocked::http://myhost:8080/openroad> http://myhost:8080/openroad
or https://myhost:8443/openroad <blocked::https://myhost:8443/openroad>
.
It is not required to append the name of the servlet, as this is already
configured in the web.xml file.

Bodo.

________________________________

From: openroad-developer-bounces at lists.ingres.com
[mailto:openroad-developer-bounces at lists.ingres.com] On Behalf Of Joseph
C. Kronk
Sent: Monday, May 05, 2008 4:59 PM
To: openroad-developer at lists.ingres.com
Subject: [openroad-developer] RE: New OpenROAD HTTP Gatekeeper

Can't these examples be included in the new HTTP Gatekeeper?  I would
really like to have just one version.

-Joe

________________________________

From: Bodo Bergmann 
Sent: Monday, May 05, 2008 7:48 AM
To: Durwin Wright; Joseph C. Kronk
Cc: Roger L. Whitcomb; David Tondreau
Subject: RE: New OpenROAD HTTP Gatekeeper

I thought we want to keep the old one as it contains examples,

e.g. for 

-  using permitted SCPs via web.xml configuration

-  using permitted SCPs via SCP call (hard-coded)

-  restricting access to AkaNames via hard-coded settings

The new HTTP Gatekeeper does not restrict access to SCPs

as a user that has access to an application usually uses more than one
(or even all) of its SCPs anyway.

It restricts access to Users/Groups and AkaName via configurable items
in the web.xml.

Bodo.

________________________________

From: Durwin Wright 
Sent: Monday, May 05, 2008 3:50 PM
To: Bodo Bergmann; Joseph C. Kronk
Cc: Roger L. Whitcomb; David Tondreau; Durwin Wright
Subject: RE: New OpenROAD HTTP Gatekeeper

Why not just replace the existing SRS.java code with the new code?  Is
there a reason to keep the old version?  I thought your new gatekeeper
was going to replace the old gatekeeper.

Durwin Wright | Sr. Architect | Durwin.Wright at ingres.com
<mailto:Durwin.Wright at ingres.com>  | Ingres | 500 Arguello Street |
Suite 200 | Redwood City | CA | 94063 | USA
<http://maps.google.com/maps?q=500+arguello+street,+94063&ll=37.487297,-
122.233200&spn=0.004602,0.012771&t=k&hl=en>   +1 650-587-5523 | fax: +1
650-587-5550 

________________________________

From: Bodo Bergmann 
Sent: Monday, May 05, 2008 1:20 AM
To: Joseph C. Kronk; Durwin Wright
Cc: Roger L. Whitcomb; David Tondreau
Subject: RE: New OpenROAD HTTP Gatekeeper

After review by Roger (and no commend from David) I'm going to provide
an IP now.

As we already have an "web.xml" file, which works in conjunction with
the SRS.java code

I will name the new one differently, e.g. "web_OrHttpGk.xml".

The same applies to the readme.txt file - I'll create a new (additional)
one - "readme_OrHttpGk.txt".

Any objections?

Required changes to the build/packaging process (Durwin: please check if
this is possible): 

It should create a new subdirectory WEB-INF (under
$II_SYSTEM\ingres\orjava).

This directory should contain:

- a "web.xml" file, which is a copy of the web_OrHttpGk.xml source

- a "classes" subdirectory, which contains the files generated by
compiling the OrHttpGk.java source:

    OrHttpGk.class and OrHttpGk$OrHttpGkListener.class

This way the user will be able to just copy the whole WEB-INF into a
subdirectory of the %CATALINA_HOME%\webapps directory,

and only has to configure the contained web.xml file - no Java compiling
required.

Bodo.

________________________________

From: Bodo Bergmann 
Sent: Monday, April 07, 2008 8:40 PM
To: Roger L. Whitcomb; David Tondreau
Cc: Joseph C. Kronk
Subject: RE: New OpenROAD HTTP Gatekeeper

Roger,

thanks for talking your time to review.

I'll change the comment - a leftover from another source I based my code
upon :)

Bodo.

Bodo Bergmann

Senior Software Engineer

OpenROAD Worldwide Development

Ingres Corp.

________________________________

From: Roger L. Whitcomb 
Sent: Monday, April 07, 2008 8:25 PM
To: Bodo Bergmann; David Tondreau
Cc: Joseph C. Kronk
Subject: RE: New OpenROAD HTTP Gatekeeper

Bodo -

    I have reviewed the code.  Thanks for passing it by me.  It looks
fairly good to me, and seems to be well documented.  I did notice
something funny (as compared to the "web.xml" file):  in the comments
for the last nested class which say:

// Note that because nested Java classes are really just a compiler

// trick and not an inherent JVM feature, the REAL name of this class

// (after compilation) is "SRS$SRSListener". That is why the

// <listener-class> element in your web.xml file must refer to

// "SRS$SRSListener" and not "OrHttpGk.OrHttpGkListener".

I think this should read "(after compilation) is
"OrHttpGk$ORHttpGkListener"." and similarly on the last line.

But otherwise it seems like good Java-style code with proper Java style
and naming conventions.

Roger Whitcomb

Architect, Engineering

Ingres Corp.

+1 (650) 587-5596

roger.whitcomb at ingres.com

________________________________

From: Bodo Bergmann 
Sent: Friday, April 04, 2008 2:32 AM
To: Roger L. Whitcomb; David Tondreau
Cc: Joseph C. Kronk
Subject: FW: New OpenROAD HTTP Gatekeeper

Roger & David,

Joe asked me to send you the new OpenROAD HTTP gatekeeper for review
(before I submit an IP):

Roger:   Please review the Java code

David:    Please review the namespace

Thanks in advance,

Bodo.

Bodo Bergmann

Senior Software Engineer

OpenROAD Worldwide Development

Ingres Corp.

________________________________

From: Bodo Bergmann 
Sent: Thursday, March 20, 2008 2:21 PM
To: Joseph C. Kronk
Cc: David Tondreau; Lee Howard; Durwin Wright
Subject: New OpenROAD HTTP Gatekeeper

As you know I developed a new (additional) Java HTTP Gatekeeper (see
attached source).

It has been tested by David and also by some support staff guys here in
Germany.

The new gatekeeper should provide an easy to use out-of-the-box
experience and configurable options

via changing an xml file rather than code.

The new classnames have been used in order to keep the old

SRS.* files for reference (as they contain some configuration examples).

The next step is to:

1.	Provide an IP which adds the sources to the orjava directory:
I can do this 
2.	Changes in the Windows build and packaging scripts, as the
*.class files will have to be delivered in compiled form,
	so users do not have to compile them (which requires a JDK):
Durwin? 
3.	Provide a .NET port with the same functionality: Durwin? 
4.	Update the documentation for HTTP access (see attached readme):
	It should reference the OrHttpGk classes rather than the
existing SRS.java source
	(which should still be mentioned as a source for other examples)
: Lee? 

Is this the way to go or do I miss something?

Bodo.

Bodo Bergmann

Senior Software Engineer

OpenROAD Worldwide Development

Ingres Corp.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ingres.com/pipermail/openroad-developer/attachments/20080505/3584cb02/attachment-0001.html