Re: Struts examples and also where to place use of SOAP
"Max Cooper" <[email protected]> Tue, 28 Jan 2003 01:20:14 -0800
| Newsgroups | gmane.comp.java.securityfilter.user |
|---|---|
| Message-ID | <002401c2c6ae$f2a3deb0$6401a8c0@ozzy> |
----- Original Message ----- From: Tony Baity To: securityfilter-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Sent: Monday, January 27, 2003 7:11 PM Subject: [securityfilter-user] Struts examples and also where to place use of SOAP Max, Since you are both active with Struts and securityfilter, I was wondering if you were planning to create any "How-to with Struts" links on the securityfilter page. I have been thinking about what features could be added to SecurityFilter to better support Struts, but there is no Struts-specific documentation in the works at this time. It is just like container-managed security for the most part, so there isn't any SecurityFilter-specific info to cover. From a "marketing" perspective, it might be worth doing some documentation, but there is no technical synergy there (yet). It would be nice to have a more complete user management system that would integrate with SecurityFilter (and perhaps also with container-managed authentication). Password changes, password expiration, self-registration, persistent cookies, and more could be part of the project. It should probably be a seperate project from SecurityFilter, but it would be a nice thing to have. I would certainly consider doing it with Struts. I have not had a chance to actually use the new Struts 1.1 role-to-action mapping yet but I will be shortly and will also be attempting to use web services/SOAP for supplying role and access level information. I haven't looked at that feature in Struts yet. Does it route you to one action or another based on roles? Struts has had support for specifying a role that you need to have to access an action mapping, but it doesn't really work that nicely. Since the request already got past the security, all you can do is send a 403 (forbidden) error. There is no chance for just-in-time authentication with that scheme, which would eliminate the useful option of sending links to co-workers (intranet app) or members (public site). It would be nice to be able to specify the roles in the struts-config file and have it work without this limitation. I am not sure I understand the web services part. SecurityFilter or container managed security will need a Realm, so that the security system can check passwords and role membership info. You could write a Realm implementation that makes requests to a web service for this info, but I am not sure if that is what you mean or not. It appears that securityfilter is the best place to do the SOAP and then just set up the Struts config as if regular container managed authorization is being used. SecurityFilter does look just like container-managed authentication to Struts, so it seems like that should work. I do not believe that I will need URL checking if all the actions are mapped to roles. Also, I do not believe that I would need something like JDBCRealms if the role and access level are directly supplied via web services. As I mentioned above, I don't think the Struts role stuff is that seamless an implementation, since it can't invoke a login sequence itself. One work-around for this limitation would be to have a role that every user of the site would have and require that role for the same mapping as the Struts action servlet. That would allow SecurityFilter/container to log users in as needed, and then Struts could just return 403 errors if the user does not meet the role requirement (which is the same thing the filter/container would do anyway). If you don't have any url patterns, SecurityFilter/container would not be doing anything anyway. I don't quite grok the web services part. If you want to use SecurityFilter/container security, you will absolutely need a Realm. However, Realms just adapt some source of security data to the security system, be it a DB, LDAP, XML file, or whatever. A web service that can be polled for username/password validity, and username/role membership info would be a suitable source of information for a Realm. If there is really a db behind it, though, it might be faster just to use JDBCRealm or write your own Realm implementation to hit the db. -Max Are these assumptions valid? -Tony ------------------------------------------------------------------------------ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now