Posts Tagged ‘CA SiteMinder’

« Older Entries

Configuring OpenLDAP as a SiteMinder Policy Store

Thursday, October 13th, 2011

Overview
SiteMinder supports OpenLDAP for use as a Policy Store. OpenLDAP provides a freely available, replicated directory that can be used as a redundant store for SiteMinder’s configuration information. Unfortunately, the SiteMinder documentation covering how to configure OpenLDAP is at best incomplete and at worst incorrect. This article breaks down the steps required to enable OpenLDAP to be a Policy Store and configure the Policy Server to leverage the directory. Keep in mind that SiteMinder currently only supports OpenLDAP 2.3.x. This means that only Master/Slave replication is supported. While this is sufficient to ensure the availability of the Policy Store, if the Master directory is down, no policy or key updates can be performed. This article also assumes that the Key Store is set to the default setting of using the Policy Store as the location to store key information. Switch the directory paths outlined below to use backslashes if these steps are being performed on Windows.

1. Download and Install OpenLDAP
This article does not cover the specific details on how to build and install OpenLDAP. The details for this can be found on the OpenLDAP site. A quick start guide is located there as well.

2. Download the OpenLDAP Schema Files for SiteMinder
OpenLDAP is considered a “Tier 2″ directory for SiteMinder. As such, the ability to configure the directory as a Policy Store is not automated. In order to obtain the needed schema files for the Policy Store, the “CA SiteMinder Tier 2 Directories- ESD Only” package must be downloaded. To download this file (current as of 10/12/2011):

  1. Log in to the Technical Support Site
  2. Click “Download Center” in the lefthand navigation
  3. Type siteminder into the “Select a Product” field
  4. Select the listed SiteMinder product
  5. Select 12.0 in the “Select a Release” drop-down
  6. Select SP3 in the “Select a Gen level” drop-down
  7. Click the [GO] button
  8. Scroll down to the bottom of the list of returned downloads
  9. Download and unzip the “CA SiteMinder Tier 2 Directories- ESD Only” download to the Policy Server

3. Configure OpenLDAP To Support the SiteMinder Policy Store
The OpenLDAP server requires manual configuration to support its use as a SiteMinder Policy Store. The following steps are required:

3a. Copy the Policy Store schema files into the OpenLDAP schema directory
3b. Include the SiteMinder Policy Store schema files in the OpenLDAP configuration
3c. Ensure that SiteMinder can detect it is an OpenLDAP Policy Store
3d. Create the base Policy Store structure
3e. Restart OpenLDAP

Note that these instructions assume that the install location for OpenLDAP is under the /usr/local path and the default directories are used. For this example, the root of the directory is “dc=company,dc=com” for the location of the Policy Store. These steps will need to be modified if a different path or directory structure is used.

3a. Copy the Policy Store schema files into the OpenLDAP schema directory
The OpenLDAP schema needs to be extended to support the SiteMinder Policy Store objects. This is done by copying the schema files to the server and adding them into the slapd.conf configuration file. To copy the schema files:

  1. If not already done, unzip the Tier 2 directory support zip file to a known location (I used “/home/installers” for these steps)
  2. Copy the following files to the “/usr/local/etc/openldap/schema” directory by running the following commands:
cp /home/installers/Tier2DirSupport/openldap/openldap_attribute.schema /usr/local/etc/openldap/schema
cp /home/installers/Tier2DirSupport/openldap/openldap_object.schema /usr/local/etc/openldap/schema
cp /home/installers/Tier2DirSupport/xps/openldap/openldap_attribute_XPS.schema /usr/local/etc/openldap/schema
cp /home/installers/Tier2DirSupport/xps/openldap/openldap_object_XPS.schema /usr/local/etc/openldap/schema

The schema files now need to be added into the OpenLDAP configuration.

3b. Include the SiteMinder Policy Store schema files in the OpenLDAP configuration
Once the Policy Store schema files are copied into the correct location, they need to be added to the OpenLDAP configuration. This is done by adding them to the slapd.conf file. In this example, the slapd.conf file is located in the “/usr/local/etc/openldap” directory. To include the files:

  1. Edit the slapd.conf file with your favorite editor (e.g. vi slapd.conf)
  2. Add the following lines to the file under the “include /usr/local/etc/openldap/schema/core.schema” line and then save the configuration (note that other changes to this file will be made in later steps):
include         /usr/local/etc/openldap/schema/openldap_attribute.schema
include         /usr/local/etc/openldap/schema/openldap_object.schema
include         /usr/local/etc/openldap/schema/openldap_attribute_XPS.schema
include         /usr/local/etc/openldap/schema/openldap_object_XPS.schema

OpenLDAP can now reference the appropriate schema files for the Policy Store objects.

3c. Ensure that SiteMinder can detect it is an OpenLDAP Policy Store
Since OpenLDAP does not support server-side sorting SiteMinder must instead handle sorting on the client side. To accomplish this, all XPS objects are retrieved at start-up using server-side paging.

To support client-side sorting, OpenLDAP must be configure with the following settings in the slapd.conf file:

  • Allow SiteMinder to read the Root DSE so that it can determine the directory is of type OpenLDAP
  • Set the maximum number of entries returned in a search operation to at least 500 so that the XPS objects are retrieved in increments of 500 or more objects
  • Allow v2 LDAP binds so that the SiteMinder Admin Console (smconsole) to test the LDAP connection to the Policy Store

To allow SiteMinder to read the Root DSE, uncomment the following 2 lines in the slapd.conf file:

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read

By default the sizelimit setting for OpenLDAP is 500. Ensure that this is the minimum value in the slapd.conf file. If the value is less than 500, increase it to 500 by adding the following line above the “BDB database definitions” section in the slapd.conf file:

sizelimit 500

To allow v2 binds, add the following line above the “BDB database definitions” section in the slapd.conf file:

allow bind_v2

SiteMinder should now be able to correctly identify the Policy Store as an OpenLDAP server and validate that it can connect to the server.

3d. Create the base Policy Store structure
In order to import the Policy Store base objects, the proper directory structure must be in place prior to running the administration tools. This is done by creating an LDIF file with the correct DIT structure and importing it into the OpenLDAP server.

An LDIF file is a text file which represents the objects in an LDAP directory. In my example where my base DN is “dc=company,dc=com” I created the following LDIF file and saved it in the /home/installers directory. This LDIF file creates the base structure for SiteMinder to store its policy objects and also the Manager account which SiteMinder will use to bind (authenticate) to the directory:

# company.com
dn: dc=company,dc=com
objectclass: dcObject
objectclass: organization
o: Example Company
dc: company

# Manager, company.com
dn: cn=Manager,dc=company,dc=com
objectclass: organizationalRole
cn: Manager

# Netegrity, company.com
dn: ou=Netegrity,dc=company,dc=com
ou: Netegrity
objectClass: organizationalUnit
objectClass: top

# SiteMinder, Netegrity, company.com
dn: ou=SiteMinder,ou=Netegrity,dc=company,dc=com
ou: SiteMinder
objectClass: organizationalUnit
objectClass: top

# PolicySvr4, SiteMinder, Netegrity, company.com
dn: ou=PolicySvr4,ou=SiteMinder,ou=Netegrity,dc=company,dc=com
ou: PolicySvr4
objectClass: organizationalUnit
objectClass: top

# XPS, policysvr4, siteminder, netegrity, company.com
dn: ou=XPS,ou=policysvr4,ou=siteminder,ou=netegrity,dc=company,dc=com
ou: XPS
objectClass: organizationalUnit
objectClass: top

Once this file is created, you can import it using the following command (I called the file base.ldif):

/usr/local/bin/ldapadd -x -D “cn=Manager,dc=company,dc=com” -W -f /home/installers/base.ldif

3e. Restart OpenLDAP
To pick up the slapd.conf file changes, the OpenLDAP server must be restarted. Use the following command to stop OpenLDAP:

kill -INT `cat /usr/local/var/run/slapd.pid`

Use the following command to start OpenLDAP:

/usr/local/libexec/slapd

The OpenLDAP server should now be set to go for the next set of steps to load SiteMinder base policy objects.

4. Configure SiteMinder to Use OpenLDAP as the Policy Store
Once OpenLDAP is set up with the proper schema and other settings from section 3, the next step is to point SiteMinder at the OpenLDAP directory and create the base objects used by the policy server. The following steps are required:

4a. Point SiteMinder at the OpenLDAP instance
4b. Load the base objects into the Policy Store

These instructions assume that you have already installed the Policy Server binaries. For details on how to do this follow the instructions in the SiteMinder documentation. You do not need to configure the Policy Store during the installation of the Policy Server (that’s what we are doing here).

4a. Point SiteMinder at the OpenLDAP instance
You can point the Policy Server at the OpenLDAP directory either in the Policy Server Management Console (smconsole) or through the command line. The following section contains the command line based steps:

1. Run the following command to validate that the Policy Server can communicate with the OpenLDAP directory:

smldapsetup status -hhost -pport -dAdminDN -wAdminPW -rroot -ssl1/0 -ccert

Where:

-hhost Specifies the IP Address of the LDAP server host system.-pport Specifies the port on which the LDAP server is listening
-dAdminDN Specifies the name of an LDAP user with privileges to create LDAP schema in the LDAP directory server
-wAdminPW Specifies the password for an LDAP user with privileges to create LDAP schema in the LDAP directory server
-rroot Specifies the DN location of the SiteMinder data in the LDAP directory
-ssl1|0 Specifies an SSL connection. Limits: 0=no | 1=yes Default: 0
-ccert (Only required if the ssl value is 1) Specifies the path to the directory where the SSL client certificate database file, cert7.db, exists

Since I have OpenLDAP installed locally, the following command was used:

smldapsetup status -h127.0.0.1 -p389 -d"cn=Manager,dc=company,dc=com" -wpassword -r"dc=company,dc=com" -ssl0

2. Run the following command to configure the Policy Server to use the OpenLDAP Policy Store:

smldapsetup reg -hhost -pport -dAdminDN -wAdminPW -rroot -ssl1/0 -ccert

Where:

-hhost Specifies the IP Address of the LDAP server host system.-pport Specifies the port on which the LDAP server is listening
-dAdminDN Specifies the name of an LDAP user with privileges to create LDAP schema in the LDAP directory server
-wAdminPW Specifies the password for an LDAP user with privileges to create LDAP schema in the LDAP directory server
-rroot Specifies the DN location of the SiteMinder data in the LDAP directory
-ssl1|0 Specifies an SSL connection. Limits: 0=no | 1=yes Default: 0
-ccert (Only required if the ssl value is 1) Specifies the path to the directory where the SSL client certificate database file, cert7.db, exists

So, for this install the following command was used:

smldapsetup reg -h127.0.0.1 -p389 -d"cn=Manager,dc=company,dc=com" -wpassw0rd -r"dc=company,dc=com" -ssl0

4b. Load the base objects into the Policy Store
The next step is to load the base objects into the Policy Store. To load the Policy Store objects the following steps are required:

  • Register the SiteMinder admin user
  • Load the base policy objects
  • Load the base federation objects
  • Import the XPS data definitions

To register the SiteMinder admin account, smreg is required. You may need to copy smreg from the SiteMinder Policy Server installation media to the <Policy Server Home>/bin directory where <Policy Server Home> is the installation path for the Policy Server.

1. Run the following command in the terminal to register the SiteMinder administrator account (switch to the <Policy Server Home>/bin directory is necessary):

smreg -su adminPW

Where:

adminPW is the administrator password for the “SiteMinder” account

2. Run the following command to import the base policy store objects:

smobjimport -i<Policy Server Home>/db/smdif/smpolicy.smdif -dsiteminder_super_user_name -wsiteminder_super_user_password -f -v -c

Where:

<Policy Server Home> is the installation path for the Policy Server
-i<Policy Server Home>/db/smdif/smpolicy.smdif Specifies the path and name of the import file
-dsiteminder_super_user_name Specifies the name of the SiteMinder administrator account
-wsiteminder_super_user_password Specifies the password for the SiteMinder administrator account
-f Overrides duplicate objects
-v Turns on tracing and outputs error, warning, and comment messages in verbose format so that you can monitor the status of the import
-c Indicates that the smdif input file contains unencrypted data

So, for this install the following command was used:

smobjimport -i/home/smuser/CA/siteminder/db/smdif/smpolicy.smdif -dsiteminder -wpassword -f -v -c

3. Run the following command to import the base federation objects:

smobjimport -i<Policy Server Home>/db/smdif/ampolicy.smdif -dsiteminder_super_user_name -wsiteminder_super_user_password -f -v -c

Where:

<Policy Server Home> is the installation path for the Policy Server
-i<Policy Server Home>/db/smdif/smpolicy.smdif Specifies the path and name of the import file
-dsiteminder_super_user_name Specifies the name of the SiteMinder administrator account
-wsiteminder_super_user_password Specifies the password for the SiteMinder administrator account
-f Overrides duplicate objects
-v Turns on tracing and outputs error, warning, and comment messages in verbose format so that you can monitor the status of the import
-c Indicates that the smdif input file contains unencrypted data

So, for this install the following command was used:

smobjimport -i/home/smuser/CA/siteminder/db/smdif/ampolicy.smdif -dsiteminder -wpassword -f -v -c

4. Importing the policy store data definitions is required to use the policy store with the Administrative UI. The base definitions describe the policy store data. Run the following commands to import the XPS data definitions (note that these commands must be run in the order below or the imports fail):

  1. Switch to the <Policy Server Home>/xps/dd directory where <Policy Server Home> is the installation path for the Policy Server
  2. Run the following command: XPSDDInstall SmObjects.xdd
  3. Run the following command: XPSDDInstall EPMObjects.xdd
  4. Run the following command: XPSDDInstall SecCat.xdd
  5. Run the following command: XPSDDInstall FssSmObjects.xdd

The Policy Server is now fully configured to use OpenLDAP for the Policy Store.

5. Prepare the Policy Store for registration of the Administrative UI
The default SiteMinder super user account (siteminder) is used to log into the Administrative UI for the first time in order to register the Administrative UI. This creates a trusted relationship between both components. The XPSRegClient utility is used to supply the super user account name and password. The Policy Server uses these credentials to verify that the registration request is valid and that the trusted relationship can be established. Keep in mind that the time from which you supply the credentials to when the initial Administrative UI login occurs is limited to 24 hours. If you do not plan on installing the Administrative UI within one day, complete the following before installing the Administrative UI.

Run the following command to prepare the Policy Server for the Administrative UI registration:

XPSRegClient siteminder[:passphrase] -adminui-setup -t timeout -r retries -c comment -cp -l log_path -e error_path -vT -vI -vW -vE -vF

Where:

passphrase Specifies the password for the default SiteMinder super user account (if you do not specify the passphrase, XPSRegClient prompts you to enter and confirm one).
-adminui–setup Specifies that the Administrative UI is being registered with a Policy Server for the first–time.
-t timeout (Optional) Specifies the allotted time from when you to install the Administrative UI to the time you log in and create a trusted relationship with a Policy Server. The Policy Server denies the registration request when the timeout value is exceeded.

Unit of measurement: minutes
Default: 240 (4 hours)
Minimum Limit: 1
Maximum Limit: 1440 (24 hours)

-r retries (Optional) Specifies how many failed attempts are allowed when you are registering the Administrative UI. A failed attempt can result from submitting incorrect SiteMinder administrator credentials when logging into the Administrative UI for the first–time

Default: 1
Maximum Limit: 5

-c comment (Optional) Inserts the specified comments into the registration log file for informational purposes. Surround the comments with quotes.
-cp (Optional) Specifies that registration log file can contain multiple lines of comments. The utility prompts for multiple lines of comments and inserts the specified comments into the registration log file for informational purposes. Surround the comments with quotes.
-l log path (Optional) Specifies where the registration log file must be exported.

Default: <Policy Server Home>/log where <Policy Server Home> is the installation path for the Policy Server.

-e error_path (Optional) Sends exceptions to the specified path.

Default: stderr

-vT (Optional) Sets the verbosity level to TRACE.
-vI (Optional) Sets the verbosity level to INFO.
-vW (Optional) Sets the verbosity level to WARNING.
-vE (Optional) Sets the verbosity level to ERROR.
-vF (Optional) Sets the verbosity level to FATAL.

XPSRegClient supplies the Policy Server with the administrator credentials the Policy Server uses to verify the registration request when you log into the Administrative UI for the first–time.

 

Tags: , , , , , ,
Posted in Identity and Access Management | No Comments »

Setting the Windows Security Context with SiteMinder

Thursday, September 8th, 2011

Note: Portions of this post come from details in the SiteMinder Policy Server Configuration and User Context Gateway Guides Copyright © by CA Technologies.

Overview:
In a Windows network, a security context defines a user’s identity and authentication information. Web applications such as Microsoft Exchange Server or SQL Server need a user’s security context to provide native security in the form of Microsoft’s access control lists (ACLs) or other access control tools. The SiteMinder Web Agent can provide a Windows user security context for accessing Web resources on IIS Web servers. By establishing a user’s security context, the server can use this identity to enforce access control mechanisms. This approach can be used to supply the security context to applications that call native .NET (or other) methods to get the user and associate security information.

There are several requirements to use SiteMinder’s native mechanism to establish the security context in IIS:

  • Active Directory must be used as the user store with the “Use authenticated user’s security context” option checked.
  • The SiteMinder Session Server must be configured and enabled on all the Policy Servers. The Session Server requires a relational database (e.g. MS SQL) in which to store session information.
  • The realm protecting the applications requiring the user’s security context must have Persistent Session enabled.

The session server stores a user’s encrypted credentials and associates the user with a session ID. When a SiteMinder session is established between a client and a Web Agent, the Windows user account is established and linked to the session.

Considerations:
There are several considerations to keep in mind when using SiteMinder to establish the Windows Security Context. These items may impact the ability to leverage SiteMinder functionality for this purpose.

The following items should be considered:

  • The user must initially authenticate to a realm with Persistent Session enabled. This is required to establish the initial session for the user in the session server and to capture the user’s credentials. In an environment where a user can authenticate to multiple realms, each of those realms must have Persistent Session enabled. A user may be re-challenged when entering a realm with Persistent Session enabled if the initial authentication was to a non-persistent realm. However, it looks like SiteMinder is instead throwing an error in that scenario.
  • The user must authenticate to Active Directory for the necessary information to be captured in the session store. When domains have a combination of multiple user directories of different types listed, the Active Directory user directory may need to be listed first to ensure that a user’s credentials do not match another directory prior to being authenticated to Active Directory. If that occurs SiteMinder will not be able to establish the user’s security context.
  • Persistent Sessions introduce performance implications since the session must be validated against the session server. This can be minimized by setting the validation period on the session to a high value to reduce the number of times the session is checked. The validation period should be set less than the idle timeout value. Once a persistent session is established for a user, the users session is always validated against the session server regardless of if the realm being accessed has persistent session enabled. Using security zones for the Web Agents protecting applications requiring persistent sessions constrains the session validation to that zone only. This eliminates the need for other agents to validate the session with the session server.
  • Environments with global implementations require either the session database to be replicated in real-time to each data center or for the Policy Servers to point back to a common session store across the network. If the Policy Server does not have the session server enabled or is pointed to a database that does not contain the user’s session, the user will be re-prompted for authentication. Pointing at a database across the network to a common session store eliminates that issue, but due to the latency and frequency of the calls to the session server this is not recommended.
  • Only authentication schemes that leverage an ID and password can be used with SiteMinder’s capability to establish the Windows Security Context. The following authentication schemes are supported:
    • Basic Authentication Schemes
    • Basic Over SSL Authentication Schemes
    • HTML Forms Authentication Schemes
    • X.509 Client Certificate and Basic Authentication Schemes
    • X.509 Client Certificate and HTML Forms Authentication Schemes

Other Options:
Since third-party Web Access Management (WAM) systems are fairly prevalent, modern applications should support the capability to integrate with this type of system. This is usually done by trusting a header or token created by WAM system that contains the user’s identity. For SiteMinder the application should read the SM_USER header or allow the option to specify a header that contains the user’s identity. SiteMinder can then set the appropriate header using a response that ties the header to the specific identity attribute in the underlying user store.

In cases where that is not possible and the SiteMinder native capabilities to establish the security context do not meet the specified requirements, CA has a solution module called the “User Context Gateway” that can establish the security context for the user. The User Context Gateway (UCG) is used for three purposes:

  • Establishing a Windows Security Context under IIS.
  • Capturing a user’s sign-on password for later use.
  • Maintaining and verifying a Windows password independent of the user’s sign-in (also known as “directory”) password.

UCG differs from SiteMinder native security in the following ways:

  • All user directories that are writable to SiteMinder can be used by UCG. SiteMinder natively requires Active Directory as the user store.
  • The session server is not required for UCG.
  • All authentication schemes are supported by UCG. SiteMinder natively requires authentication schemes that leverage an ID and password.
  • The user’s credentials are stored persistently in the user directory instead of being stored in the session store.
  • While not recommended a user’s credentials can be made available to third-party applications. SiteMinder natively can only supply the user’s password to the first resource requested after authentication.

Since the User Context Gateway is a solutions module, there may be additional costs for this solution. Compatibility with the deployed version of SiteMinder should also be validated.

Configuring SiteMinder to Establish the Windows Security Context:

The following steps outline what is required to configure SiteMinder to establish the Windows Security Context for the user:

  1. Create the session server database and run the relevant SQL scripts to create the tables, etc.
  2. Define the ODBC data source for the session database.
  3. Configure the session database on the Data tab of the Policy Server Management Console and enable the session server.
  4. Enable the user directory containing the Windows users to run the security context by checking the “Use Authenticated User’s Security Context” check box on the Directory Setup group box on the User Directory pane.
  5. Associate one of the authentication schemes defined in the Considerations section with each realm where a user can authentication in the resource group box of the Realm pane.
  6. Enable persistent sessions for each realm and set a high Validation Enabled period with each realm where a user authenticates or the Windows Security Context is required in the session group box of the Realm pane.

Refer to the relevant SiteMinder documentation for details on how to perform these steps.


Tags: , , , , ,
Posted in Identity and Access Management | 4 Comments »

Working Around SiteMinder 500 Errors for Unauthorized Federation Service Provider Access

Wednesday, September 7th, 2011

Overview:
SiteMinder provides federation capabilities for SAML (and other protocols). SiteMinder’s federation capabilities are accessed through a set of web services installed with the Web Agent Option Pack. The federation web service throws a 500 error instead of automatically redirecting the user for re-authentication like a standard SiteMinder Web Agent when the user has a valid SiteMinder session, but is not authorized to access the configured SAML Service Provider. This can be worked around in a couple of ways, but one way to handle this is to leverage the federation 500 error redirect to automatically redirect the user to a page which logs the user out and then redirects back to the federation URL.

The following is required for this configuration:

  1. Custom redirect page that takes the federation POST variables and redirects the user back to the sent SPID. This page should be placed on a web server with an installed SiteMinder Web Agent.
  2. Configure the redirect page as the logoff URI within the agent’s configuration object (ACO).
  3. Set the custom error page as the Server Error URL in the Additional URL Configuration section on the Advanced tab of the SAML service provider configuration dialog.

Custom Redirect Page:
The custom redirect page can be an ASP, ASP.NET, JSP or any other dynamic page that can take POST parameters, parse them and redirect the user back to a URL. The following ASP code is an example of a page that takes the information from SiteMinder and redirects the user back to the federation URL:

<%
Dim relaystate, spid, fedurl, redirecturl
relaystate=Request.Form("RelayState")
spid=Request.Form("SPID")
fedurl="https://saml.company.com/affwebservices/public/saml2sso"

if relaystate = "" Then
 redirecturl=fedurl+"?SPID="+spid
Else
 redirecturl=fedurl+"?SPID="+spid+"&RelayState="+Server.URLEncode(relaystate)
End If
%>

<html>
<head>
<title>Redirect Page</title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</head>
<body>
<% Response.Redirect(redirecturl) %>
</body>
</html>

To use this code, set the fedurl variable to the base federation URL for the environment. The page should then be dropped on a server with a SiteMinder Web Agent in an unprotected folder. For example in a folder like:

<WWW root>\redirect\logoffredirect.asp  (is the file was an ASP named logoffredirect.asp)

where <WWW root> is the base document folder for the web server site.

Configure the Page as the LogoffUri Agent Parameter:
Setting the custom redirect page as the logoffUri for SiteMinder ensures that the SiteMinder session is ended so that when the user is redirected page to the federation URL they will then be prompted to log in again. In the example above, the URI for the page is /redirect/logoffredirect.asp. To add this:

  1. Open the Agent Config Oject (ACO) for the Web Agent  installed on the server with the custom redirect page.
  2. Uncomment the LogoffUri parameter and add the URI (not URL) for the custom redirect page.
  3. Save the ACO.

The configuration change will be automatically picked up be the agent. In this example, the ACO looks like the following image:

Set the Server Error URL:
Once the custom error page is deployed and configured as the LogoffUri, the next steps is to tell SiteMinder to redirect to this page when the user would normally receive a 500 error from the federation web service. While we are using to redirect the 500 error thrown when a user is not authorized, this has the side effect of sending all 500 errors to the redirect page. This may or may not be an issue in your environment. To configure the Server Error URL:

  1. Open the SiteMinder FSS Administrative UI.
  2. Click on the Domains tab.
  3. Open the federation domain.
  4. Click on the SAML Service Providers left-nav item.
  5. Open the Service Provider configuration.
  6. Click on the Advanced tab.
  7. Click the [Custom Error URL Config] button.
  8. Check the Enable Server Error URL checkbox.
  9. Enter the URL for the custom redirect page (e.g. https://saml.com.com/redirect/logoffredirect.asp).
  10. Change the drop-down to Http Post.
  11. Save the configuration.

Setting the drop-down to Http Post is required so that the necessary information is sent to the redirect page. This allows the redirect page to redirect the user back to the correct Service Provider configuration. Making the redirect page dynamic ensures that a common redirect page can be used for multiple Service Provider configurations.

 

Tags: , , , ,
Posted in Identity and Access Management | 4 Comments »

CoreBlox is Hiring!

Wednesday, August 17th, 2011

Need one good reason to join the CoreBlox team? How about these polo shirts?!

You may have already noticed the shiny new updates to our Jobs page, but just in case you missed it: we’re hiring! We’re finding that the number of project opportunities in the Identity & Access Management space continues to grow at a rapid pace, and we’d like to be able to staff more of these engagements while continuing to provide excellent service to clients we’ve already worked with. CoreBlox has primarily focused on SiteMinder and Radiant Logic since we launched the company in 2005, but we’re looking to diversify our product knowledge base by finding folks with experience in CA Identity Manager, CA Role & Compliance Manager, CA Access Control, and other related technologies. We need folks who can handle responsibilities ranging from architecture and scoping all the way through to deployment and support.

Our standards are high but the work and rewards are compelling. If you’re interested, please contact us and tell us why you think you’re a good fit!

Tags: , , , , , ,
Posted in CoreBlox News | No Comments »

Migrating SiteMinder r12 Policies Between Tiers

Tuesday, August 16th, 2011

So, you spent all this time getting SiteMinder integrated with your applications in Dev.  Now it’s time to move your policies to QA and then on to Production. You can see it now, hours of work to manually reenter everything you set up in Dev. Oh yeah, don’t fat finger anything either since tracking down a mismatched policy is like finding a needle in the haystack.  Whoa there cowboy!  There is a better answer.  You can migrate the policies automatically -IF- you handle it just right…

The key to determining the best approach to migrate policies is to have a plan from the start. This way you can set up the proper path to move policies through the environment without having to (mostly) manipulate the policies.  There are probably another 20 ways to do this that people have thought through, but this works for me.  If you know a better way, enlighten me in the comments section below (seriously, I want to know).

Migrating SiteMinder policies in r12 has a few limitations that should be kept in mind:

  • Many of the new objects in r12 (e.g. EPM applications) cannot be migrated the way you did things in SiteMinder 6 (smobjexport, Perl CLI, Java API, etc.). They’re not exposed to those tools.
  • You need to have a user with the correct rights set up in SiteMinder.
  • Certain items (e.g. redirect URLs) may still need to be updated either manually or by modifying the import file.
  • Global policies/rules/responses don’t seem easy to move using this approach. So, unless you can figure it out, it may be easier not to use them.

So, what are the tools to make this happen?  There are three:

  • XPSExplorer: Interactive command-line utility that allows an administrator or application developer to view the data in a policy store.
  • XPSExport: Tool for extracting policy data from SiteMinder in an XML-based format.
  • XPSImport: Tool for taking a file extracted by XPSExport and importing it into another policy store.

You are also going to need to become familiar with the term, “XCart,” which is how you specifically define which objects you want to move between the tiers.  In this example I’m going to leave out the complexities around import modes, etc., because the approach is what I think is most important here.

So, how do you get this process going? First, some terminology:

  • Source: The system where you develop all policies and are trying to take those policies and move them into another tier
  • Target: The system(s) where you are trying to take polices from another tier and move thing into the local policy store.

So, in my example, Dev is the source and QA is the target.

The key is to always migrate from the source environment into the target tiers and to never manually create objects in those targets. That way your objects will be correctly linked based upon the unique ID of the object being migrated. This is the key because once you don’t have that link, you’re stuck trying to manually manipulate the files to fix the relationships between the objects. You can modify them, though, since the ID of the object stays the same. So, once the objects have be migrated, go in and adjust the URL’s, etc., as needed.

Here is the approach:

  1. Create your base objects your Dev environment. These objects would be things like: Agents; Agent Groups; User Directories; Authentication Schemes; SQL Query Schemes; Auth/Az Mappings; AuthValidate; Mappings and Certificate Mappings.  Hosts, Agent Config Objects and Host Config Objects don’t need to be migrated since those are not linked directly to policies.
  2. Export the objects created in step #1. This gives you all the objects that you are going to link to when you migrate policies to these targets. You can keep this file in case you create new target systems down the road.
  3. Import the base objects into each target tier. Don’t forget that system level objects like ODBC configurations will not be migrated and need to be created manually.
  4. Modify the migrated objects so that they are relevant for that tier. So, this includes things like: User Directory IP address and credentials and Authentication Scheme URL’s.
  5. Create your new policies and be sure to use the objects from step #1 when you need to associate the objects in step #1 with the policy. If a new base object is required, go ahead and create it and just follow the same steps to migrate it to the target tiers.
  6. Export the policies created in step #5.

Now you can import these policies into any target system since all of the base objects are present and all of the links are there.

Here is a simple example that highlights the steps above. In this example I’m going to migrate my base objects (an Agent, User Directory and Authentication scheme) to QA. Then, I’m going to take a policy I created and migrate that as well.  So, let’s give this a shot.  First lets create the XCart for the base objects:

  1. Log into the source policy server and open a command prompt.
  2. Type: XPSExplorer
  3. The XPSExplorer tool opens with its plethora of options
  4. Enter 15 to export an agent
  5. The Agent menu appears
  6. Enter S to search the objects
  7. This list of Agents appears
  8. Enter the number of the Agent you want to export (I chose testagent).
  9. The Agent details appear
  10. Enter X to add it to the XCart
  11. It’s hard to see that it actually did anything, but the X setting has now turned to remove from XCart instead of Add.
  12. Enter Q three times
  13. Enter 57 for User Directory
  14. Enter S to search the list of directories
  15. Enter the number of the User Directory (I chose RadiantOne)
  16. Enter X to add it to the XCart
  17. Enter Q three times
  18. Enter 22 for Auth Schemes
  19. Enter S to display the list of Auth Schemes (this includes all the defaults so you may want to filter this list)
  20. Enter the number of the Auth Schem (I chose Form Scheme)
  21. Enter X to add it to the XCart
  22. Enter Q three times
  23. Now that we have the objects, we need to save the XCart
  24. Enter X to enter XCart Management
  25. Enter N to save cart file as new name
  26. At the “Path to load” prompt (huh?) enter the name of XCart you want to use – I chose baseobjects.cart (In case you missed it, there was a message at the top of the screen that says the file was saved)
  27. Enter Q to leave the XCart Management tool and Q again to exit XPSExplorer

Now we need to export those objects:

  1. Type: XPSExport <the name of the file you want to create> -xf <name of the XCart> (so, I entered: XPSExport baseobjects.xml –xf bassobjects.cart)
  2. Enter a passphrase if prompted.  The passphrase must contain 1 uppercase letter, 1 lowercase letter and 1 number and must be 8 characters long.
  3. The tool spits out the ID’s of the objects it exported

You now have the base objects to move into the target tier.  So, copy the file over and then we’ll run XPSImport to create them.  Here are the steps.

  1. Log into the target Policy Server and open a command prompt (you’ve already copied over the file, right?)
  2. Enter the command: XPSImport <file name> (so, I entered: XPSImport baseobjects.xml)
  3. Enter your passphrase if prompted
  4. The tool exits

Now go about creating your Applications and/or Domains.  For this, I have created an Application called “Test App.” Select the base objects created above when creating this application.

Once that is done, we can walk through the same steps we used to export the base objects. However, now select the new application when you use XPSExport from the source system.  You can create a new XCart or since in this case I am just exporting a single Application and an Application is an object that can be granularly exported, I’m just going to export it directly.  You still use XPSExplorer to get the ID of the object.  So, I entered the following command to export my Application:

XPSExport testapp.xml -xo CA.SM::Domain@03-66822cfa-b8c5-4620-9834-e3e45edf162d

Once you copy over the file, now run XPSImport to import the new Application into the QA tier:

XPSImport testapp.xml

That’s it. You now have everything you need to set up a clean migration path between SiteMinder tiers. You can use this approach as the basis for migrating other objects. To move multiple Applications and/or Domains (or any other objects), use XPSExplorer to create a new cart of the objects and use that as the cart for the export file. Since the base objects are all there, everything will link up and import as planned.

Tags: , , , , ,
Posted in Identity and Access Management | 3 Comments »

IdentityLogix and CoreBlox Team to Bring Continuous Monitoring Solutions for Radiant Logic and CA SiteMinder Environments

Tuesday, July 12th, 2011

Crown Point, IN (PRWEB) June 30, 2011

IdentityLogix and CoreBlox today announce a partnership to provide on-premise and cloud based continuous security monitoring and real-time actualization for Radiant Logic and CA SiteMinder sites. CoreBlox will provide private and public entities who utilize CA SiteMinder R6 & R12, along with SiteMinder enabled applications, such as CA Federation Security Services, SOA Manager, and Federation Manager and/or Radiant Logic RadiantOne Virtual Directory (VDS) and Identity Correlation and Synchronization Server (ICS) technologies, the visibility to proactively perform security analysis and rapid troubleshooting. The combination of CoreBlox expertise and SpyLogix™ software platform will allow organizations to enhance information security while reducing costs and support complexity.

“We are excited to partner with CoreBlox, a trusted service provider for CA and Radiant Logic identity and access technologies, as we work to provide a level of real-time access and visibility that was not previously available,” says V. Michael Hrobat, Vice-President of Sales and Marketing for IdentityLogix. “We believe that CoreBlox providing both on-premise and cloud based solutions will give organizations business flexibility, while at the same time raising the quality level within corporations as plans are formulated to have continuous analytical monitoring of identity security and activity across the enterprise.”

“The SpyLogix™ software platform is an exceptional fit for any CA or Radiant Logic customer that seeks to discover and resolve security infrastructure issues before they become a larger problem for the user base,” says Chad Northrup, Vice President of Client Services for CoreBlox. “This technology offering is a natural extension of our services capabilities, and it provides the real-time intelligence we need to scale our support offerings in the cloud.”

CoreBlox provides Identity & Access management consulting services and dedicated support offerings for CA SiteMinder, Radiant Logic VDS/ICS, and a number of related products. The SpyLogix security middleware software now provides users of SiteMinder and RadiantONE VDS/ICS an efficient conduit for finding that “needle in the haystack” for issue resolution, proactive identity analysis and access to security data on demand for IT GRC enablement.

The end result is that SpyLogix middleware technology combined with CoreBlox’ technical expertise will enhance the efficiency and effectiveness for information security governance, risk control, and administrative troubleshooting being conducted within an organization. Organizations achieve business outcomes of enhanced security and reduced staff burden, which results in improved productivity and cost savings.

About IdentityLogix
IdentityLogix is an innovator in providing software for information security intelligence, data actualization, identity assurance, enablement of information technology governance, risk, and compliance (IT GRC) initiatives for both public and private entities. SpyLogix Enterprise software protects business information assets from multi-faceted cyber threats by continuously monitoring end-users, networks, identity systems, and multi-platform application systems in real-time. Identity assurance solutions leverage biometrics for verifying users strongly to enhance self-service password reset and identity verification. For more information please visit http://www.identitylogix.com.

About CoreBlox
CoreBlox is a leading provider of enterprise security services. Headquartered in Framingham, MA, the CoreBlox team specializes in single sign-on (SSO) and web access management solutions, SAML and identity federation services, and LDAP Directory Virtualization, with broad experience managing, executing and supporting Identity Management deployments. CoreBlox’ commitment to service excellence has won successful clients across the Fortune 500 and in a number of key verticals including Banking, Information Technology, Insurance, Telecommunications, and the Public Sector. For more information, please visit http://www.coreblox.com.

Tags: , , , , , , , , , , , , , ,
Posted in CoreBlox News | No Comments »

Collection of Useful SAML Tools

Saturday, June 11th, 2011

Architecting and deploying SAML-based federation for companies using tools like PingFederate and CA SiteMinder is one of CoreBlox’ key services. Since I find myself using the same sites repeatedly during these deployments, I thought it would be useful to jot them down for your enjoyment. There are other sites out there are as well, but these few always seem to be on my list:

Update - This was also brought to my attention: SAML Tracer for Firefox

Since this also comes up, here are the steps I use to create a self-signed certificate with OpenSSL for use with SiteMinder for Federation. The certificate can be used to sign SAML assertions during testing (or I cheat sometimes and using it in production since I can create a certificate with an extended expiration date). I am not an OpenSSL expert, but these steps seem to do the trick (be sure to substitute your desired values):

Generate Private Key and Cert:

> openssl req -x509 -days 3650 -newkey rsa:1024 -keyout saml_key.pem -out saml_cert.pem

Enter PEM Passphrase:  password
Verify Passphrase:  password
Country:  US
State:  Massachusetts
Locality:  Framingham
Organization Name: CoreBlox
Organizational Unit Name: SiteMinder Team
Common Name: ps.coreblox.com
Email Address: siteminder@coreblox.com

Convert Private Key PCKS8 DER Encoding:

> openssl pkcs8 -topk8 -inform PEM -outform DER -in saml_key.pem -out saml_key.pkcs8

Enter Passphrase:  password
Enter Encryption Password:  password
Verify Encryption Password: password

Create SiteMinder Key Database (if you haven’t done this already):

> smkeytool.bat -createDB -password password -importDefaultCACerts

Import Certs into Key Database:

> smkeytool.bat -addPrivKey -alias defaultEnterprisePrivateKey  -certfile saml_cert.pem -keyfile saml_key.pkcs8 -password password

Validate certs imported correcly:

> smkeytool.bat -listCerts -alias defaultEnterprisePrivateKey

I hope this is helpful.  If you have any tricks or sites you use, please post them in the comments.

Tags: , , , ,
Posted in General, Identity and Access Management | 2 Comments »

Collection of Useful SiteMinder Videos

Friday, June 3rd, 2011

CA SiteMinder is a sophisticated product with a considerable number of options and deployment scenarios.  The product also is constantly evolving to meet new requirements and challenges.  This post contains links to some of the recent videos that we have found which provide some good insights into product basics, new functionality and ways to get the most out of your deployment:

Have you come across any other useful videos?  If so, post the links in the comments below.

Tags: , , , , , ,
Posted in General, Identity and Access Management | No Comments »

Webinar Recording: Identity Virtualization: Untangle Your Integration, Upgrade Your Portal, and Supercharge Your SiteMinder

Tuesday, March 23rd, 2010

Last month, Todd was part of a webinar with Dieter Schuller (from Radiant Logic) and Andras Cser (from Forrester Research) where the topic was how to simplify your CA SiteMinder implementation using Radiant Logic’s Virtual Directory Server.  Here is the video of the webinar.  As always, feedback is welcomed or contact us with any questions.

-Dave

Tags: , , , , , ,
Posted in Identity and Access Management, Virtual Directory | No Comments »

CA SiteMinder Expands Open Source Support

Monday, February 8th, 2010

opensource_logoThis morning I noticed an interesting item in my news feed that CA SiteMinder has been expanded to support web applications and services running on JBoss Enterprise Middleware. This means that popular platforms such as JBoss Enterprise Application Platform, JBoss Enterprise Portal Platform, and JBoss Enterprise SOA Platform are now fully in play for CA SiteMinder customers.

Anyone who is familiar with enterprise software can tell horror stories about its acquisition & maintenance costs, not to mention the frustration that comes when an internal team identifies a bug that must await a formal fix from the vendor because its root cause lies in the source code. Only those who have experienced this pain can fully appreciate the value of the open source model. The CoreBlox team leveraged an open source platform during the early stages of the company and we were continually impressed by the passionate community that backed it up and was always willing to help. It’s encouraging to see a large corporation like CA recognize the importance of extending SiteMinder support to those who choose to build their infrastructures (either solely or partly) on open source technologies. Well done, CA!

Tags: , , , , , , , , , , ,
Posted in Identity and Access Management, Interesting Info | No Comments »

« Older Entries