Migrating SiteMinder r12 Policies Between Tiers

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.