CA SSO REST Services - Facing issues with /ca/api/sso/services/policy/v1/deployment/import service

[Gopi ReddyIrala]

Hello Everyone,

I am trying to explore CA SSO REST API services and I am facing an issue with /ca/api/sso/services/policy/v1/deployment/import service

1. I have exported federation partnership with /ca/api/sso/services/policy/v1/deployment/export command by providing "passPhrase" value as well.

2. Export service worked fine and I was able to download the federation partnership configuration as an XML file

3. I have then changed the federation partnership name and description by opening the XML file

4. I have tried to import the updated XML content with /ca/api/sso/services/policy/v1/deployment/import service. I have also provided the correct "passPhrase" in the body.

5. But I am getting the below error 

[2019-08-28 18:57:26][ERROR][RestServlet:com.ca.siteminder.sdk.restservlet.RestServlet.doLog(RestServlet.java:145)][RESPONSE_BODY:
{
"responseType": "error",
"status": 400,
"data": [
{
"msgId": "sm-xpsxps-05850",
"args": [
"ImportFile_1567018646403.xml"
],
"message": "Decryption failed.",
"code": -1
}
]
}]

I am sure I am giving the correct "passPhrase" .value.

Please let me know if you have any thoughts on this issue.


------------------------------
Thanks,
Gopi.
------------------------------

[Hongxu Liu]

"passPhrase" is required when submitting the request using API import. "passPhrase" must be submitted in beginning of the line on top and within xml content itself.
Here is technical article about the solution:
https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_search?articleId=136473

Hongxu

[Hongxu Liu]

Another related article:
The particular partnership must be deactivated, before importing it again. Otherwise get different error 400 "Import failed."
https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_search?articleId=136633

[Warren Barrow]

I don't believe the scenario will work as you expect because while you've changed the partnership name & description in the XML before import, there are unique identifiers that map to the object name that will continue to cause conflict.

I had tried the same scenario on an EpmApplication.  After changing the name and importing, I received a HTTP 200 OK, but I did not see the new application get created in the UI.   

A better option would be to test the exporting/importing into different policy store environments.  

To test with the same environment, perform an export with the "mainObjectsMethod" set to OVERLAY. Make a name or description change via the UI, then perform the import to see the changes reverted back to original.

Warren