-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Garey,
(Thanks for taking this back onto the list).
On 10/19/2011 5:07 PM, Garey Mills wrote:
> Geoserver only has basic authentication on an object by object
> level. We are deploying it in a unversity that has a Centralized
> Authentication Server, or CAS. CAS has a implementation that can be
> used in tomcat, and that is realized as a set of filters.
Do you control anything about the implementation of the CAS filters?
> The first problem is that filters have the severe limitation of
> only allowing one asterisk, making it impossible (as far as I can
> see) to distinguish URLs on the basis of recognizing a pattern in
> the query string.
It's true, filters can only be mapped by relatively simple url-pattern
matching constraints. That doesn't mean the the Filter itself can't be
smart about how it does it's own checks. There is no prohibition on
further processing of the URL to determine how to act. These CAS
filters have to be used in situations where the servlet spec's paltry
url-pattern mapping semantics must be overcome, right? I'm surprised
to hear you say that they are so inflexible.
> So this seems to necessitate recognizing the pattern in code,
> modifying the URI in some recognizable way (or setting an attribute
> on the request) and redirecting so that it gets intercepted by the
> CAS filter(s).
You can set an attribute on the request and then continue the call
chain (where the CAS filter is later in the chain): there is no need
for a redirect and/or forward to occur.
> This makes it very difficult to work with Geoserver directly. While
> the code is available, this is a massive project.
>
> On the other hand, I got my scheme to work more or less, but there
> are problems. I got it to work by instantiating a
> RequestDispatcher by getNamedDispatcher and finding the servlet
> name ("dispatcher") in Geoserver's web.xml. However, I find that
> the content that Geoserver returns embeds a number of URLs that
> point back to itself. I would have to somehow intercept Geoserver's
> return in my fronting webapp and rewrite those URLs.
If this is the strategy you have chosen, then yes, you will have to
act as a proxy/reverse proxy. You're going to have to do that in any
event. And, it's a total pain in the neck. Better to intercept all the
traffic on it's way to Geoserver and do whatever modifications you
need to on the fly, there, than to try to proxy everything and rewrite
links, etc.
> If I bite the bullet and attempt to change Geoserver, there is
> another difficulty.
If you can customize Geoserver's behavior by inserting your own
filters somewhere in the filter chain (which is trivial of course),
then I would highly recommend that route. Dual webapps where one of
them does authentication and acts as a re-writing reverse proxy sounds
like madness.
> I am attaching Geoserver's web.xml. Here also are the CAS filters
> from my fronting webapp:
>
> <filter> <filter-name>CAS Single Sign Out Filter</filter-name>
> <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class>
>
>
</filter>
Hah. I usually see that called SingleSignOn, but I guess if you want
to get out of everything quickly, that will help, too. :)
> A major problem is how to integrate these two. If you can tell me,
> maybe I can attempt to introduce the necessary changes to the
> Geoserver servlet.
I didn't see the web.xml from Geoserver, but merging web.xml files
shouldn't be /too/ hard. If you want to keep Geoserver's webapp
relatively untouched (for easier upgrades, etc.) you could use XSLT to
process their original and add your own stuff (for instance,
installing your own filters at the beginning of the filter chain with
all their filters running afterwards).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6gjYUACgkQ9CaO5/Lv0PBjZQCggQWKntrSt/Ko1tgND8tldEnJ
SWMAniNt+FtWZWqG3M+MwybohZ51w3Mr
=a9sS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
