Requires Free Membership to View
With today's tools, quite a bit of monitoring can be performed on Web services, all the way from the transport layer, to the backend application layer. Some of the metrics that can be logged include: inbound requests to the stack such as client IP, SSL parameters, authentication at the Web server level; SOAP security headers (UsernameToken, SAMLToken, etc.); SOAP request payload parameters; SOAP response payload; service latency and response time; policy and security failures (authentication failure; authorization failure, malformed XML, non-valid XML schema).
There are two main blind spots that I see on a regular basis. First is the matter of making sure that your policy enforcement points are actually enforcing the right policies. In other words, ensuring effective compliance with your policies. Next is the issue of what to do with all the information, and how useful is that information. For example, signed audit logs can be used in some cases for non-repudiation, but that is not an automatic assumption. Some legal framework needs to be established in advance of that functionality. Another case is problem of reconciling Web services level faults with higher level business processes. For example, can the service monitoring information you collect help you correlate with an online product ordering process break-down, and can it help you streamline that process?
This was first published in July 2006
Join the conversationComment
Share
Comments
Results
Contribute to the conversation