Layer7 Access Management

Expand all | Collapse all

Approach for migrating Policy store from Oracle DB to CA Directory

Jump to Best Answer
  • 1.  Approach for migrating Policy store from Oracle DB to CA Directory

    Posted 09-22-2017 07:51 AM

    Hello SiteMinder wizards,

     

    I need to work on a requirement where customer is planning to migrate from Siteminder 12.52 (On-Premise) to Siteminder 12.7 (AWS cloud). In addition to that current Siteminder 12.52 has Oracle DB as Policy Store. Customer wants to replace Oracle DB with CA Directory as policy store when moving into 12.7. I just want to check what would be my high level steps for this migration. Is there anything I need to specifically plan or be careful about?

     

    So there are 2 tasks here.

    1. Upgrade from 12.52 On Premise to 12.7 (deployed on private AWS cloud). 
    2. Move Policy Store from Oracle DB to CA Directory

     

    I am wondering if I should first upgrade Siteminder or should I first replace Policy store? Or the sequence doesn't matter?

     

    As I understand, I can export policy objects from existing Siteminder admin console (in form of XML) and then import the same XML into new Siteminder instance. Is there anything else I should be worried about? Do we have any tech document which talks about migrating Policy store from DB to LDAP?

     

    Thanks a lot for your time.

    Nitin Nigam



  • 2.  Re: Approach for migrating Policy store from Oracle DB to CA Directory
    Best Answer

    Posted 09-22-2017 09:48 AM

    We are not touching OR upgrading R12.52 environment. That stays as is. This is an use case of Parallel Upgrade.

     

    Task-1 : Review the documented Steps & understand the process.

    https://docops.ca.com/ca-single-sign-on/12-7/en/upgrading/complete-the-upgrade-prerequisites

    https://docops.ca.com/ca-single-sign-on/12-7/en/upgrading/parallel-upgrade

     

    Task-2 : Prepare a step by step upgrade plan. This would allow you to track and monitor changes. It is crucial we do this before we start the upgrade as it helps us better understand how the generic product documented process would apply to our environments. Take this step seriously as many hidden gotcha's are revealed beforehand when we visually design the flow / steps on paper before actuals.

     

    Task-3 : Identify a lower environment where we could attempt the migration. Also cross verify / check Documented Upgrade Plan.

     

    Task-4 : Install a vanilla OOB R12.7 with CA Directory as Policy Store.

     

    Task-5 : Review your R12.52 KeyStore & R12.7 KeyStore Deployment strategy to maintain SSO between R12.52 and R12.7.

    • Align KeyStore as per strategy & SSO requirements

     

    Task-6 : Object Migration.

    • Review your current objects in R12.52 environments (e.g.  Federation, Certificates, Policy Objects etc).
    • Take a XPSExport from R12.52 environment (using flags -xp -xe -xi).
    • Before XPSImport in R12.7 run a validateOnly (using flags -validateOnly).
    • Fix any anomalies that the XPSImport (with flags -validateOnly) reports.
    • Import the objects without -validateOnly after all reported anomalies are fixed.
    • Review custom solutions OR custom developments.
    • Recompile custom code using R12.7 SDK or look for appropriate alternatives for the solutions.

     

    Task-7 : Pointing WebAgents to R12.7. Since you are migrating from OnPremise to AWS. I'd assume the WebAgents / Applications would also be migrating to AWS.

     

    Task-8 : At every step, go back and update the documentation. Track Issues / Solution / Closures.



  • 3.  Re: Approach for migrating Policy store from Oracle DB to CA Directory

    Posted 09-22-2017 12:22 PM

    Hi HubertDennis

     

    Thanks for quick and detailed response. This surely helps.

     

    Thanks,

    Nitin



  • 4.  Re: Approach for migrating Policy store from Oracle DB to CA Directory

    Posted 09-22-2017 12:56 PM

    Just one added caution. 

     

    I mentioned for XPSExport using flags (-xp -xe -xi); but it really depends on how we want to migrate the Policy Store i.e. one shot full store OR phased object migration. Based on the approach adopted the flags would different for Export. If we need to cleanse the policy store of redundant / dirty objects, phased approach is preferred. If there is a shorter way to cleanse objects from a full export, we could explore that avenue as well. It really is a case by case scenario.