Unable to activate Federation Partnership for Production

Document ID : KB000009965
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

How should one migrating a Federation configuration from one environment to another?

How do I fix the policy store if there are hidden partnerships that are causing problem?

 

Background:

Federation partnership was setup in lower environment and for convenience, it was exported (XPSExport -xe and XPSExport -xp) and imported in Production.

However, the federation partnership does not display in AdminUI.

So, you create a new (same) partnership but fails to activate as it complains there is an existing partnership.

Environment:
This is not specific to a version.R12.52SP1 PS and AdminUI on RHEL6 in this sample.
Instructions:

When you are setting up a federation in one environment and need to migrate it to another environment, it is best to export the metadata and import at the other environment.

From the AdminUI, navigate to Federation Partnerships.

If IDP2SP Partnership, when you select Export Metadata, it would export the IDP Entity.

If SP2IDP Partnership, when you select Export Metadata, it would export the SP Entity.

You can only export the "Local Entity" because the Metadata for "Remote Entity" is what you would have received from your counter part.

If you do not have and unable to get the metadata for Remote Entity, you will have to refer to the policy store export and create a matching one manually.

 

 

If you tried XPSExport to migrate, there can be problems.

When running XPSExport -xe and -xp to export the policy store, it would not export all the federation configuration.

Also, Federation Partnership is exported without the entities and no "CA.FED::PartnershipBase" which is requred for AdminUI to read the related Domain object.

This cause a problem and the AdminUI would not display this partnership.

However, if you do another policy store export(XPSExport -xb), you can see the partnership actually exist.

 

This also causes a conflict if you try to create the same partnership again and will fail to activate if the imported partnership was in active state.

 

If you did encounter this condition, please follow the steps below to fix the problem.

 

1. Do a "XPSExport -xb bad.xml -pass yourpass"

2. Perform a DB backup or LDIF export of your policy store to ensure you can revert to exact same status if anything goes wrong.

3. Load the bad.xml with Policy Store reader tool.

4. Locate the problematic partnership at the "Applications" tab. It would appear as a Domain.

If your partnership name was "samlsp:sso2partner" then you would find "samlsp:sso2partner" Domain.

5. Select the "samlsp:sso2partner" Domain and check the "Xid" value of this Domain.

At the right panel, under "Attributes" section, you will find Xid value "Domain@03-055611e8-e1e2-46c8-8dbf-1e67f5a5c9fe" for example.

6. Load the bad.xml file with text editor(those that understands xml) and locate the matching value.

<Object Class="CA.SM::Domain" Xid="CA.SM::Domain@03-055611e8-e1e2-46c8-8dbf-1e67f5a5c9fe" CreatedDateTime="2016-06-17T09:27:59" ModifiedDateTime="2017-01-03T23:42:38" UpdatedBy="smuser" UpdateMethod="GUI" ExportType="Replace">

As this is a Domain object, there would be other child elements(realms/rules/policies) under it.

7. Delete the whole Domain section.

Select from:

<Object Class="CA.SM::Domain" Xid="CA.SM::Domain@03-055611e8-e1e2-46c8-8dbf-1e67f5a5c9fe" CreatedDateTime="2016-06-17T09:27:59" ModifiedDateTime="2017-01-03T23:42:38" UpdatedBy="smuser" UpdateMethod="GUI" ExportType="Replace">

 

And select until:

</Object><!-- Xid="CA.SM::Domain@03-055611e8-e1e2-46c8-8dbf-1e67f5a5c9fe" -->

And delete.

If you do find "CA.FED::PartnershipBase" that has a reference to this "CA.SM::Domain@03-055611e8-e1e2-46c8-8dbf-1e67f5a5c9fe" then that whole PartnershipBase section has to be deleted as well but it would not be the case if the migration was performed by using XPSExport -xe and -xp.

8. Delete the Agent matches the "samlsp:sso2partner" name.

        <Object Class="CA.SM::Agent" Xid="CA.SM::Agent@01-279fb169-b307-453d-b0e6-e5137e3489be" CreatedDateTime="2016-06-17T09:34:33" UpdatedBy="PRODUCT: CA.FED LIBRARY: FedObjects" UpdateMethod="Internal" ExportType="Replace">

            <Property Name="CA.SM::Agent.AgentTypeLink">

                <LinkValue>

                    <XID>CA.SM::AgentType@10-fbe22c2f-ce96-4465-a8f3-45219bdd5232</XID>

                </LinkValue>

            </Property>

            <Property Name="CA.SM::Agent.RealmHintAttrId">

                <NumberValue>0</NumberValue>

            </Property>

            <Property Name="CA.SM::Agent.Name">

                <StringValue>samlsp:sso2partner</StringValue>

            </Property>

            <Property Name="CA.XPS::MetaAttributes.HidingMask">

                <NumberValue>1</NumberValue>

            </Property>

        </Object><!-- Xid="CA.SM::Agent@01-279fb169-b307-453d-b0e6-e5137e3489be" -->

9. If you are SP2IDP partnership, then you would also find Authentication Schemes that match the partnership name as well.

Search for "samlidp:sso2partnership_auth" and remove the Authentication Scheme object.

But in this sample, because sso2partnership was IDP2SP partnership, it would not have the authentication scheme.

10. Save the bad.xml as good.xml

11. Load the good.xml from Policy Store reader and see if there are any broken references.

It is actually good to save good.xml at each updates and read from Policy Store to ensure every changes are not breaking anything.

 

Once everything looks good, you can now import it to your policy store and test if your newly created partnerships can save without error.

It would be highly recommended to restart the policy server and login to adminui when verifying.

 

Additional Information:

Policy Store Reader: https://communities.ca.com/thread/100333222