CA SiteMinder® Federation Standalone Guide › Logs to Monitor Federation Activities › Server Trace Logging › SSL Migration Tool Command Arguments › Create a SQL Server Data Sources on UNIX Systems

Create a SQL Server Data Sources on UNIX Systems

The CA SiteMinder® Federation Standalone ODBC data sources are configured using a system_odbc.ini file, which you create by renaming sqlserverwire.ini, located in federation_install_dir/siteminder/db, to system_odbc.ini. This system_odbc.ini file contains all of the names of the available ODBC data sources as well as the attributes that are associated with these data sources. This file must be customized to work for each site. Also, you can add additional data sources to this file, such as defining additional ODBC user directories for CA SiteMinder®.

The first section of the system_odbc.ini file, [ODBC Data Sources], contains a list of all of the currently available data sources. The name before the “=” refers to a subsequent section of the file describing each individual data source. After the “=” is a comment field.

Note: If you modify of the first line of data source entry, which is [CA SiteMinder® Data Source], take note of the change because you will need this value when configure your ODBC database as a policy store.

Each data source has a section in the system_odbc.ini file describing its attributes. The first attribute is the ODBC driver to be loaded when this data source is used by CA SiteMinder®. The remaining attributes are specific to the driver.

Adding a MS SQL Server Data source involves adding a new data source name in the [ODBC Data Sources] section of the file, and adding a section that describes the data source using the same name as the data source. You need to change the system_odbc.ini file if you create a new service name or want to use a different driver. You should have entries for the Oracle or SQL drivers under [CA SiteMinder® Data Source].

Again, to configure a MS SQL Server data source, you must first create a system_odbc.ini file in the federation_install_dir/siteminder/db directory. To do this, you need to rename sqlserverwire.ini, located in federation_install_dir/siteminder/db, to system_odbc.ini.

Create an Oracle Data Source on Windows

Create an ODBC data source for an Oracle database.

Follow these steps:

1. Do one of the following:
   • If you are using a supported 32–bit Windows operating system, click Start and select Programs, Administrative Tools, ODBC Data Sources.
   • If you are using a supported 64–bit Windows operating system:
     1. Navigate to the install_home\Windows\SysWOW64.
     2. Double–click odbcad32.exe

   The ODBC Data Source Administrator appears.

2. Click the System DSN tab, and then click Add.

   The Create New Data Source dialog appears

3. Select CA SiteMinder® Oracle Wire Protocol, and click Finish.

   The ODBC Oracle Wire Protocol Driver Setup dialog appears. The General tab is pulled to the front.

4. Enter a name that identifies the data source in the Data Source Name field.

   Note: Record this name. You will need the data source name when pointing the Policy Server to the database.

5. Enter the machine name where the Oracle database is installed in the Host Name field.
6. Enter the port number where the Oracle database is listening on the machine in the Port Number field.
7. Enter the name of the Oracle instance to which you want to connect in the SID field.

   Note: The service name is specified in the tnsnames.ora file. The SID is the system identifier for the database instance. The tnsnames.ora file contains service names and details that Oracle uses to identify and connect to Oracle instances.

   Example: if the tnsnames.ora file contains the following entry for an Oracle instance, you enter instance1 in the SID field:

   instance1 =
   

   (Description=
   (Address = (PROTOCOL = TCP)(Host = myhost)(Port=1521))
   (Connect_DATA_ = (SID = SIDofinstance1))
   )
   

8. Click Test Connection.

   The connection settings are tested and a prompt appears specifying that the connection is successful.

9. Click OK.

   The Oracle data source is configured for the wire protocol driver.

Create an Oracle Data Source on a UNIX System

The CA SiteMinder® ODBC data sources are configured using a system_odbc.ini file, which you create by renaming oraclewire.ini, located in federation_install_dir/siteminder/db, to system_odbc.ini. This system_odbc.ini file contains all of the names of the available ODBC data sources as well as the attributes that are associated with these data sources. This file must be customized to work for each site. Also, you can add additional data sources to this file, such as defining additional ODBC user directories for CA SiteMinder®.

The first section of the system_odbc.ini file, [ODBC Data Sources], contains a list of all of the currently available data sources. The name before the “=” refers to a subsequent section of the file describing each individual data source. After the “=” is a comment field.

Note: If you modify of the first line of data source entry, which is [CA SiteMinder® Data Source], take note of the change because you will need this value when configure your ODBC database as a policy store.

Each data source has a section in the system_odbc.ini file describing its attributes. The first attribute is the ODBC driver to be loaded when this data source is used by CA SiteMinder®. The remaining attributes are specific to the driver.

Adding an Oracle Data source involves adding a new data source name in the [ODBC Data Sources] section of the file, and adding a section that describes the data source using the same name as the data source. You need to change the system_odbc.ini file if you create a new service name or want to use a different driver. You should have entries for the SQL Server or Oracle drivers under [CA SiteMinder® Data Source].

Again, to configure an Oracle data source, you must first create a system_odbc.ini file in the federation_install_dir/siteminder/db directory. To do this, you need to rename oraclewire.ini, located in federation_install_dir/siteminder/db, to system_odbc.ini.

Transaction IDs to Aid Federation Troubleshooting

Troubleshooting a federated transaction is difficult when many transactions are logged in one file. To follow a single transaction in a trace log, use the SAML transaction ID. When a federation call occurs, the FWS application first generates a SAML Transaction ID. The SAML Transaction ID is generated only once. This unique SAML transaction ID can map to multiple transaction IDs

For example, you can see the following message in the fwstrace.log for a SAML 2.0 POST transaction. Note the line in bold that shows the mapping of the two transaction IDs.

[08/01/2013][17:33:54][2292][1884][1c2d7650-b006e46a-ed071f41-bbbede33-fe78e2dd-38d][SSO.java][processAuthentication][SAMLTransactionID 2aaf90ec-fdef4897-0ef49d91-63d4031d-f508a3e9-12 maps to TransactionID: 1c2d7650-b006e46a-ed071f41-bbbede33-fe78e2dd-38d.]

The CA SiteMinder® Federation Standalone system generates a new SAMLTransactionID only if it is acting as the asserting party. These specific activities are:

• When Federation Web Services redirects the browser to the authentication URL to establish a session.
• For the following HTTP-Artifact single sign-on transactions:
  • When the asserting party sends the artifact to the relying party.
  • When the asserting party resolves the artifact.
• When the user is redirected to the Identity Discovery profile URL.
• During single logout at the asserting party.

At the relying party, there exists a request ID, which can be traced easily through the log files. The request ID makes it unnecessary for the CA SiteMinder® Federation Standalone system to generate a SAMLTransactionID at the relying party.

For each unique SAML transaction ID, there can be multiple transaction IDs. When a new HTTP transaction occurs, a new transaction ID is generated. This transaction ID is mapped to the single SAML transaction ID. For example, in the trace log you can see the following entries:

SamlTransactionID ["xyz"] maps to TransationID["123"]
["123"] HTTP operation
["123"] HTTP operation

A new transaction ID "456" is generated:

SamlTransactionID["xyz"] Maps to Transactionid["456"]
["456"] <some operation>
["456"] <some operation>

Transaction IDs are placed in the fwstrace.log and the smtracedefault.log. The same set of transaction IDs for a single transaction is written to each of these logs. The trail of IDs in these logs enables you to follow a transaction. If there is a failure, the IDs help you determine which event failed for a transaction.

How To Follow a Single Transaction in a Log

To monitor a transaction, you can follow the two types of transaction IDs in the FWSTrace.log or smtracedefault.log. If there is a failure, looking at the IDs can help you determine the failure point.

To follow a transaction in a log, use one or more of the following methods:

• Open the trace file in a text editor and search on the string SAMLTransactionID (no spaces) or search for a sepcific SAMLTransactionID. This collection of entries in the log provides a view of the entire end-to-end transaction. You can see how far a transaction proceeded.
• Follow the transaction ID in the log file. The transaction ID represents HTTP transactions. Multiple transaction IDs can be associated with a single SAML Transaction ID. A failed transaction displays the transaction ID in the browser. To search the FWSTrace.log and smtracedefault log for the checkpoint error messages, use the displayed transaction ID.
• Parse the log files with a tool that searches files. On UNIX and Windows platforms, you can use a tool like the grep command. The grep command can stream through raw data, line by line, without your having to load a large text file into a text editor.

  Example:

  [usr@rhel632 etc]# more fwstrace.log| grep checkpoint
  [CHECKPOINT = SSOSAML2_SPCONFFROMPS_REQ]]
  [CHECKPOINT = SSOSAML2_SPCONFREAD_REQ]]
  [CHECKPOINT = SSOSAML2_SPCONFFROMCACHE_REQ]]
  [CHECKPOINT = SSOSAML2_SESSIONCOOKIEVALIDATE_REQ]]