SSO Help

Your Source for Help with Single-Sign-On Solutions

Chad Northrup

Maintaining and Migrating Between Environments

Quick discussion topic- what are people doing to maintain multiple security environments, and migrate changes between them? This seems to be something that's very custom from one organization to another, and we've yet to see a list of best practices emerge aside from the obvious (BACK UP EVERYTHING!). Are people using certain tools to handle diffs & migrations? Custom scripts? Please chime in with any info you can provide, and perhaps we can build a repository of tips and potential tools.

Tags: best, deployments, migrations, practices

Reply to This

Replies to This Discussion

I am very interested in this topic as we currently do not have a procedure to move changes from different environments. We are currently recreating each change in each environment in out stack but would like to script the changes.

Reply to This

Interesting topic

Currently we are using the API to manage all changes. We setup our 'siteminder config xml' for an application, which contains all of the elements required for our configuration app to be able to setup the application in our lowest test environment.

Basic logic for how the config app builds the application realms/rules/policies/membership/responses based on our standards is as follows:
The config app checks CVS to see if a previous XML for that app has been checked in - if so, it checks it out of CVS and deletes all of the realms/rules/policies/membership/responses, if one does not exist it moves on and creates all of the realms/rules/policies/membership/responses as they are defined in the XML that the user submitted. When that is complete, it checks in the now latest version of the config XML.

When migrating through the rest of the states, there is an approval process that the config app enforces. The testing authorities for the state approve the migration of the configuration out of their test state (the approve the CVS version number) into the next one. Then the owner of the subsequent test state approves in the migration. The tool then checks out the approved version of the XML, and moves it forward.

The config tool is tied to a db to manage the versions of all the various configs in each state, as well as the approvals and migrations for some basic auditing.

Not fool proof, but is working fairly well for us right now in a somewhat controlled fashion.

I too would be interested to see how others deal with this, as there does not seem to be a perfect way to migrate between environments

Reply to This

RSS

CoreBlox Blog

Loading feed

Radiant Logic Blog

Loading feed

Matt Flynn's IDM Blog

Loading feed

IdentityStuff

Loading feed

Ash's IdM Rantings

Loading feed

Burton Group: Identity Mgt Blog

Loading feed

IdM Thoughtplace

Loading feed

Identity Thought Stream

Loading feed

Jackson's Identity Management & Active Directory Reality Tour Travelblog

Loading feed

Discovering Identity

Loading feed

© 2010   Created by Core Blox

Badges  |  Report an Issue  |  Privacy  |  Terms of Service