Saturday 25 February 2012

Creating Datasource



Procedure
1.     Open the administrative console.
2.     Click Resources > JDBC Providers.
3.     Choose the JDBC resource provider under which you want to create your data source. The detail page for this provider is displayed.
4.     Under Additional Properties, click the Data Sources link that is appropriate for your application. The Data sources or Data sources (Version 4) page is displayed.
5.     Click New to display the Data source settings page.
6.     Verify that all the required properties have valid values.
The following steps guide you through supplying the property values, a process that is basically the same for both data source types:
a.     Select a DataStoreHelper class name.
§  You can choose a DataStoreHelper class name from the list that is provided. The application server provides a class called DataStoreHelpers, or you can keep the default selection.
§  To use a data store helper other than what is provided, click Specify a user-defined DataStoreHelper. Type a fully qualified class name in the field that is provided.
b.    The next section of properties varies according to the database selection, provider type, and implementation that you chose for your JDBC provider. These properties are either required or highly recommended for your data source. Provide valid values for these settings if you do not want to accept the default values.
c.     Click Component-managed Authentication Alias if your database requires a user ID and password for a connection. This alias is used only when the application resource reference is using res-auth = Application.
Important:(For components with res-auth=Container) Both the Container-managed Authentication Alias and Mapping-Configuration Alias settings are deprecated. They are superseded by the specification of a login configuration on the resource-reference mapping at deployment time. You must now use this login setting to define the aliases at deployment.
d.    If you chose XA Data Source as the implementation type of your JDBC provider, you need to specify the alias used during transaction recovery processing. An additional section entitled Authentication Alias for XA Recovery is available. Select either Use Application Authentication Alias to use the same value that you chose for component-managed authentication, or select Specify: to choose a different alias from the drop-down list.
7.     Click Apply to view a page with your new data source settings. Additional properties and Related items sections are now available on this page. Additional properties contains the Connection pool, Custom properties, and WebSphere Application Server data source properties choices. (If you are using a Version 4 data source, however, you see only the Connection pool and Custom properties links.)
a.     Click on the first link to define settings that affect the behavior of the Java 2 Connector (J2C) connection pool manager.
b.    Use the WebSphere Application Server data source properties page to input settings that exclusively affect the application server's connection to the database.
c.     Go to the Custom properties page to view and modify additional properties that the database vendor might require or recommend for the connection of its product to an application server.
d.    The Related items section (applicable only to later version data sources, not Version 4 data sources) contains the J2C Authentication data entries choice. Here, you can specify a list of user IDs and passwords for J2C security to use.
8.     Click Save.
9.     Return to the data source page to confirm that your new data source is displayed in the list. 

Monday 13 February 2012

Configuring the IBM HTTP server Httpd.conf file

You must configure the IBM® HTTP server to use either the self-signed or CA-signed certificate you created.
  1. Make a backup of the httpd.conf file before
  2. Navigate to <IHS_root>\conf and, with a text editor, make a backup copy of the IBM HTTP server configuration file, named httpd.conf, then open it.
Add the following to the end of the httpd.conf file to implement one type of SSL implementation on the IBM HTTP server:
   Listen 80
   Listen 443
   FileETag none
   <VirtualHost HOST_MACHINE:443>
         ServerName HOST_MACHINE
         SSLEnable
  
         SSLV2Timeout 100
         SSLV3Timeout 1000
         SSLClientAuth none
   </VirtualHost>
   SSLDisable
    1. (IBM HTTP server 1.3.26) (Windows® only) Add the following line before Listen 80 above:
LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll
    1. (IBM HTTP server 2.0.42) Add the following line before Listen 443 above:
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
  1. (AIX® only) Search for "Dynamic Shared Object (DSO) Support" in httpd.conf, and then locate the list of files that have a SO extension. Enter the following line after LoadModule setenvif_module libexec/mod_setenvif.so:
   LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so
  1. (AIX only) Search for "AddModule mod_setenvif.c" in httpd.conf, then enter the following line of code after AddModule mod_setenvif.c:
   AddModule mod_ibm_ssl.c
  1. (AIX and Linux only) Add the following line after </VirtualHost> and before SSLDisable:
   SSLCacheDisable
  1. Navigate to SSLEnable and on the next two lines, enter the path to the key file and SSL stash file:
To configure to use a self-signed certificate on Windows, enter:
   Keyfile "c:\program files\ibmhttpserver\ssl\keys\ihscert.kdb"
   SSLStashfile "c:\program files\ibmhttpserver\ssl\keys\ihscert.sth"
To configure to use a CA-signed certificate on Windows, enter:
   Keyfile "c:\program files\ibmhttpserver\ssl\keys\casignedihscert.kdb"
   SSLStashfile "c:\program files\ibmhttpserver\ssl\keys\casignedihscert.sth"
To configure to use a self-signed certificate on AIX, enter:
   Keyfile "/data/IBMHttpServer/ssl/keys/ihscert.kdb"
   SSLStashfile "/data/IBMHttpServer/ssl/keys/ihscert.sth"
To configure to use a CA-signed certificate on AIX, enter:
   Keyfile "/data/IBMHttpServer/ssl/keys/casignedihscert.kdb"
   SSLStashfile "/data/IBMHttpServer/ssl/keys/casignedihscert.sth"
Note: Windows-based systems use backslashes (\) to delimit directories in a directory path. AIX-based systems and Web addresses use forward slashes (/) as delimiters.
  1. Replace all instances of HOST_MACHINE with the fully-qualified host name of the IBM HTTP server.
For example: intlcontact.sales.acme.com.
The resulting httpd.conf file should contain the following text at the end of the file for a system using the intlcontact.sales.acme.com HTTP server. The first example is for self-signed certificate on Windows for an IBM HTTP server 1.3.26; the second is for an IBM HTTP server 2.0.42.
   LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll
   Listen 80
   Listen 443
   FileETag none
   <VirtualHost intlcontact.sales.acme.com:443>
         ServerName intlcontact.sales.acme.com
     SSLEnable
     SSLClientAuth none
     Keyfile "c:\program files\ibmhttpserver\ssl\keys\ihscert.kdb"
       SSLStashfile "c:\program files\ibmhttpserver\ssl\keys\ihscert.sth"
       SSLV2Timeout 100
           SSLV3Timeout 1000
   </VirtualHost>
   SSLDisable
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so      
Listen 443
     <VirtualHost intlcontact.sales.acme.com:443>
         ServerName intlcontact.sales.acme.com
       SSLEnable
       SSLClientAuth none
       Keyfile "c:\program files\ibmhttpserver\ssl\keys\ihscert.kdb"
       SSLStashfile "c:\program files\ibmhttpserver\ssl\keys\ihscert.sth"
      ErrorLog "c:\program files\ibmhttpserver\logs\sslerror.log"
      TransferLog "c:\program files\ibmhttpserver\logs\sslaccess.log"
   </VirtualHost>
     SSLDisable
  1. Save and close the file.
  2. Stop and restart the IBM HTTP server.
Verify that SSL is working correctly with the IBM HTTP server by going to: https://hostname.domain.com.
Note: Users must use the fully-qualified host name when accessing the server using SSL. For example, use acme.com in the Web address, but not acme. To access the backend IBM Workplace Collaborative Learning Web application, users can enter https://hostname.domain.com/lms-lmm.


MORE about Above in troubleshooting:

Problem(Abstract)

The following information can be used as a guide for setting up the Secure Sockets Layer (SSL) within the IBM HTTP Server. This document covers information on setting up SSL virtualhosts, creating keyfiles, certificates along with how to protect access to directories and URLs to specific ciphers. Also, included is documentation on how to trace and record SSL traffic between a client browser and the Web server.

Resolving the problem

The following steps help guide you through the proper set up of SSL within the IBM HTTP Server:
  1. Confirm that the Global Security Kit (GSKit) is installed and meets the minimum requirements

  2. Create a key database file and certificates needed to authenticate the Web server during an SSL handshake

  3. Enable SSL directives within the IBM HTTP Server configuration file (httpd.conf)

  4. Other considerations when enabling SSL directives within the IBM HTTP Server configuration file (httpd.conf)

  5. Information that IBM WebSphere® Support needs to debug SSL configuration and certificate issues related to the IBM HTTP Server



  1. Confirm that the Global Security Kit is installed and meets the minimum requirements
    The Global Security Kit (GSKit) is a required component for the Secure Sockets Layer (SSL) enablement within the IBM HTTP Server. Therefore, it is important to confirm that a supported version of the Global Security Kit is installed prior to enabling SSL.

    For a complete listing of IBM HTTP Server releases and corresponding Global Security Kit versions, click IBM HTTP Server: Global Security Kit (GSKit) supported versions.

  2. Create a key database file and certificates needed to authenticate the Web server during an SSL handshake
    The iKeyman GUI, which is included within the IBM HTTP Server distribution, can be used to create a key database file (for example: key.kdb) needed to store personal server certificates required by the client browser during an SSL handshake.

    For quick information on how to create a key database file and personal server certificates, refer to the technote IKEYMAN, How do I...?

    More extensive information on using the iKeyman GUI to create key database files and certificates is located here:
  3. Enable SSL directives within the IBM HTTP Server's configuration file (httpd.conf)
    1. Verify that the SSL modules are uncommented
      • For Microsoft® Windows®:


        LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

      • For UNIX® platforms:


        LoadModule ibm_ssl_module modules/mod_ibm_ssl.so

    2. Create an SSL virtualhost stanza using the following examples and directives
      If you are enabling one Web site for SSL, and the hostname is the same as the one already defined in the Global Scope for non-SSL (port 80), you can enable SSL as follows. This virtualhost uses the default hostname defined by the ServerName directive in the Global Scope and the IP address associated with it.

      http://www.mycompany.com (non-SSL) 192.168.1.102 https://www.mycompany.com (SSL) 192.168.1.102

      Example 1:
      Listen 80
      ServerName
      www.mycompany.com

      <Directory "c:/Program Files/IBM HTTP Server/htdocs">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>

      DocumentRoot "c:/program files/ibm http server/htdocs"
      DirectoryIndex index.html

      Listen 443
      <VirtualHost  :443>
      SSLEnable
      SSLClientAuth None
      </VirtualHost>

      SSLDisable
      KeyFile "c:/program files/ibm http server/key.kdb"
      SSLV2Timeout 100
      SSLV3Timeout 1000

      If you are enabling one Web site for SSL and the ServerName is different than the ServerName already defined in the Global Scope for non-SSL (port 80), you can enable SSL as follows. Both hostnames must be registered in DNS to a separate IP address, and both IP addresses must be configured on local network interface cards.

      http://www.mycompany.com (non-SSL) 192.168.1.102 http://www.mycompany2.com (non-SSL) 192.168.1.103 https://www.mycompany2.com (SSL) 192.168.1.103

      Example 2:
      Listen 80
      ServerName
      www.mycompany.com

      <Directory "c:/Program Files/IBM HTTP Server/htdocs">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>

      DocumentRoot "c:/program files/ibm http server/htdocs"
      DirectoryIndex index.html

      <VirtualHost 192.168.1.103:80>
      ServerName
      www.mycompany2.com
      <Directory "c:/Program Files/IBM HTTP Server/htdocs2">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs2"
      DirectoryIndex index2.html
      </VirtualHost>

      Listen 443
      <VirtualHost 192.168.1.103:443>
      ServerName
      www.mycompany2.com
      SSLEnable
      SSLClientAuth None
      <Directory "c:/Program Files/IBM HTTP Server/htdocs2">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs2"
      DirectoryIndex index2.html
      </VirtualHost>

      SSLDisable
      KeyFile "c:/program files/ibm http server/key.kdb"
      SSLV2Timeout 100
      SSLV3Timeout 1000

      If you are enabling multiple Web sites for SSL, you can enable SSL as follows. All hostnames must be registered in DNS to a separate IP address. Also, all the IP addresses must be configured on a local network interface card. You must use the SSLServerCert directive to identify which personal server certificate in the key database file is passed to the client browser during the SSL handshake for each Web site. If the SSLServerCert directive is not defined, the IBM HTTP Server passes whatever certificate in the key database file is marked(*) as the "default key".

      For more information on why different IP addresses are required when enabling multiple Web sites for SSL: IP-Based Virtual Hosting must be used if configuring multiple SSL Virtual Host
      http://www.mycompany.com (non-SSL) 192.168.1.102 https://www.mycompany.com (non-SSL) 192.168.1.102 http://www.mycompany2.com (non-SSL) 192.168.1.103 https://www.mycompany2.com (SSL) 192.168.1.103 http://www.mycompany3.com (non-SSL) 192.168.1.104 https://www.mycompany3.com (SSL) 192.168.1.104

      Example 3:
      Listen 80
      ServerName
      www.mycompany.com

      <Directory "c:/Program Files/IBM HTTP Server/htdocs">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>

      DocumentRoot "c:/program files/ibm http server/htdocs"
      DirectoryIndex index.html

      <VirtualHost 192.168.1.103:80>
      ServerName
      www.mycompany2.com
      <Directory "c:/Program Files/IBM HTTP Server/htdocs2">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs2"
      DirectoryIndex index2.html
      </VirtualHost>

      <VirtualHost 192.168.1.104:80>
      ServerName
      www.mycompany3.com
      <Directory "c:/Program Files/IBM HTTP Server/htdocs3">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs3"
      DirectoryIndex index3.html
      </VirtualHost>

      Listen 443
      <VirtualHost 192.168.1.102:443>
      ServerName
      www.mycompany.com
      SSLEnable
      SSLClientAuth None
      SSLServerCert mycompany
      <Directory "c:/Program Files/IBM HTTP Server/htdocs">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs"
      DirectoryIndex index.html
      </VirtualHost>

      <VirtualHost 192.168.1.103:443>
      ServerName
      www.mycompany2.com
      SSLEnable
      SSLClientAuth None
      SSLServerCert mycompany2
      <Directory "c:/Program Files/IBM HTTP Server/htdocs2">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs2"
      DirectoryIndex index2.html
      </VirtualHost>

      <VirtualHost 192.168.1.104:443>
      ServerName
      www.mycompany3.com
      SSLEnable
      SSLClientAuth None
      SSLServerCert mycompany3
      <Directory "c:/Program Files/IBM HTTP Server/htdocs3">
      Options Indexes
      AllowOverride None
      order allow,deny
      allow from all
      </Directory>
      DocumentRoot "c:/program files/ibm http server/htdocs3"
      DirectoryIndex index3.html
      </VirtualHost>

      SSLDisable
      KeyFile "c:/program files/ibm http server/key.kdb"
      SSLV2Timeout 100
      SSLV3Timeout 1000

  4. Other considerations when enabling SSL directives within the IBM HTTP Server configuration file (httpd.conf).
  5. Information that IBM WebSphere Support needs to debug SSL configuration and certificate issues related to the IBM HTTP Server

    Brief description of the SSL directives discussed in this document

    Listen

    Tells the IBM HTTP Server what port to use for secure communication. The standard port is 443. This directive is set in the Global Scope.

    SSLEnable
    Enables this virtualhost for secure communication

    SSLClientAuth None
    Indicates that client authentication is disabled. This means that the client browser is not required to pass a client certificate during the handshake. Most sites do not require client authentication. To enable client authentication, use the SSLClientAuth Require directive.

    SSLDisable
    In the Global Scope; indicates SSL is disabled outside the virtualhost.

    KeyFile
    In the Global Scope; points to the key database file that contains the personal server certificates required by the browser during an SSL handshake. Refer to Step 2 in this technote.

    SSLV2Timeout
    Sets the timeout for SSL Version 2 session IDs

    SSLV3Timeout
    Sets the timeout for SSL Version 3 session IDs

    SSLServerCert
    Specifies the labelname of the certificate in the key database file that must be passed to the client browser during an SSL handshake. This is useful and required when you have multiple certificates stored in the key database file along with multiple SSL virtualhosts.

    SSLCipherSpec
    Used to limit which cipher the site allows during an SSL handshake. Browsers that do not provide the allowed cipher are denied access to the requested resource.

    SSLCipherRequire
    Most often used within a directory and/or location stanza to allow access to specific content, only if the corresponding cipher is used. Browsers that do not provide the allowed cipher are denied access to the requested resource. You can also use SSLCipherBan directives.

    For a complete list of available SSL directives:

Configuring SSL for IHS WebServer

The request flows in the following order: Web Browser –> IBM Http Server –> WebSphere Plug-in –> WebSphere Application Server.
This involves setting SSL for two different communications.
1. Between Browser and IBM http server [IHS]
2. Between IBM http server [IHS] and Websphere Application Server
In this part, let us take the, SSL setup for IHS. [between browser and IHS]. This involves, editing httpd.conf file and creating a new SSL certificate.
Creating new SSL digital Certificate using iKeyman:
For the certificate you can use either a certificate that is signed by a certificate authority or you can also use a self-signed certificate.  Before creating a new certificate, you need to create a certificate store or Key Database.
  • start the iKeyman utility: /IHS root/bin/ikeyman.sh
  • From the Menu Bar select Key Database File > New.
  • Choose the key database type as CMS
  • Enter a file name for the new Key Database file you are creating
  • Enter a Location for the location where you want to store the .kdb file
  • Click OK
  • After saving the key database file to the location specified, you are prompted to enter a password. This is the password that will be used to open the key database file in iKeyman in the future.
  • make sure checkbox Stash the password to a file is enabled. this saves the encrypted password file as a .sth file in the same directory as the key database file.
  • Now Click OK
Your Key Database file is Ready.
Now lets create a certificate request. Iam using this URL for my site
   www.bhikshuwebsphere.com(this site name is  differ based on your organization enveronment)
  • First, Open the KDB using ikeyman. This will show the key database contents.
  • Click on the "down arrow" to the right, to display a list of three choices.
Select Personal Certificate Requests and click New.
Now, a new window will pop up. here you need to input details about the certificate and your organization.
 
Options:
  • Key Size= 1024 for 128bit and 512 for 56bit
  • Common Name= SiteName, [This is the name that the CA will register]
  • Organization= Company Name
  • Enter the name of a file in which to store the certificate request = This is the file (.arm) that will contain your request
Once you save the file (.arm) you are done with creating the request
You must now choose a CA and send them a the "Certificate Request"
Once the CA has signed your certificate, generally they send you back the signed certificate through email.
  • Take the information provided in the CAs email and copy it to a text file (notepad) and save it as IHS_Root/SSL/CertRcvd.arm
  • Open the KDB file and choose Personal Certificates from the drop down options [ check image3 for how-to]
  • From the Personal Certificates section, click Receive, a pop-up window will come
Input the required data. Like  certificate name and location and click OK

Extracting public certificates for truststore files
Extracting a certificate from one keystore file and adding it to a truststore file is not the same as exporting the certificate and then importing it. Exporting a certificate copies all the certificate information, including its private key, and is normally only used if you want to copy a personal certificate into another keystore file as a personal certificate.
If a certificate is self-signed, extract the certificate and its public key from the keystore file and add it to the target truststore file.
If a certificate is CA-signed, verify that the CA certificate used to sign the certificate is listed as a signer certificate in the target truststore file. The keystore file must already exist and contain the certificate to be extracted.
Read the http://www.ibm.com/developerworks/java/jdk/security/iKeymanDocs.zip file for further information about how to extract a public certificate from a key database file.
Steps for this task
  1. Start the key management utility (iKeyman), if it is not already running.
  2. Open the keystore file from which the public certificate will be extracted.
  3. Select Personal Certificates.
  4. Click Extract Certificate.
  5. Click Base64-encoded ASCII data under Data type.
  6. Enter the Certificate File Name and Location.
  7. Click OK to export the public certificate into the specified file.
Result
A certificate file that contains the public key of the signed personal certificate is now available for the target truststore file.
What to do next
  1. Open the keystore file from which the public certificate will be extracted.
           Select signer Certificates and alick Add button
Enter the Certificate File Name and Location.
             Click OK
Now the signer certificate is added .


Open the httpd.conf file for editing and modify it to implement the follwoing:
  1. To allow IBM HTTP Server to support HTTPS, port 443, for example, enable SSL on IBM HTTP Server. Modify the configuration file of IBM HTTP Server, IHS_HOME/conf/httpd.conf. You also can enable SSL through the IBM HTTP Server administrative console. Open the IHS_HOME/conf/httpd.conffile and add the following lines to the bottom of the file:

    LoadModule ibm_ssl_module libexec/mod_ibm_ssl.so
    AddModule mod_ibm_ssl.c
    Listen 443
    <VirtualHost host_name.domain:443>
    ServerName host_name.domain
    SSLServerCert certificate name
    DocumentRoot "IHS_Root\docs"
    SSLEnable
    SSLClientAuth none
    <\VirtualHost>
    SSLDisable
    Keyfile "path_to_keyfile_created"
    SSLV2Timeout 100
    SSLV3Timeout 1000

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443
<VirtualHost XXXXXXX:443>
ServerName www.bhikshuwebsphere.com
DocumentRoot <install_root>\htdocs
SSLEnable
#SSLClientAuth required
</VirtualHost>
SSLDisable
Keyfile <IHS_HOME>/serverkey.kdb
Note: Change the host name and the path for the key file accordingly. Modify the Web server to support client certificates by uncommenting the SSLClientAuth directive shown in the httpd.conf file.

  • For the host_name.domain, use the virtual host IP address or fully qualified domain name.
  • Typically, port 443 is used for HTTPS protocol.
  • The timeout values are given in seconds. Your values might be different.
Note: Change the host name and the path for the key file accordingly. Modify the Web server to support client certificates by uncommenting the SSLClientAuth directive shown in the httpd.conf file.
SSLClientAuth required
  1. Restart IBM HTTP Server.
  2. Test SSL between a browser and IBM HTTP Server. For more information on the default IBM HTTP Server port number, see Port number settings in WebSphere Application Server versions.
  3. Follow the prompts to select a personal certificate if the SSLClientAuth directive is set to required.
  4. To enable the application server to communicate with IBM HTTP Server using port 443, add the host alias on the default_host. In the administrative console, click Environment > Virtual Hosts > default_host. Under Additional properties, click Host Aliases > New. Enter the following information in the appropriate fields:
Host name
*
Port
443
  1. Click Apply and Save When you click Save, the information is written to the security.xml file and the Web server plug-in is automatically updated.
  2. Restart WebSphere Application Server.
  3. Test your connection.