Hi,
I've implemented similar functionality in another project I've worked on
using a typical J2EE security configuration. I think it's important to
frame this problem from both the server and client points of view.
On the server side, it's probably easiest to use the built in J2EE security
mechanisms. It would be best if you could map servlets requiring
authentication to a different URL than the read-only servlets
(/geoserver/wfst perhaps?). You can then set up role based
<security-contraint> elements in the apps web.xml file, and configure the
security realm for the web service in server.xml. The realm is where you
connect a user database (LDAP/custom/file based/...) to the servlet
container.
On the system we implemented we essentially had 2 roles: editor, admin.
Editors can enter content to the DB but we also needed fine-grained access
control so that editors can only edit their own entries. We implemented
this part using a servlet filter which checks a userId column in the DB per
entry (or feature) based on the authenticated user ID. I can provide more
details of the setup if anyone thinks it's applicable.
On the web-client side (ie. mapbuilder, not uDig) it's a little trickier.
We will typically be making calls to these web services using an
XmlHttpRequest object so this is where the security handling has to be
implemented and tied to some form of user interface. What happens when an
XmlHttpRequest object gets an BASIC authentication prompt? We also need to
pass on cookies cookies or request param credentials somehow. If the web
service lives in a different domain than the client app we also need to pass
all this information through our proxy servlet. If the mapbuilder app and
geoserver instance were in the same domain, then there might be some
simplification by using the tomcat single-sign-on valve, but that is still a
question. An even trickier problem is how to pass on credentials in an
<IMG> SRC attribute for GetMap requests.
All the above assumes that security is at the HTTP layer. There are other
ways to implement as well like Jody described. Passing authentication
tokens along as a request parameter seems to be a viable option as well.
Mike