Welcome!

Cloud Security Authors: Pat Romanski, Elizabeth White, Zakia Bouachraoui, Yeshim Deniz, Liz McMillan

Related Topics: Weblogic, Cloud Security

Weblogic: Article

WebLogic Web Services Security

WebLogic Web Services Security

Security is a priority for most of our customers. As more and more customers adopt Web services, they find a need to understand how Web services can be secured and what authentication mechanism to use. In order to keep Web services open and support multiple client types, it's necessary to understand how to handle Web-services security.

This article takes a look under the hood of WebLogic Web services security. I'll explain how WebLogic Web services can be secured, how authentication works, and how to develop clients in various programming languages to authenticate against WebLogic Web services.

WebLogic Web Service Components
Web services hosted by WebLogic Server are implemented using standard J2EE components such as EJBs and JMS, and are packaged as standard J2EE enterprise applications. WebLogic Web services use Simple Object Access Protocol (SOAP) 1.1 as the message format and HTTP 1.1 as the connection protocol.

The Web services runtime component is a set of servlets and associated infrastructure needed to create a Web service. One element of the runtime is a set of servlets that handle SOAP requests from a client. These servlets are included in the WebLogic Server distribution. Another element of the runtime is an Ant task that generates and assembles all the components of a WebLogic Web service.

WebLogic Web services are packaged as standard J2EE Enterprise applications that consist of the following specific components:

  • A Web application that contains, at a minimum, a servlet that sends and receives SOAP messages to and from the client. It's automatically included as part of the Web services development process.
  • A stateless session EJB that implements an RPC-style Web service or a JMS listener (such as a message-driven bean) for a message-style Web service.

    In an RPC-style Web service, the stateless session EJBs might do all the actual work of the Web service, or they may parcel out the work to other EJBs. The implementer of the Web service decides which EJBs do the real work. In a message-style Web service, a J2EE object (typically a message-driven bean) gets the messages from the JMS destination and processes them.

    WebLogic Web services are packaged as Enterprise archive (.ear) files that contain the Web application's Web archive (.war) files and EJB archive (.jar) files.

    Securing WebLogic Web Services
    Since WebLogic Web services are packaged as standard J2EE Enterprise applications, access to a Web service may be secured by securing some or all of the following standard J2EE components that make up the Web service:

  • The SOAP servlets
  • The stateless session EJB upon which an RPC-style Web service is based

    Basic HTTP authentication or SSL can be used to authenticate a client that is attempting to access a WebLogic Web service. Because the preceding components are standard J2EE components, they may be secured using standard J2EE security procedures.

    Securing Message-Style Web Services
    A message-style Web service may be secured by securing the SOAP servlet that handles SOAP messages between the client and the service.

    When the Web service is assembled, either manually or by using the wsgen Ant task, you reference SOAP servlets in the web.xml file of the Web application. These servlets handle the SOAP messages passed between WebLogic Server and client applications. They are always deployed on WebLogic Server and are shared by all deployed WebLogic Web services.

    The particular SOAP servlet referenced by a Web service depends on its type (RPC-style or message-style). The following list describes each SOAP servlet:

  • weblogic.soap.server.servlet.DestinationSendAdapter: Handles SOAP messages in a message-style Web service that receives data from a client application and sends it to a JMS destination
  • weblogic.soap.server.servlet.QueueReceiveAdapter: Handles SOAP messages in a message-style Web service that sends data from a JMS Queue to a client application
  • weblogic.soap.server.servlet.TopicReceiveAdapter: Handles SOAP messages in a message-style Web service that sends data from a JMS Topic to a client application
  • weblogic.soap.server.servlet.StatelessBeanAdapter: Handles SOAP messages between an RPC-style Web service and a client application

    For example, in a message-style Web service in which client applications send data to a JMS destination, the SOAP servlet that handles the SOAP messages is weblogic.soap.server.servlet.DestinationSendAdapter. The wsgen Ant task used to assemble the Web service adds the elements shown in Listing 1 to the web.xml deployment descriptor of the Web application.

    To restrict access to the DestinationSendAdapter SOAP servlet, you first define a role that is mapped to one or more principals in a security realm, then specify that the security constraint applies to this SOAP servlet by adding the following url-pattern element inside the web-resources-collection element to the web.xml deployment descriptor of the Web application:

    <url-pattern>/sendMsg</url-pattern>

    Securing an RPC-Style Web Service
    You can restrict access to an RPC-style Web service by restricting access to the stateless session EJB that implements the Web service or the SOAP servlet.

    Listings 2 and 3 show how to set up the web.xml and weblogic.xml files to secure the SOAP servlets. Make sure that the WSDL file is still accessible by the clients. To ensure that, avoid using wild-card mapping; instead secure the SOAP servlet adapter path explicitly. The listings provide an example of how to secure the account manager proxy Web service. As you can see, the role is defined in web.xml and is associated to the group in the realm.

    Web Services Clients
    In order to understand how security for Web services clients is handled, it's necessary to understand how SOAP and HTTP authentication works.

    SOAP Authentication
    Web services use the SOAP protocol, a high-level messaging protocol implemented over some underlying transport mechanism. Web services security is still an emerging field and there are extensions emerging around the SOAP specification to support security features. Currently, SOAP uses the underlying transport protocol infrastructure for authentication. So WebLogic Server SOAP indirectly uses HTTP 1.1 authentication.

    HTTP Authentication
    The method for user authentication used with HTTP is quite simple. Since HTTP is a stateless protocol - that is, the server doesn't remember any information about a request once it has finished - the browser needs to resend the username and password on each request (see Figure 1).

    On the first access to an authenticated resource, the server will return a 401 status ("Unauthorized") and include a WWW-Authenticate response header, which will indicate the realm name and which authentication scheme to use. The browser should then ask the user to enter a username and password. It then requests the same resource again, this time including an authorization header that contains the scheme name ("Basic") and the username and password entered.

    The server checks the username and password, and if they are valid, returns the page. If the password is not valid for that user, or the user is not allowed access, the server returns a 401 status as before. The browser can then ask the user to retry the username and password.

    Assuming the username and password are valid, the user might next request a protected resource. In this case, the server would respond with a 401 status, and the browser could send the request again with the user and password details. This would be slow, however, so instead the browser sends the authorization header on subsequent requests. Refer to the W3C HTTP Working Group RFC 2617 (www.w3c.org/Protocols/Specs.html) for more details on HTTP authentication.

    Client Types
    Even though the previous section focused on browser clients, the protocol is the same for any type of client. Any client that needs to access secured Web services is expected to understand this HTTP authentication protocol and implement it in order to be authenticated. This section shows how authentication information can be passed from various types of clients.

    MS Visual Basic Clients
    Microsoft provides an HTTPConnector interface for the transport layer. It uses two properties, AuthUser and AuthPassword, to pass credentials. Listing 4 is an example of invoking a secured WebLogic Web service using Visual Basic and MS SOAP Toolkit 2.0.

    AuthUser and AuthPassword should not be confused with ProxyUser and ProxyPassword. They are used to provide the credentials for the proxy server, if there are any. This authentication works the same way, except that an error number 407 is returned instead of 401.

    Java Clients
    WebLogic Server provides Java client libraries to access secured resources. Usernames and credentials are passed using "java.naming.security.principal" and "java.naming.security.credentials". Listing 5 describes how a Java client would invoke a secured WebLogic Web service using WebServiceProxy.

    JAX-RPC Clients
    JAX-RPC (Java API for XML-based remote procedure calls) is a new standard released in June 2002 that defines APIs for invoking Web services. WebLogic Server 7.0 supports JAX-RPC. The JAX-RPC interfaces "Stub" and "Call" both support the properties "javax.xml.rpc.security.auth.username" and "javax.xml.rpc.security.auth.password" with which the authentication information may be passed. You can also use the static constants Stub.USERNAME_PROPERTY and Stub.PASSWORD_PROPERTY to set the security information before making a service call (see Listing 6). The username and password may also be passed while getting the port using get<web service>port().

    MS C++ Clients
    Similarly, you can write a C/C++ client using APIs provided by the vendor. The MS SOAP toolkit may be used to write C++ clients on a Windows platform. The username and password are passed using Connector Property. Following is an example that sets the username and password.

    Connector->Property["AuthUser"] = "<UserName>";
    Connector->Property["AuthPassword"] = "<Password>";

    Conclusion
    This article discussed authentication for WebLogic Web services and securing Web services components. As Web services are a natural choice for heterogeneous environments involving different technologies, it's necessary to understand how to access secured Web services using clients of various types.

  • More Stories By Anbarasu Krishnaswamy

    Anbarasu Krishnaswamy has over 15 years of IT industry experience, nine of which were with BEA. In his current role as the Enterprise Architect Lead, he leads the enterprise architecture and SOA practices for the central region professional services at BEA. As a SOA practitioner, he has helped several customers with SOA transformation and implementation. His experience also includes design and development of Java/J2EE applications, client/server computing, Web development, and enterprise application integration (EAI). Anbarasu holds a MBA from NIU and an MS in computer science and engineering.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    Never mind that we might not know what the future holds for cryptocurrencies and how much values will fluctuate or even how the process of mining a coin could cost as much as the value of the coin itself - cryptocurrency mining is a hot industry and shows no signs of slowing down. However, energy consumption to mine cryptocurrency is one of the biggest issues facing this industry. Burning huge amounts of electricity isn't incidental to cryptocurrency, it's basically embedded in the core of "mini...
    In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
    The term "digital transformation" (DX) is being used by everyone for just about any company initiative that involves technology, the web, ecommerce, software, or even customer experience. While the term has certainly turned into a buzzword with a lot of hype, the transition to a more connected, digital world is real and comes with real challenges. In his opening keynote, Four Essentials To Become DX Hero Status Now, Jonathan Hoppe, Co-Founder and CTO of Total Uptime Technologies, shared that ...
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    Every organization is facing their own Digital Transformation as they attempt to stay ahead of the competition, or worse, just keep up. Each new opportunity, whether embracing machine learning, IoT, or a cloud migration, seems to bring new development, deployment, and management models. The results are more diverse and federated computing models than any time in our history.
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several l...
    The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...