Layer7 Access Management

A Primer on CA SSO REST APIs for Migrations and Upgrades

By Pashapour posted 11-20-2017 05:13 PM


There was a time when Java applets were considered the greatest invention in computer science. That was back in the late 1990s, when applets managed SiteMinder (now CA SSO) access control policies. This arrangement was useful, but it had its limitations. Then along came newer versions of CA SSO, complete with the web-based admin UI application.


With the newest version of CA SSO, the environment is now 64-bit—much faster and more capable for agent-based and federation-based access control.


But the best part, for me anyway, is using REST APIs to administer the environment. Let me give you a quick tour.



Clicking on the link to REST APIs at the bottom of the admin UI screen gives us access to the admin UI Swagger interface. Once you authenticate, you have 15 minutes to make REST API calls for all sorts of CA SSO objects.



This interface shows you how to make API calls using CURL, which can be quite handy for many situations, including command line interactions. When you install the CA SSO SDK, you will also find Java-based SDK 64-bit samples. If you’re interested in what intrigues me the most, I've been looking into Policy Migration API and Core Policy Objects.  


Migration APIs have export and import endpoints that easily export domain-level objects such as realms, rules, responses and policies. For example, when using the Swagger interface, code like that below will export the whole webservices.domain and create a file named domain-export.xml.  For brevity, I’ve changed my token to $$:


curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/octet-stream' --header 'Authorization: Bearer $$ -d '{"mainObjectsMethod": "ADD","closureObjectsMethod": "ADD","passPhrase": "SomePassPhrase01","suggestedFileName": "domain-export.xml","objects": [{"path": "/SmDomains/webservices.domain"}]}' 'https://<my admin ui fqdn>:8443/ca/api/sso/services/policy/v1/deployment/export'


If you make the CURL call directly from the command line, the response will be the complete export in XML format. You can then feed the exported XML file as an input to another environment. Don’t forget to add the passphrase from export before the actual xml input.


curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header 'Authorization: Bearer $$ -d 'SomePassPhrase01

<XPS><XPSVersion>1</XPSVersion><HostInformation></HostInformation><XPSAdmin>siteminder [SM://0004690d-ee9c-1851-ae9c-7a01c0a8487f/siteminder]</XPSAdmin>

     <PolicyData IsDumpExport="false">

                 <Object Class="CA.SM::AgentType" Xid="CA.SM::AgentType%4010-8d78bb96-ae15-11d1-9cdd-006008aac24b" CreatedDateTime="2016-12-15T01:31:12" ModifiedDateTime="2017-07-06T16:47:31" UpdatedBy="XPSDictionary::Import" UpdateMethod="Internal" ExportType="Add">


         <Object Class="CA.SM::Agent" Xid="CA.SM::Agent%4001-000cdc32-1a83-1a0b-a3de-b182c0a8cd7f" CreatedDateTime="2017-11-14T16:32:15" ModifiedDateTime="2017-11-14T16:32:15" UpdatedBy="My Admin" UpdateMethod="GUI" ExportType="Add"><Property Name="CA.SM::Agent.RealmHintAttrId"> <NumberValue>0</NumberValue></Property><Property Name="CA.SM::Agent.AgentTypeLink"><LinkValue> <XID>CA.SM::AgentType%4010-8d78bb96-ae15-11d1-9cdd-006008aac24b</XID> </LinkValue></Property><Property


Name="CA.SM::Agent.Name"><StringValue>throwaway.agent</StringValue></Property></Object></PolicyData> </XPS>' 'https:// <my admin ui fqdn>::8443/ca/api/sso/services/policy/v1/deployment/import'


As I said earlier, the SDK installation includes sample Java codes for export/import. In my Linux environment, I have it installed at /opt/CA/sdk127/samples64/restapi/basic


To build and run it, just

  • ./ [export, import, manage] -i for interactive admin username/password or use the file


For example:


./ export -ap https://localhost:8443/ca/api/sso/services/login/v1/token -ep https://localhost:8443/ca/api/sso/services/policy/v1/deployment/export -pphrase SomePassPhrase01 -file myoutput.xml –i


./ import -ap https://localhost:8443/ca/api/sso/services/login/v1/token -ep https:// localhost:8443/ca/api/sso/services/policy/v1/deployment/import -pphrase SomePassPhrase01 -file myoutput.xml –i


./ manage -ap https://localhost:8443/ca/api/sso/services/login/v1/token -ep https://localhost:8443/ca/api/sso/services/policy/v1 -i


The last call has some great examples of how to create, update and delete core objects like domains and policies.


As you can see above, these REST API calls can easily be used for migrating from one environment to another—for example, from Dev to QA and production environments. You can even version the files to keep track of objects being added/deleted/updated.


For one of my most recent CA SSO upgrade customers, I used APIs to make sure only selected objects were recreated and updated in the new environment, to prevent moving everything from distant years.


There you have it—a primer on using REST APIs to administer the CA SSO environment. Questions? Comments? Contact me at

1 view


12-04-2017 01:34 PM

Good question, Brian


To start, I used the swagger interface to get existing objects. For example, to see existing rules, you can make

Which is equivalent of a curl call like:


curl -X GET --header 'Accept: application/json' --header 'Authorization: Bearer $$$' 'https://localhost:8443/ca/api/sso/services/policy/v1/SmRules'


Which gives a lengthy JSON output for all the rules you have in an array surrounded by [ ]

"responseType": "links",
"path": "children",
"xpsclass": "SmRules",
"data": [
"id": "CA.SM::Rule@0b-0006a3e2-5bc0-1853-a41a-b182c0a8577f",
"path": "/SmDomains/DOMAIN-SPSADMINUI-secureproxy-01/SmRealms/REALM-SPSADMINUI-secureproxy-01/SmRules/RULE-SPSADMINUI-secureproxy-01",
"href": "https://localhost:8443/ca/api/sso/services/policy/v1/objects/CA.SM::Rule@0b-0006a3e2-5bc0-1853-a41a-b182c0a8577f",
"desc": "Rule for protecting Proxy UI"


To get existing policies, you can make similar call for SmPolicy:


Which gives an array of SmPolicy objects like:

"id": "CA.SM::Policy@04-000a3aaa-2529-19e6-a99c-b182c0a8ce7f",
"path": "/SmDomains/Restapi.domain/SmPolicies/restapi.allow.policy",
"href": "https://localhost:8443/ca/api/sso/services/policy/v1/objects/CA.SM::Policy@04-000a3aaa-2529-19e6-a99c-b182c0a8ce7f",
"desc": "Allow policy created by rest api"

12-04-2017 01:18 PM



Great post - good starting point for my foray into the REST API.


What process did you use to identify old policy objects?  Maybe that's a follow up post on your blog.