Back to normal programming. No more infocard
With a typical Access Manager
deployment atop a webserver or appserver, there are many instances where apart from the Access Manager
services deployed, one may deploy other applications on the same server instance and may need to "protect" them. The right way of going about it is to deploy a policy agent
on the same server instance. I noticed that in some cases folks choose not to deploy an agent but "embed" code in every page of their webapp to check for the validity
of the SSOToken
issues by AM
and enable access to thise pages that they need "protected".
Well, if all one needs is to protect a few URI's that reside on the same server instance as AM
, one could also use a Servlet Filter
to do the same without having to embed code in every page of their application to check for it. This is a simple SSO only method and not
a replacement for a policy agent
Here's what one needs to do to enable this.
Declare the [filter] element in your web application deployment descriptor. For Sun's Webserver
it would be the default-web.xml file.
Map the filter to a servlet by defining a <filter-mapping> element in the deployment descriptor. This element maps a filter name to a servlet by name or by URL pattern.
Add the URL's you would like to "protect" to the url-pattern tag element.
Now compile the attached code
, build a jar file and add it to your servers classpath.
for some reason I just cannot post code on this blog. No matter what I try, the code gets converted over to HTML. I did follow Pat's advise, but that didnt help. So I'm uploading the NNAgent.java file and providing you a link to download it instead of posting code as inline text
Restart your webserver.
- Try accessing the "protected" URL without authentication.
- Try accessing the "protected" URL with authentication.
You'd see the difference...
This is NOT
a replacement for a Policy Agent
. This is just an FYI/example
of how one could achieve SSO
only using a Filter