Hi Conor, thanks for your reply.
The problem is that we have very fine-grained access control
requirements beyond what is used by the manager application where access
is yes/no all/none.
Here is our scenario: we want to return provide different levels of
access to the web service clients depending on who they are. the web
service will provide images from a corporate database to internal
applications. a lot of the images are in the public domain, but there
are also privately copyrighted collections, and images that legally
cannot be displayed without permission (indigenous photos).
So we need to provide a default level of access that anything can
connect as (eg - null user/pass) that can see public stuff, but to
access any of the restricted images the client has to supply credentials
that map to a role that has access to those resources.
Because of this, I don't want to use the <security-constraint> tag to
restrict access to my service, since then default users won't be able to
access it. I'm posting on the tomcat list about trying this with an
empty user tag, like this: "<user username="" password=""
roles="public"/>", but no-one has the final answer yet...
I'm going to try to write a few examples with xFire/tomcat and see if I
can get it to do what I want, and I'll post back the results...
* Matthew Kerle
* * IT Consultant *
* Canberra, Australia*
Mobile: +61404 096 863
Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Web: Matthew Kerle <http://threebrightlights.blogspot.com/>
Conor MacMahon wrote:
Hi Matthew,
Sounds like the security model you're using has the
same needs as the manager application within tomcat (i.e. running at
http://localhost:7080/manager/html/list)? If so, maybe you can just
use that security model, which does typical J2EE security url
constraints, within the web.xml (i.e.
$CATALINA_HOME\server\webapps\manager\WEB-INF\web.xml). That manager
also uses tomcat-users.xml, so it would be very easy to migrate you're
existing context to mimic the manager one?
Just means you don't have to do anything fancy with
HTTP/SOAP headers, the security is done using the typical known (and
trusted!) way of url mapping security constrains within your web.xml?
Sorry in advance if I have missed a reason why the above was not
suitable for you :).
Best,
Conor
------------------------------------------------------------------------
*From:* Matthew Kerle [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, 15 August 2007 2:22 PM
*To:* [email protected]
*Subject:* Re: [xfire-user] http basic auth documentation
Hi Yogesh.
Thanks for your input, the application will be deployed to an
intranet, so will don't need any SSL or message digest encryption. The
client api doc link is good but doesn't that apply to the client side?
My question relates to accessing HTTP or SOAP headers from the
ServiceImpl class on the server side from xFire...
--
*Matthew Kerle
**
*
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
