Managing and Monitoring Web Services in Project GlassFish

Print-friendly Version

[Part 1] [Part 2] [Part 3]

Enterprises can enable effective advertising of their Web services through registries on the Web. Registries hold Web services' metadata so that outside parties can search for and locate items of interest. Currently, Electronic Business With XML (ebXML) and Universal Description, Discovery, and Integration (UDDI) are the two major competing standards for registries.

The platform for managing Web services must provide visibility and control for developing those services. In the real world, you can develop Web services on various platforms to take advantage of the platforms' unique capabilities. However, governance in the form of a registry must track and control development activities across platforms. Other governance products also offer information on code and interface revisions for problem-solving and correlation of business events.

For information on ebXML and UDDI registries, see the two sections, Overview of UDDI and Overview of ebXML, in the article Registration and Discovery of Web Services Using JAXR with XML Registries. Also, note the four core elements in the UDDI information model, as described in the section Overview of UDDI.

For details on your registry, see its documentation.

To set up an ebXML registry for publishing Web services, do the following:

1. Download and install Tomcat 5.0.
   
   
2. Install Java Web Services Developer Pack (Java WSDP) and start the server.
   
   
3. Choose the default.
   
   You can then access the service-oriented architecture (SOA) registry at http://localhost:7080/soar/.

To deploy the ebXML resource adapter to Application Server, do the following:

1. In the Administration Console, click Application Server, followed by Applications and Connector Modules.
   
   
2. Click Deploy and navigate to the resource adapter, soar.rar file, in the file browser.
   
   Note: Sun Java System Application Server does not support this RAR. To learn more about the latter, see the Web Services Management Registry page for Project GlassFish.
   
   It may take a few minutes to upload the file. Afterwards, the Deploy Connector Module (Step 2 of 2) page is displayed.
   
   
3. Choose ebXML under Registry Type. Click Finish. See Figure 10.
   
   

Figure 10: Deployment of an ebXML Registry (Click image for larger view.)

 

To create a registry access point, do the following:

1. Specify the following information:
   
   
   • Java Naming and Directory Interface (JNDI) name — The name of the connector resource pool.
     
     
   • Type of registry — UDDI 3.0 or ebXML.
     
     
   • Publish URL and query URL — The Web addresses for publishing and querying the registry, respectively. The format is http://hostname.domain_name:portnumber/soar/registry/soap.
     
     
   • User name and password — The login credentials for the registry.
   
   
2. In the Administration Console, click Application Server, followed by Web Services and Registry. Click Add.
   
   

   Figure 11 is an example of the Add Registry page that's displayed.

   Figure 11: Example of Add Registry Page (Click image for larger view.)

    
   To list the registry access points you have configured, type:

   asadmin list-registry-locations
   

   Here is an example of the output:
   
   

   sample_ebXML Command list-registry-locations executed successfully.

From the Administration Console, you can specify registry access points and publish a Web service to a registry. Do the following:

1. Specify the following information:
   
   
   • Categories — Groups under which to list the Web service. Separate each category with a comma. The registry contains definitions of the categories.
     
     
   • Description — A synopsis of the Web service.
     
     
   • Name of organization — Your company's name, required only for UDDI.
     
     
   • Information on the load-balancer — The host name of the load-balancer, its port number, and the Secure Socket Layer (SSL) port number, as applicable. If you are publishing the Web service to an external registry, where the WSDL is available on the Internet, this information will replace the host name and port number specified in the WSDL.
   
   
2. In the Administration Console, click Application Server and then Web Services. Click the Publish tab and then the Publish button.
   
   Figure 12 shows an example of the Publish Web Service page that's displayed.
   
   

   Figure 12: Example of Publish Web Service Page (Click image for larger view.)

    
   

Alternatively, to publish a Web service on the CLI, type, for example:

asadmin publish-to-registry -registryjndinames sample_ebXML -webservicename server_HelloImpl#HelloImpl

From the Registry Administration page, you can search for a published Web service: Under Object Type, choose __Organization and click Search. See Figure 13.

Figure 13: Web-Service Search Page (Click image for larger view.)

Clicking ExternalLinks displays the external URI that points to the WSDL of the published Web service.

With the emergence of Service-Oriented Architecture (SOA) as a disruptive technology, security of Web Services must be addressed to adopt SOA in the mainstream production environment on a wide scale. Organization for the Advancement of Structured Information Standards (OASIS) Web Services Security (WSS), a standard for implementing message-level security in Web services, defines the core facilities for protecting the integrity and confidentiality of messages. That standard also affords the mechanisms for associating security-related claims with messages. For details, see the OASIS WSS Technical Committee site. Application Server supports the WS-I Basic Security Profile and the signing and encryption of SOAP messages.

This section discusses how you can secure Web services and audit requests and responses.

You can secure Web services through either transport-level security or message-level security.

With transport-level security, the connection between a client and Application Server is secured with SSL, whereby the client and server authenticate each other's identity and communicate with encrypted messages. If an intermediary is in use for invoking the Web service, you must secure all the connections with SSL.

Only the intended recipient can understand and decode the transmitted data. When a message reaches the final destination, the original sender information disappears. SSL cannot partially encrypt SOAP messages.

Message-level security involves protection with XML encryption and digital signatures. No limitations imposed by TLS apply. Messages are digitally signed and encrypted and, therefore, secured end to end. This level also supports partial encryption of SOAP messages. For details, see Chapter 10, "Configuring Message Security," in the Sun Java System Application Server Platform Edition 9 Administration Guide.

To enable message-level security, do the following:

1. On the Administration Console, click Application Server, followed by Configuration, Security, and Message Security. Select SOAP.
   
   The Edit Message Security Configuration page is displayed.
   
   
2. Choose ServerProvider under Default Provider and ClientProvider under Default Client Provider. By default, those two fields contain no values. See Figure 14.
   
   

   Figure 14: Edit Message Security Configuration Page (Click image for larger view.)

    
   
3. Stop Application Server. Type:
   

   $AS_HOME/bin/asadmin stop-domain
   

   The output reads:
   
   

   Domain domain1 stopped

    
   
4. Restart Application Server. Type:
   

   $AS_HOME/bin/asadmin start-domain
   

   The output reads:
   
   

   Starting Domain domain1, please wait. Log redirected to $AS_HOME/domains/domain1/logs/server.log. Domain domain1 is ready to receive client requests. Additional services are being started in the background.

    
   
5. Add the attribute default-client-provider="ClientProvider" to the message-security-config element in the file $AS_HOME/domains/domain1/config/sun-acc.xml, as follows:
   

   <message-security-config auth-layer=&quto;SOAP" default-clientprovider="ClientProvider">
   

6. Set up the environment variable VMARGS. Type:
   

   setenv VMARGS "-Djavax.net.ssl.keyStore=$AS_HOME/domains/domain1/config/keystore.jks
   -Djavax.net.ssl.trustStore=$AS_HOME/domains/domain1/config/cacerts.jks"
   

7. Repeat steps 4, 5, and 6 under Client Implementation.
   
   
8. Run the client. Type these two commands:
   

   cd $AS_HOME
   
   bin/appclient client.Client
   

   Message-layer security is now in force: You'll notice that the response takes a little longer to come through.

In Application Server, audit modules collect and store information on incoming requests (servlets, EJB components) and outgoing responses. The audit capability is off by default. When enabled, the default audit module trails requests and responses for the purpose of nonrepudiation.

Each audit module contains the following callbacks:

• init — Invoked at server startup and initialization of the audit module
  
  
• authentication — Invoked after an authentication request for a user in a given realm
  
  
• webInvocation — Invoked after a Web authorization request and unsecured requests for the Web service
  
  
• ejbInvocation — Invoked after an EJB authorization request and unsecured requests for the Web service
  
  
• webServiceInvocation — Invoked during the validation of a Web-service request for secured Web-service requests only
  
  
• ejbAsWebServiceInvocation — Invoked during the validation of an EJB request for secured Web-service requests only
  
  
• serverStarted — Invoked after Application Server has started
  
  
• serverShutdown — Invoked after Application Server has shut down

To turn on audit, from the Administration Console, click Configurations, followed by server-config, Security, and Audit Logging. Application Server then loads all the audit modules. To turn on the default audit module, you must set the property auditOn to true.

Alternatively, type these two commands:

asadmin set server-config.security-service.audit_enabled=true

asadmin set server-config.security-service.audit-module.default.property.auditOn=true

Afterwards, the default audit module logs the trail information to server.log at a log level of INFO. Each audit message, prepended with Audit:, contains the following information:

• User name
• Type of permission
• Name of the HTTP servlet request
• Confirmation of whether the request is successful

See this example:

[#|2005-11-02T09:25:45.074-0800|INFO|sun-appserver-ee9.0|
javax.enterprise.system.core.security|_ThreadID=14;_ThreadName=httpWorkerThread-4848-3;|Audit:
[Web] Authorization for user = (admin) and permission type = (hasResourcePermission)
for request com.sun.enterprise.web.connector.coyote.PwcCoyoteRequest@e03f50
returned =true|#]

To view the audit messages, from the Administration Console, click Advanced Search in the Log Viewer. Be sure to set the logger name as javax.enterprise.system.core.security. The output includes not only audit messages but also all the messages in the security logger.

To custom-build an audit module, extend the class com.sun.appserv.security.AuditModule. For example, do the following:

1. Specify a logger, such as this one:

   Logger logger = LogDomains.getLogger(LogDomains.SECURITY_LOGGER);
   

2. Adopt this sample implementation.
   
   
3. Compile with this command:
   

   javac -classpath $AS_HOME/lib/javaee.jar:$AS_HOME/lib/appservrt.jar -d $AS_HOME/lib SampleAuditModule.java
   

4. Update the suffix of the class path with the location of the audit module class file. Type:
   

   asadmin set server-config.java-config.classpath_suffix=:${AS_HOME}/lib
   

5. Create the audit module. Type:
   

   asadmin create-audit-module --classname
   com.sun.examples.security.auditmodule.SampleAuditModule --property
   LogFileName=sqeaudit.log:LogFilePath=\$\{com.sun.aas.instanceRoot\}/logs myAuditModule
   

6. Add the audit module to the configuration. Type:
   

   asadmin set server-config.security-service.audit_modules=default,myAuditModule
   

7. Restart Application Server.

Take a look at the log file ($AS_HOME/domain/domain1/logs/sqeaudit.log). Here is a sample:

SampleAuditModule::webInvocation(null,/com_sun_web_ui/js/browserVersion.js,hasUserDataPermission,true) invoked ...

Integrated with Sun Java System Access Manager, Application Server EE 9 will support Security Assertion Markup Language (SAML) 2.0 assertion, Liberty ID-WSF SOAP binding, single sign-on (SSO), as well as access control and identity federation, both based on open standards.

You've now learned how to manage Web services, mostly through JMX.

With its the intuitive UI and scriptable CLI, Application Server boasts a nifty, nimble, and straightforward interface for managing and monitoring Web services. Give Application Server a try!

Here is a wealth of reference material:

• Project Wiseman, an open-source implementation that focuses on management using Web Services on the Java Platform, Standard Edition. In addition, JSR 262: Web Services Connector for JMX Agents, currently in progress, aims at defining a way to remotely access JMX instrumentation with Web services.
  
  
• Project GlassFish
  
  
• Sun Java System Application Server
  • Main page
  • Developer home
  • Software Forum
  
  
• Standards, documentation, and articles
  • Web Services Management in Project GlassFish
  • J2EE Management Specification
  • Application Server Management Extensions (AMX) for Project GlassFish
  • Java EE Service Engine in Project GlassFish
  • Self-Management in Project GlassFish
  • AMX API documentation
  • Tutorial: Using XSLT
  • Chapter 10, "Configuring Message Security," in the Sun Java System Application Server Platform Edition 9 Administration Guide
  • Article: Registration and Discovery of Web Services Using JAXR with XML Registries
  • Article: Securing J2EE Applications in Sun Java Studio Enterprise 8
  • Article: Fast Infoset
  
  
• Java API for XML Web Services (JAX-WS)

[Part 1] [Part 2] [Part 3]