Hi Wolfgang, Thanks much for the great work on this! We should talk to the Axis guys about what their plans regarding security are -- Dims, Ias? Are you guys planning on implementing a role-based security model in Axis -- that e.g. pipes the container security configuration (user, roles) through to the WebService?
I haven't tried out your code, yet -- just looked at it. I like the fact that it's pretty much separate from the rest of the WSM implementation, integrated only through the XML (config) file. I'll give it a spin soon. This way, it can easily be customized and integrated when needed. It's awesome to have support for security extensions in WS running on Tomcat/Axis! :) Since the security annotations are also particularly interesting (since mandatory) for the JSR-109-type deployment scenario, we should try to make as few assumptions about the runtime as possible. Maybe we can come up with an abstraction layer once we gathered some experience with the whole security model. The Axis model could implement such an abstract interface. Comments, ideas anyone? Cheers, -michael -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 10:14 AM To: [email protected] Cc: Michael Merz; Jonathan Colwell Subject: @SecurityIdentity, @SecurityRoles Hi Michael and Jonathan, I've not forgot about @SecurityRoles stuff, but been think how to integrate @SecurityXXX annotation with Tomcat/Axis's security model. The section "Authenticating the caller" of Axis's Web Service Security page ( http://ws.apache.org/axis/java/security.html ) states "Note that Axis does not yet integrate with the servlet API authentication stuff." I think the integration will never be implemented unless the securiy model of servlet spec is changed. All authentication/authorization stuff of servlet container is done in the container itself. There's no way for servlets to get involved in the authentication/authorization process of the servlet container. Exactly same thing happens to Axis since Axis is just a servlet so that it's impossible for Axis to be integrated with the servlet API authentication. Thus, Axis has its own security mechanism using users.lst and perm.lst. As long as I investigated, the security model of Axis is user-based. The users.lst holds username/password combinations. The perms.lst holds username/action( which is allowed to be invoked by the username) We have two choices to build the security model. One is just to use Axis's users.lst. (user-based) The other is to make our(Beehive) own role-based security model. (probably we can make a file like tomcat-users.xml and read username/password and roles out of the file.) The advantage of the former one is that the current Axis users can reuse thier users.lst file. The disadvantage is that it's user-based authorization and always sticks with Axis. The advantage of the latter one is that role-based authorization and can be used with a web service container other than Axis. The disadvantage is that it required for admin to maintain two username list files. ( Axis's one and Beehive's one ) It's kinda troublesome for developers and admins. I've implemented with the former one. (Attached on this email) The file, WsmAuthenticationHandler.java, resides in the wsm/src/runtime/org/apache/beehive/wsm/axis/handlers directory. ( Please create a "handlers" directory under the "axis" directory ) To enable the security, please follow the procedures below. 1. Adding <handler type="java:org.apache.beehive.wsm.axis.handlers.WsmAuthenticationHandler "/> element between <handler type="java:org.apache.beehive.wsm.axis.DropInDeploymentHandler"> element and <handler type="java:org.apache.axis.handlers.JWSHandler"> element in the server-config.wsdd. ( I think the order is not that important though. ) 2. Creating a users.lst file in AnnotatedAxis/WEB-INF directory. File can be like this. ( Don't need hyphens ) --------------- wolfgang mypass michael yourpass --------------- 3. Modifying AddressBookWebService.jws like below. @WebService( targetNamespace="http://www.beehive.com/AddressBook";) @SecurityRoles(rolesAllowed={"wolfgang"}) public class AddressBookWebService implements AddressBook { ..... @WebMethod @SecurityRoles(rolesAllowed={"michael"}) public void addEntry(String name, Address address) throws RemoteException { addressBook.addEntry(name, address); } ..... @WebMethod public Address getAddressFromName(String name) throws RemoteException { return addressBook.getAddressFromName(name); } 4. In client side, use the wsdl2java tool to generate java files. This is snippet of my client code. binding = (com.beehive.www.AddressBook.AddressBookWebServiceSoapBindingStub) new com.beehive.www.AddressBook.AddressBookWebServiceServiceLocator().getAdd ressBookWebService(); binding.setUsername("wolfgang"); binding.setPassword("mypass"); binding.addEntry("Nick",new Address()); The user "wolfgang" can invoke all methods. The user "michael" can invoke ony addEntry method. The getAddressFromName method is allowed to be invoked by only user "wolfgang". ( This is because even though the getAddressFromName method is not annotated with @SecurityRoles, the CLASS is annotated with @SecurityRoles( rolesAllowed={"wolfgang"}) ) If user "michael" trys to invoke the getAddressFromName method, (401)Unauthorized exception will be thrown. @SecurityRoles.rolesReferenced and @SecurityIdentity are not implemented yet. How can we use these annotations with web service ? @SecurityRoles.rolesReferenced can be used with servlets if role is hardcoded like below in the source of servlet and allow admin/deployer to change role to access the servlet. doGet(HttpServletRequest req, HttpServletResponse res )...{ if( req.isUserInRole("myrole") ){ ... }else{ ... } } But it's impossible for web serivce to do like that because web service don't get an interface object such as req object above from web service container. Can I think about @SecurityIdentity later or when we integrate Beehive with EJB ? Thanks in advance. wolfgang ps) To Michael, please don't check in the attachment. I gotta put comments and might need some modification. Although I said we have two ways for implementing security models above, I can implement both and let developers/deployers choose one out of two.
