SOAP Authorization Methods
This chapter is from the book
This chapter is from the book
This chapter is from the book
So far, we have examined security technologies with which Web services can authenticate users and protect transmitted data from eavesdropping or alteration by inappropriate parties. From a technology point of view, network security relies on cryptographic methods such as message digests, digital signatures, and message encryption. Authorization, the security aspect covered in this section, is different from the others because it is not based on cryptography.
Authorization denotes granting authority, including granting access to resources based upon access rights. The purpose is to control access over resources such as Web resources, databases, and so on. Perhaps the most basic implementation of this idea is the access control list (ACL), which defines a mapping from entities to resources that can be accessed by each entity. A slightly more sophisticated model is role-based access control (RBAC), which maps entities to roles and then roles to resources. This model simply adds one extra layer of abstraction to the ACL model.
Three types of authorization methods are relevant for our SOAP architecture. URL authorization controls access to Web resources such as HTML pages and servlets. Java class authorization can be implemented using the Java Authentication and Authorization Services (JAAS) package. Finally, an authenticated entity may be issued a standardized set of security assertions that describe access rights for that entity and can be shared among trading partners. These three methods are examined in detail in this article.
URL Authorization
Tomcat provides a means of defining user identities, user-role mapping, and role-resource mapping. The file <TOMCAT>/conf/tomcat-user.xml contains these mappings, as shown in Listing 1.
Listing 1: Tomcat User File Configuration
<tomcat-users> <user name="SkateboardWarehouse" password="wsbookexample" [ccc] roles="MyCustomer" /> <user name="WeMakeIt" password="wsbookexample" roles="MySupplier" /> <user name="Both" password="wsbookexample" roles= [ccc]"MyCustomer,MySupplier" />
The tomcat-users element includes a collection of users, and user defines a user identity, a password, and any roles assigned to it. Listing 2 illustrates access control for servlets.
Listing 2: Configuration of Access Control over Servlets
<web-app> <display-name>Basic Authentication Sample</display-name> <servlet> <servlet-name>PriceCheckServlet</servlet-name> <servlet-class>com.sams.xxxx.PriceCheckServlet</servlet-class> </servlet> <servlet> <servlet-name>POServlet</servlet-name> <servlet-class>com.sams.xxxx.POServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>POServlet</servlet-name> <url-pattern>/servlet/justsample/POServlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>PriceCheckServlet</servlet-name> <url-pattern>/servlet/justsample/PriceCheckServlet</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Protected Area</web-resource-name> <url-pattern>/servlet/justsample/POServlet</url-pattern> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>MyCustomer</role-name > </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Protected Area</realm-name> </login-config> </web-app>
Here we have different servlets for price checking and purchase order processing. Because Axis has a router servlet, all application classes are accessed through the router. However, if we prepare a servlet for each application class, controlling access to each of them is fairly simple, as the example demonstrates.