Presented by Secure Web Services Ernie Guerrera, President [email protected].

Presented by

SecureWeb Services

Ernie Guerrera, [email protected]

Copyright © 2005 NuWave Technologies, Inc. 2

Web Services Today

• Offer an effective architecture and technology for connecting back office applications with customers and trading partners

• Turn stove-piped and rigid systems into adaptive business solutions

• Extend the life and value of your existing NonStop

• Position your organization for a managed migration to other platforms

http://www.itug.org/


Why Use Web Services?• Multi-vendor/multi-platform support

provides migration paths• Replaces proprietary client/server

middleware• Customers and end-users can develop on

platforms of their choice• Utilize existing business logic to deliver new

functionality over the web• Extend critical data throughout the

enterprise in real-time



Benefits• Capitalize on NonStop environment as a

strategic platform for business critical applications

• Enable NonStop customers to leverage their enormous investments with:– New e-business initiatives– Enterprise Application Integration

• Satisfy corporate strategic objectives to achieve an Enterprise Service-Oriented Architecture (SOA) that includes NonStop

Web services is the first step to SOA



SOAP/AM Server Features

• Exposes your NSK-based server application as Web services

• Works with existing servers, no code changes required

• Does not require OSS• It’s secure (SSL/TLS included)• Integrated with TS/MP and TM/MP• Leverages native NSK inter-process message

system• Hides protocol, encoding and encryption

complexities



SOAP/AM Server Benefits

• Simple installation• Easy to use• Automatic WSDL generation• Self-documenting• Browser-based management• Works with many client toolkits (.NET,

Axis, et al)



Web Services vs Traditional Middleware

Web Services• Open standards• Platform-neutral• Vendor-neutral• SSL/TLS• Broad open source

support

CORBA, Tuxedo, RSC, etc.• Proprietary interfaces• Platform specific• Vendor specific• Custom security• Little or no open source

support



Concerns

The one concern we keep hearing from our customers is…

“How do I secure access to my NonStop?”

Let’s start by securing the architecture…


Intranet Web Services

Internet Web Services

Copyright © 2004 NuWave Technologies, Inc.


SOAP/AM Security Features

SOAP/AM Server provides four security features to control Web service transactions.

HTTP Authentication restricts access by requiring web client applications to provide a username and password.Secure Communications protects the data by encrypting the communications traffic between the client and server using the SSL3 or TLS1 protocol.



More SOAP/AM Security

Access Control helps secure services by limiting access to SOAP/AM Server to specific client IP addresses.User Impersonation helps secure services by allowing SOAP/AM Server to impersonate a Guardian user when sending request messages (IPMs) to servers.



HTTP Authentication

Basic Authentication is the simpler but less secure method. It merely requires that user's credentials be base-64 encoded. This encoding is easily reversible, so someone electronically eavesdropping on the TCP/IP session could discover the password. Therefore, it's recommended that Basic Authentication be used in conjunction with Secure Connections, which provides additional security by using strong encryption over the entire session.



HTTP Authentication

Using Digest Authentication, the user's credentials are more strongly encrypted using the MD5 algorithm. Consider using digest authentication if the Web service client library or tool kit supports it.



The authentication protocols that SOAP/AM Server will use are configured on the General Settings page of the Control Panel.

When the Server is installed, Digest authentication is disabled because not all web clients support this protocol. If all applications accessing the server support Digest authentication, enable Digest authentication and disable Basic authentication. Enabling both protocols is also an option because clients that support Digest authentication will always select this protocol when it is available. Disabling both protocols is not allowed.



In order to activate HTTP authentication of Web service requests, deny “Anonymous” access to the folder that contains the Service Definition File.

In this example, the Anonymous user has execute access to the /services/bankdemo folder which allows any user to access the BankDemo service without authentication.



In this example the permissions have been updated to allow execute permission to the Administrator only. Since the Anonymous user no longer has execute access to the folder, access to the service will require authentication. Only those clients that provide the username and password for the Administrator user will be granted access to the service.



Secure Connections

• SOAP/AM Server supports the SSL 3.0 and TLS 1.0 protocols to encrypt data transmission between the Server and the Web service client using HTTPS.

• The SOAP/AM Server Administrator can configure settings to require a Secure Connection in order to access a service. When configured in this way, if a client application attempts to access the service without using a Secure Connection, an HTTP error 403 will be returned to the client.



In order to use Secure Connections you must install a server certificate that has been properly signed by a Certificate Authority. Begin the certificate request process by selecting “Certificate Management” from the Server Management page of the Control Panel.



Select “Create a new certificate request”.



Enter the Distinguished Name information for your certificate. This information will uniquely identify your server. Note that the Common Name field must exactly match the host name portion of the URL that will be used to access your server.



SOAP/AM Server will create the Certificate Signing Request in base64 encoded format. The CSR may be copied from the screen or downloaded to a file for forwarding to the Certificate Authority.



Once the CSR has been signed by the Certificate Authority it must be installed on the Server. Select “Install a new certificate”.



Enter the file name of the signed CSR and click Install.



SOAP/AM Server will upload the signed certificate and install it in the Server. Once installed you may View, Renew, or Remove the certificate.



Secure Connections

Once the Server is restarted with the new configuration, it can be accessed using a Secure Connection by specifying the HTTPS protocol prefix.



To require a Secure Connection for a service, modify the properties for the folder that contains the Service Definition file. Navigate to the folder, select the Connection tab, and set the Connection Security options appropriately.



Access Control

• Access to SOAP/AM Server can be controlled by allowing or preventing access to server resources based on the client's IP address.

• Access control can be configured in one of two ways:

1. Allow all with exceptions 2. Deny all with exceptions



Allow All with Exceptions

By selecting Allow all with exceptions will allow access from all computers and can optionally deny access to specific computers or groups of computers specified in the exception list.



Deny All with Exceptions

By selecting Deny all with exceptions will deny access from all computers except those listed in the exception list. When configuring this option you must specify at least one address in the exception list and you cannot deny access from the computer you are currently using.



Access Control by IP Address

When a connection is made to the server, the client's IP address is compared to each entry in the exception list. The client IP address is logically ANDed with the subnet mask and compared to the associated IP address. If the IP address matches then the server determines if this address is allowed or denied. If the address is denied the server returns an HTTP 403 error to the client.Example:<IP Address> [ / <subnet mask> ]



Access Control Access Control settings are managed from the Access Control Management page of the Control Panel.



These settings allow access to all computers except those in networks 192.168.168 and 192.169. When a client connects, its address will be logically ANDed with each of the subnet masks. If the result matches the address associated with the mask, the client will be denied.



These settings deny access to all computers except those in network 192.168.168. When a client connects, its address will be logically ANDed with the subnet mask. If the result matches the address associated with the mask, the client will be allowed.



Guardian User Impersonation

When the SOAP/AM Server executes a Web service method on behalf of a client, it sends an interprocess message to a Pathway or Guardian application server. By default, it does this under the identity of the user that created the SOAP/AM Server process (sometimes known as the "CAID" or creator accessor id).

Since the SOAP/AM Server is a Guardian process, the identity under which a Web service is executed may be important if Safeguard or Pathway security settings restrict access to the server process that supports the Web service.



Guardian User Impersonation

Guardian User Impersonation is a feature that allows the SOAP/AM Server to internally switch its process accessor id, or “PAID”, to the user identity of a given Guardian user, prior to sending an interprocess message to the target server.

This feature allows the SOAP/AM Server to be started under any user identity but still enforce user-based access privileges to servers. Using the SOAP/AM Control Panel, you set the impersonated user identity on the VFS folder that contains the Service Definition File for the service. By setting an identity on the root folder, you can establish a default identity for all Web services.



Proper configuration of the SOAPAMP process can be verified on the Server Configuration Summary page.



Set User Impersonation defaults for all users by configuring Impersonation settings on the root folder of the VFS. In this example, SOAP/AM Server will change its process accessor id (PAID) to “nuwave.soapam” before sending the IPM to the target server.



A specific process accessor id can be configured for individual services by configuring the Impersonation settings on the folder that contains the Service Definition for the service. In this example, SOAP/AM Server will use the process accessor id “nuwave.bankdemo” when it sends IPMs to the BANKDEMO server.



SOAP/AM Web Service Client

• Access Web services on any platform from your NSK application

• Hides the complexity of TCP/IP, HTTP, XML, SOAP and SSL/TLS protocols


SOAP/AM Web Service Client


About NuWave Technologies

• Incorporated in 1999, but…• We’ve been in the Tandem consulting and

product development space since 1980• Our roots are in the Financial Services

industry, client/server, and messaging middleware products for the NSK

• We have technical specialists with knowledge of NSK fundamentals, .NET and Web services development environments



Some of Our Customers

• LogicaCMG• First Tennessee Bank• New Zealand Exchange• Federal Aviation Administration• Royal Bank of Canada• FiServ• West Telemarketing• McKesson



For more information…

1. Stop by our Booth (1218)2. Visit www.nuwave-tech.com3. Download a free trial4. Email [email protected]

Thank You!

htp://www.nuwave-tech.com/

mailto:[email protected]


Date post:	15-Jan-2016
Category:	Documents
View:	213 times
Download:	0 times

Presented by Secure Web Services Ernie Guerrera, President [email protected].

Documents