Coping Portal objects from Test to production on different Domains

Question

I want to know if anyone besides my company uses separate domain environments to do development, QA, and production. How did you get around the object owner issues that come from this level of security. Did you have to Export OID objects from one environment, and import them into the other environments to get a common GUID? Do you use a common user to do development? I would like to hear some common/best practice advise if you have any.
For those that want to understand the issues here is a little example:
For this example, I am going to call my company Acme (I like this name). Acme uses a Sneaker method of security (Sneaker method means - To move data from one level to another, you must put in on a diskette, tape, or CD and put your sneakers on the floor and walk it to another location to install it.). While this is the most secure method out there to day, it makes working in development EXTREMELY difficult. Completely isolated environments require special concerns. I wanted to know if anyone out there does this now, and how they manage these issues.
Domains:
www.Acme.com
www.QAAcme.com
www.DevAcme.com
When you do development on your site you login as a portal developer JSmith, or KJones, of BRight on the www.devacme.com domain. You build your Portal objects and custom stuff. Now you want to move it to QA, so they can test it and promote it to Production. You build your transport sets. You export using your UNIX script and get your file. You burn the file and the UNIX script to CD.
You then take the CD to the www.QAAcme.com domain Portal server and login to that system as Oracle / OrcAdmin (God mode). You run the Import script as you normally would. <Error> This doesn't work completely because your user Jsmith is different on this domain and doesn't carry the same GUID in OID. While privileges and spelling are identical, the GUID's in OID differ and the domain names don’t match. (Problem - Separate domains and OID identities - objects without matching owner GUID's will not import.)
When you check your stuff you realize that some or most of your work is missing, and all of the security that you placed on the objects is not working correctly either. Because domains are different, any OID users which you assigned permissions to are now not working at all. You will have to redo all the permissions work on this domain just like you did on the other domain. (Problem - there is no easy way to change domain names associated to OID users or group accounts, even if the names are EXACTLY the same. Permissions do not move over for users so assigning item level security is a waist of time since you will have to manually do all that work over again.)
To correct then problems above, you go and export OID user objects like OrclAdmin, IAS_Admin, and a few others. You import these identities on each domain. Now what? Do you give developers 1 identity to do their work? Pass out the Admin passwords on Dev to all the developers to do as they please? Do you build a Dev User for each Developer you have and manage those ID's outside of your normal routine?
This should draw a somewhat clear picture. There are more issues besides these. I left those out of this talk for now.
If you have questions please let me know. I would like to hear input on this. Right now, I don't have any easy solutions, just a lot of extra work. Thank you in advance for any input.
Frank

Answer 1

Hi Frank,
A very interesting question, which I never tried nor seen. Anyway, maybe I can try to give you a hand...
I believe the major problem doesn't seem to be the GUID but rather the privileges of the users / groups within the Portal. I'm assuming that you really want that the users and groups privileges be assigned to the three Portals, 'cause you wanna test them or something like that... otherwise it would be a lot easier to assign them only to the Production machine - also what the Portal documentation encourages you to do (and never take them with the Portal Export / Import... ie, the Portal ACLs).
In overview, what I think it might work, would be something like:-
1. Export all the OID users / groups to LDIF files.
2. Change the domains in the LDIF files to the Target Portal.
3. Import all the OID users / groups to the Target Portal.
4. Export with the Portal Export to a Transport Set.
5. Export the Transport Set to a DMP.
6. Import the DMP.
7. Backup the Portal Target at this stage - ALWAYS!
8. Before merging the DMP file the WWUTL_SEC_TX_PERSON$ and WWUTL_SEC_TX_GROUP$ tables need to be changed - DN (security is taking IDs of the users/groups internally to the Portal - so this should be fine).
9. Merge the Transport Set within the Portal UI.
Till point 8 it should be easy to be done... and you may check the Portal Configuration Guide over the 10.4.8 Migrating Users and Groups - http://download.oracle.com/docs/cd/B14099_19/portal.1014/b19305/cg_imex.htm
On step 8 do something like the following:-
-- groups (dn)
update WWUTL_SEC_TX_GROUP$
set dn=replace( dn, 'dc=dev_domain,dc=com', 'dc=prod_domain,dc=com' )
update WWUTL_SEC_TX_GROUP$
set dn_hash = wwsec_api_private.get_dn_hash( dn )
-- users (dn)
update WWUTL_SEC_TX_PERSON$
set dn=replace( dn, 'dc=dev_domain,dc=com', 'dc=prod_domain,dc=com' )
update WWUTL_SEC_TX_PERSON$
set dn_hash = wwsec_api_private.get_dn_hash( dn)
If you do have the opportunity to test this, I'd be much appreciated in knowing whether you've achieved to get this sorted out. And even if there is something I may be missing then you may come back with your questions as I'll try to answer them to my best knowledge.
Alternatively, you can use the cloning notes within the Metalink website, what they do is a schema database export / import and there it IDs with be there. The only downside is that the export / import will do everything and Portal Export / Import is more flexible, ie, you may not be interested in bringging the whole Portal, but just a couple of pages or Page Groups.
I hope it helps...
Cheers,
Pedro.
PS - I hope all the above makes sense, but if not, just let me know (or detail me what do you want where I've failed to understand you).