Michael, i believe Axis can plug into "container security configuration"....there are some flags to switch on i think (http://livedocs.macromedia.com/jrun/4/Programmers_Guide/wssecurity2.htm)
-- dims On Tue, 26 Oct 2004 14:03:40 -0700, Michael Merz <[EMAIL PROTECTED]> wrote: > 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. > > -- Davanum Srinivas - http://webservices.apache.org/~dims/
