SSO ID in the first request

[Fredrik Tolf <fr...@dolda2000.com>]

Hi List!

We are developing a couple of webapps that need to talk to each other,
and to do that, we have been using HTTP to just fetch certain URLs from
the other webapps to the requesting webapp. To ensure that the
programmatic request is carried out in the context of the user doing the
client request to the first webapp, we are fetching the SSOID cookie
value and putting that in the request to the second webapp. (I hope I'm
making myself clear)

However, we have encountered the problem that if the user is not already
authenticated upon the client request, the SSOID cookie doesn't exist,
so we can't forward its value to the second webapp. We haven't been able
to find a good workaround for this problem so far, so I'm turning to you
good people on the list for assistance.

What do you think? Are we making a mistake in using the SSOID to begin
with and should just think of another way, or is there a way to do this
properly. We have thought of the following workarounds -- could you
please tell me what you think of them?

1. Write a subclass of org.apache.catalina.authenticator.SingleSignOn,
which catches a call to the register() method and puts that SSOID in a
request attribute, which can later be fetched from another webapp to do
the second request.
2. Write a filter, which upon detection of a non-existing SSOID cookie,
sends a redirect back to the same URL to the client, which should make
the AuthenticatorBase valve send the SSOID cookie to the client, so that
it exists when the client comes back.
3. Use reflection somehow to fetch the SSOID cookie from the SSO valve.
I don't think this is possible, though, thanks to Tomcat's protection
against reflection from webapps.

Thanks for reading!

Fredrik Tolf



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: SSO ID in the first request

[Gregor Schneider <rc...@googlemail.com>]

Hi Fredrik,

> >
> > HttpSession session = .....;
> > session.setAttribute(String nameOfYourObject, Object yourObject);
> > Object yourObject = session.getAttribute(String nameOfYourObject);
>
> Surely, this cannot be correct? It would take me some effort to try
> sharing attributes between webapps, so I can't try it immediately, but
> different webapps even set different session cookies (JSESSIONID, that
> is) to the client, so it is very hard for me to believe that all webapps
> are sharing the same session.
>
Sure they do, we're doing it here, and it's pretty easy to implement.
However, to make all webapps using the same JSSOSessionID, you have to
enable the SingleSignOn-valve in your server.xml:

<Valve className="org.apache.catalina.authenticator.SingleSignOn"/>

This ensures that all webapps share the same session.

Cheers

Greg
-- 
what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: SSO ID in the first request

[Fredrik Tolf <fr...@dolda2000.com>]

On Tue, 2007-03-13 at 19:34 +0100, Gregor Schneider wrote:
> I guess you're talking about JSSOSessionID-Cookie, right?

Indeed.

> I believe the whole design is not too smart:
> 
> Since all webapps are sharing the same session, I'd store the needed
> values as session-attributes (too lazy to look it up right now, but
> should work like
> 
> HttpSession session = .....;
> session.setAttribute(String nameOfYourObject, Object yourObject);
> Object yourObject = session.getAttribute(String nameOfYourObject);

Surely, this cannot be correct? It would take me some effort to try
sharing attributes between webapps, so I can't try it immediately, but
different webapps even set different session cookies (JSESSIONID, that
is) to the client, so it is very hard for me to believe that all webapps
are sharing the same session.

In any event, though, it isn't so much about sharing data. We have one
webapp that produces a common header for all pages, and the others fetch
that header through an HTTP GET call.

> However, this works only when running all your webapps within the same
> Tomcat-instance.
> If this is not the case, take a look at webservices.

Thanks for the tip, but I think any SSO hack would be far easier to
implement and maintain than starting to use web services.

Fredrik Tolf



---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: SSO ID in the first request

[Gregor Schneider <rc...@googlemail.com>]

I guess you're talking about JSSOSessionID-Cookie, right?

I believe the whole design is not too smart:

Since all webapps are sharing the same session, I'd store the needed
values as session-attributes (too lazy to look it up right now, but
should work like

HttpSession session = .....;
session.setAttribute(String nameOfYourObject, Object yourObject);
Object yourObject = session.getAttribute(String nameOfYourObject);

However, this works only when running all your webapps within the same
Tomcat-instance.
If this is not the case, take a look at webservices.

HTH

Greg
-- 
what's puzzlin' you, is the nature of my game
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org