Craig,
Maybe single sign-on is the wrong term to use. We are essentially trying to
create a single 'point of entry' into our client website that will
authenticate/authorize a user to those webapps that they are allowed to
access. Within this desire, I also need to maintain a distinct separation
between my lines of business, even though a user can have access to webapp1
in business 1, webapp1 in business2, etc. In my authentication procedure, I
build a set of nested beans for the user, something along the lines of
user
+--- business --- business --- business
+webapp +webapp +webapp
+webapp +webapp +webapp
. . .
. . .
Within each webapp bean is a list of validation codes that permit the user
to access enterprise data. Each webapp is responsible for extracting this
list of codes (by webapp by business) and then using this list to retrieve
data (typically goes into the WHERE clause on a SELECT statement). By
creating this set of nested beans one time (at authentication) was to
eliminate the need for each webapp to access our authentication database,
thereby (hopefully) allowing each webapp to focus only on the business
solution. Finally, by keeping each webapp in a separate directory
structure, I was also hoping to 'self contain' each webapp (i.e. each webapp
can be modified, tested, etc. without concern about potentially changing
other webapps).
Am I just really out in left field here?
Finally, in regards to the JSP/ASP integration, I've found a product called
JIntegra from Intrinsic Systems that provides a bi-directional bridge
between Java classes and ASP .COM objects (through the use of DCOM). I
think that by using a static class in a common classloader would also
provide the functionality (within the Java class) to talk to my .ASP
webapps. Has anyone out there used this product before? Any feedback?
Jerry
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 10:51 PM
To: Struts Users Mailing List
Cc: '[EMAIL PROTECTED]'
Subject: RE: Please help clarify or confirm -- HttpSession
On Thu, 13 Jun 2002, Jerry Jalenak wrote:
> Date: Thu, 13 Jun 2002 13:12:00 -0500
> From: Jerry Jalenak <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>,
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: RE: Please help clarify or confirm -- HttpSession
>
> A couple of reasons....
>
> 1. My company has three main lines of business that for various regulatory
> reasons need to be kept separate. This applies to deliver of content on
the
> web as well. What I am trying to accomplish is essentially a
single-signon
> capability (within the framework) that the business applications can then
> validate against (successful logon, etc.).
>
Single sign on is a different kettle of fish ... and it does *not* require
sharing sessions for the server to accomodate it. Tomcat 4, for example,
supports single sign on -- see the server config documents on the <Host>
element of server.xml for the details.
All this does for you, though, is avoid the need for a user to log in to
each app -- it does nothing for sharing information between apps. Your
best bet is to do something like:
* Store the shared info in a database or EJB that is accessible
to all the relevant webapps.
* Store shared information in a static variable associated with
a class that is loaded from the shared class loader (so that
there really is only one instance).
Figuring out how to relate the information from various webapps together
is an exercise left to the user, but you can probably do something with
the fact that request.getRemoteUser() will return the same value in every
webapp.
> 2. I am also needing to integrate non-JSP applications (.ASP for instance)
> into the framework. I know they cannot directly access my JavaBeans, but
> I'm wondering if a .ASP page could access the HttpSession data.....
>
I don't have a clue how you could possibly accomplish this, given that the
ASP pages aren't running inside the same JVM that Tomcat is.
> Jerry
>
Craig
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
This transmission (and any information attached to it) may be confidential and is
intended solely for the use of the individual or entity to which it is addressed. If
you are not the intended recipient or the person responsible for delivering the
transmission to the intended recipient, be advised that you have received this
transmission in error and that any use, dissemination, forwarding, printing, or
copying of this information is strictly prohibited. If you have received this
transmission in error, please immediately notify LabOne at (800)388-4675.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
