A Step-By-Step Guide to Symantec SiteMinder Integration with Layer7 API Gateway for Automated Creation of SiteMinder Objects

Article By: Tiffany Kongpachith

Symantec SiteMinder provides a unified access management platform that applies the appropriate authentication mechanism to positively identify users; offers single sign-on and identity federation for seamless access to any application; enforces granular security policies to stop unauthorized access to sensitive resources; and monitors and manages the entire user session to prevent session hijacking. The Layer7 API Gateway is an XML firewall and service gateway that controls how web services are exposed to and accessed by external client applications. Utilizing the SiteMinder REST APIs will provide provisioning of SiteMinder objects such as Agents, Authentication Schemes, User Directories, Domains, Realm, Rules, and Policy all with a single click of a request to the API Gateway.

Prerequisites

  • Assumption that SiteMinder Policy Server has fully been installed and configured.
  • Assumption that SiteMinder Administrative User Interface (UI) has fully been installed and configured.
  • Assumption that the user has access to the SiteMinder Admin UI via a web browser.
  • Assumption that a SiteMinder Web Agents or Access Gateway has fully been installed and configured.
  • Assumption that API Gateway has fully been deployed and configured.
  • Assumption that the Policy Manager has been downloaded and accessible.
  • The user has administrative credentials to both the SiteMinder Admin UI and the API Gateway Policy Manager.
  • Contact designated teams / admins to allow the following ports open between the Policy Server and API Gateway to communicate – 44441, 44442, 44443, 44444, 8443, 80, 443.
  • The user has access to an API testing tool such as Postman to generate requests to the API Gateway.

Needs to Know

1. The certificate for SiteMinder will need to be imported into the Policy Manager.
Doing so by  following these steps below:
a. Accessing the Policy Manager and login with credentials.
b. In the Policy Manager, navigate to Tasks > Certificates, Keys, and Secrets.

c. Select Manage Certificates.
d. Click Add for a new certificate to be imported into the Gateway.

e. Select the radio button for ‘Retrieve via SSL Connection (HTTPS or LDAPS URL)’ and enter the URL for Fully Qualified Domain Name (FWDN) or IP address of the SiteMinder Policy Server over port 8443.

f. Click Accept (if entering the URL and the hostname or the URL does not match the certificates’ subject name) then click Next to View Certificate Details and verify the certificate contents.
g. Click Next for Specify Certificate Options and select the following two (2) options for the certificate: Outbound SSL Connections and Signing Certificates for Outbound SSL Connections.

h. Click Next and select Certificate is a Trust Anchor then lastly click Finish.

2. Please reference the SiteMinder REST APIs within the SiteMinder Administrative User Interface (UI) located at the bottom of the screen.

Or refer to the TechDocs documentation of the SiteMinder REST APIs (https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/programming/policy-object-rest-apis/rest-api-reference-documentation.html)

3. Reference the Broadcom Symantec SiteMinder and API Gateway TechDocs documentation for further information to assist on the integration.

Create the Necessary SiteMinder Objects for the API Gateway Integration:

  1. Open a web browser  and enter the URL to the SiteMinder Administrative User Interface (UI).
  2. Login with the SiteMinder administrator credentials.

Create an API Gateway Agent:

1. From the Administrative UI Menu screen, click the Tasks tabs located to the left column, select Infrastructure > Agent > Agents.

2. The list of available Agents should appear. Click ‘Create Agent’ button to create a new Agent object for the API Gateway.

3. Ensure the radio button is selected for ‘Create a new object of type Agent’ then click the OK button.

4. The Create Agent screen should appear. Under General, for the Name field, enter the Fully Qualified Domain Name (FQDN) of the API Gateway.

5. (Optional) You may enter a description for API Gateway Agent in the Description field.

6. Ensure for ‘Select an agent type’ that it is selected for CA Single Sign-On.

7. Ensure for ‘Agent Type’, that it is selected for Web Agent.

8. Click the Submit button to apply changes and create the Agent for API Gateway.

Create an Agent Configuration Object for the API Gateway Agent:

1. From the Administrative UI Menu screen, click the Tasks tabs located to the left column, select Infrastructure > Agent > Agent Configuration Objects.

2. The list of Agent Configuration Objects should appear. Click ‘Create Agent Configuration’ button to create a new ACO for the API Gateway.

3. Ensure the radio button is selected for ‘Create a copy of an object of type Agent Configuration’ and click the OK button.

4. Select the radio button for IISDefaultSettings then click the OK button.

5. Under General, for the Name field, enter the Fully Qualified Domain Name (FQDN) of the API Gateway appliance and add “_aco” at the end.

For example: “testapigateway.com_aco”

6. (Optional) You may enter a description for the API Gateway Agent Configuration Object in the Description field.

7. Under Parameters, locate the parameter #DefaultAgentName.

8. Left of the #DefaultAgentName parameter, click the pencil icon to ‘Modify’ the parameter.

9. Under modification of the #DefaultAgentName parameter, for the Name field, remove the # (hashmark) to make the parameter active. 

Note: This enables and makes the Parameter from Inactive to Active state.

10. For the Value field of the DefaultAgentName, enter the name of the Agent/FQDN of the API Gateway.

11. Click the OK button to save modification to the parameter.

12. Under Parameters, locate the parameter #AcceptTPCookie.

13. Left of the #AcceptTPCookie parameter, click the pencil icon to ‘Modify’ the parameter.

14. Under modification of the #AcceptTPCookie parameter, for the Name field, remove the # (hashmark).

15. For the Value field of the AcceptTPCookie, enter the value as  yes” to enable this parameter.

16. Click the OK button.

17. Scroll down the Parameters to the Active parameters section (Note: Parameters WITHOUT the # in front) and locate that DefaultAgentName and AcceptTPCookie parameters and notice that the parameters do NOT have hashmarks (#) in front.

18. Click the Submit button to apply changes and create the Agent Configuration Object (ACO) for API Gateway.

Create the API Gateway Domain, Realm, Rules, and Policy:

Create the API Gateway Domain –

1. From the Administrative UI Menu screen, click the Tasks tabs located to the left column, select Policies > Domain > Domains.

2. On the Domains page, click ‘Create Domain’ button to create a new domain for API Gateway.

3. Under General, for the Name field, enter the name of what the API Gateway domain should be called.

For example: “API Gateway Domain”

4. (Optional) You may enter a description of that API Gateway Domain in the Description Field.

5. If the User Directory IS present within the SiteMinder list of available User Directories, under User Directories section, select the Add/Remove button.

6. A list of all available User Directories will be shown on the Available Members column. Highlight or select the specified User Directory, click the right arrow key to move the directory from Available Members to Selected Members.

7. Next, click the OK button.

Create the API Gateway Realms –

1. Navigate to the Realms tab within the API Gateway Domain.

2. Click ‘Create Realm’ button to create a new Realm.

3. Under the Realms > General Section, enter in the desired name of the Realm in the Name field.

For example: “API Gateway Protected”

4. (Optional) You may enter a description for the Realm in the Description field

For example: “API Gateway Protected Root”

5. Under the Resource section > Agent, click the ‘Lookup Agent/Agent Group’ button.

6. A list of available Agents will be present, select the radio button for the Agent that will be used for API Gateway.

7. Then click the OK button.

8. For the Resource Filter, enter the desire protected resource filter (URI).

For example: “/”

9. Ensure the Default Resource Protection has the selected radio button for Protected.

10. For Authentication Scheme, select the drop-down and select the desire Authentication Scheme from the available list of Authentication Schemes in SiteMinder to be used when authenticating for the Realm/protected resource.

Create the Rule Set of the Realm for the API Gateway –

  1. For Rules, select the ‘Create’ button to create a new Rule for the API Gateway.
  2. Under General, enter in the desired name for the Rule set in the Name field.
    For example:  “ALLOW-GET-POST”
  3. Under Attributes > Realm and Resource section, enter an asterisk (*) mark.
    Example: (Should be one asterisk mark present)
    Resource = *
    Effective Resource = /*
  4. Under Action > Web Agent Actions, select/highlight “Get” and “Post”.
  5. Then scroll down the page and click the OK button.
  6. Scroll down to the Session section, for Maximum Timeout, ensure the Enabled checkbox is
  7. , ensure the Enabled checkbox is selected and set the Hours and Minutes field selected and set the Hours and Minutes field according to business requirements.
  8. For Idle Timeout according to business requirements.
  9. Then scroll down and click the OK button.
  10. Scroll to the end of the page and click the Submit button in order to save progress for the Domain and prepare to create the Policy that will comprise the Authorization actions for Users in the User Directory attached to the Domain and which Realms to include as a part of the Policy.

Create the Policy for the API Gateway Domain –

  1. The API Gateway Domain has been created. Click the pencil icon to the left of the Domain name to ‘Modify’.
  2. Click the Policies tab.
  3. Click ‘Create’ button to create a new Policy.
  4. Under General, enter the desired Policy name in the Name field.
    For example: “API Policy”
  5. Click the Users tab.
  6. (I User Directory has been added to the Domain – the User Directory will appear) Click “Add All” to add ALL user in the user directories.
  7. Click the Rules tab.
  8. Under Rules, click the “Add Rule” button.
  9. Under Available Rules, select the checkbox for each of the Available Rules of API Gateway Realms and Rules that was created previously.
  10. Click the OK button from the Available Rules page.
  11. Then click the OK button once again from the Policy-Rules page.
  12. Lastly, click the Submit button from Policies tab to save and submit changes.
    The API Gateway Domain, Realms, Rules, and Policy have been created.

Create a REST API in the Policy Manager:

  1. Launch the API Gateway – Policy Manager client.
  2. Enter the administrative credentials to log into the Policy Manager – Gateway node.
  3. Once logged in, navigate to Tasks > Services and APIs > then select Publish Web API to create a new REST API.
  4. The Publish Web API wizard will appear. Enter the Name of what the API will be under the Service Name field.

    For example: SiteMinder API
  5. For the Target URL field, enter the URL for SiteMinder Policy Manager.

    For example:
    https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/
  6. For the Gateway URL field, enter a context URL to access the API protected by the API Gateway.

    For example:
    https://apigwtest.com:[port]/siteminder
  7. Then click Next to proceed to the Access Control configurations screen.
    Note: Please enable SSL if required, Allow Anonymous Access or Required User to Authenticate
  8. Click Finish when configurations are complete.

Create a Policy for SiteMinder Objects:

  1. On the left column of the Policy Manager, the user will see the Assertions Palette of all available assertions to apply to the API Policy.
  2. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Customize SOAP Fault Response assertion. Click and drag the Customize SOAP Fault Response assertion onto the policy.
    Note: Ensure the assertion is at the top of the tree/policy.
  3. Double-click the Customize SOAP Fault Response assertion and from the “Select the SOAP fault level that will be returned in case of failure” drop-down option, select Full Detail then click OK.
    Note: Setting to Full Detail will return a comprehensive SOAP fault message when a problem occurs in a policy.
  4. Below the assertion, right-click the mouse and select the option “Add ‘At least one…’ Folder”.
    The user will see the “At least one assertion must evaluate to true” folder appear on the API’s policy.
  5. Next, click/highlight the “At least one assertion must evaluate to true” folder then right-click again and select “Add ‘All…’ Folder”.

    The user will see the “All assertions must evaluate to true” folder appear on the API’s policy beneath the “At least one assertion must evaluate to true” folder.
    Expected Result –
  6. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Audit Messages in Policy assertion.

    Note: This assertion records events pertaining to the processing of a policy—for example, assertion violations, authentication failures, routing errors, etc. These events can be viewed in the Gateway Audit Events window.
  7. Click and drag the Audit Messages in Policy assertion onto the policy.Note: The Audit Messages in Policy assertion should be underneath the “All assertions must evaluate to true” folder.Expected Result –

    Note: The Audit Messages in Policy assertion should be underneath the “All assertions must evaluate to true” folder.Expected Result –

  8. Next, expand the Policy Logic folder from the Assertion Palette to locate the Set Context Variable assertion.
  9. Click and drag the Set Context Variable assertion onto the policy.
  10. The Context Variable Properties window will appear. Configure the following:
    1. For the Variable Name field, enter “requestBody” as the value.
    2. For Data Type, select from the drop-down options for “Message”.
    3. For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”.
    4. For the Expression field, enter the value as “${request.mainpart}

  11. Then press the OK button to save configurations. The policy should look like the following so far:

  12. Expand the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  13. Click and drag the Evaluate JSON Path Expression assertion on to the policy.
    Note: This assertion is used to query JSON objects like querying XPaths. The user will enter a JSON expression and this assertion parses the target message and places the results into context variables.
  14. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.DomainName”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
      Note: The user is indicating that the target message will pull from the context variable requestBody context variable (which encaptured the full request body).
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smdomain”Note: This action is indicating that once the JSON request body is pulled from the context variable (requestBody) that the Evaluate JSON Path Expression will search against the JSON request body for any entries that match the Expression. (i.e. DomainName) Then exports the matched value into a new context variable defined in Destination – Variable Prefix.Important! Storing variable prefixes gives the user the ability to utilize the contexts. Refer to the documentation of different contexts to use with the variable. (https://techdocs.broadcom.com/us/en/ca-enterprise-software/layer7-api-management/api-gateway/10-0/policy-assertions/assertion-palette/message-validation-transformation-assertions/evaluate-json-path-expression-v2-assertion.html)
  15. Then press the OK button to save configurations.
    The policy should look like the following so far:
  16. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  17. Click and drag the Add Audit Details assertion on to the policy.
    Note: This assertion allows you to define a custom message that can enhance the context of an audit message. These audit messages are then recorded either in the Gateway Audit Events or within the Gateway appliance log. Dependent on configurations.
  18. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events.For example: “The request is ${requestbody} and the Domain Name is ${smdomain.results}”
      Note: When utilizing the Evaluate JSON Path Expression, the user is able to use the contexts for the variable prefix. In this case, we want to use the <prefix>.results context. This context returns the results of the match in the Evaluate JSON Path Expression assertion.
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      Example:

      The policy should look like the following so far:
  19. Next, expand the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  20. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  21. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.AgentName”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smagent”
  22. Then press the OK button to save configurations.
    The policy should look like the following so far:
  23. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  24. Click and drag the Add Audit Details assertion on to the policy.
  25. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events.
      For example: “The request is ${requestbody} and the Agent Name is ${smagent.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:

  26. Next, expand the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  27. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  28. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.RealmName”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smrealm”
  29. Then press the OK button to save configurations.
    The policy should look like the following so far:
  30. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  31. Click and drag the Add Audit Details assertion on to the policy.
  32. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events. For example: “The request is ${requestbody} and the Realm Name is ${smrealm.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:
  33. Continue the process of expanding the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  34. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  35. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.RuleName”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smrule”
  36. Then press the OK button to save configurations.
    The policy should look like the following so far:
  37. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  38. Click and drag the Add Audit Details assertion on to the policy.
  39. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events. For example: “The request is ${requestbody} and the Rule Name is ${smrule.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:
  40. Continue the process of expanding the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  41. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  42. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.PolicyName”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smpolicy”
  43. Then press the OK button to save configurations.
    The policy should look like the following so far:
  44. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  45. Click and drag the Add Audit Details assertion on to the policy.
  46. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events.
      For example: “The request is ${requestbody} and the Policy Name is ${smpolicy.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:
  47. Continue the process of expanding the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  48. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  49. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.ResourceFilter”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “resourcefilter”
  50. Then press the OK button to save configurations. The policy should look like the following so far:

  51. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  52. Click and drag the Add Audit Details assertion on to the policy.
  53. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events.
      For example: “The request is ${requestbody} and the Resource Filter/URI/Protected Resource is ${resourcefilter.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:
  54. Continue the process of expanding the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  55. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  56. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.UserDirectory”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smuserdirectory”
  57. Then press the OK button to save configurations.
    The policy should look like the following so far:
  58. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  59. Click and drag the Add Audit Details assertion on to the policy.
  60. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events.
      For example: “The request is ${requestbody} and the User Directory is ${smuserdirectory.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:
  61. Continue the process of expanding the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression assertion.
  62. Click and drag the Evaluate JSON Path Expression assertion once again on to the policy.
  63. The Evaluate JSON Path Expression Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “JsonPath”.
    • For Expression field, enter the value as “$.AuthScheme”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “requestBody”.
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.For example: “smauthscheme”
  64. Then press the OK button to save configurations. The policy should look like the following so far:

  65. Expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  66. Click and drag the Add Audit Details assertion on to the policy.
  67. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desired message that will be audited in the Gateway Audit Events.
      For example: “The request is ${requestbody} and the Auth Scheme is ${smauthscheme.results}”
    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
      The policy should look like the following so far:
  68. Next, expand the Policy Logic folder from the Assertion Palette to locate the Set Context Variable assertion.
  69. Click and drag the Set Context Variable assertion onto the policy.
  70. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter “sessionKey” as the value.
    • For Data Type, select from the drop-down options for “Message”.
    • For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”.
    • For the Expression field, enter the value as shown in the screenshot below:

      Note: Creating this context variable will store the session key value as the administrative JWT token needed to utilize the SiteMinder REST APIs. The Administrative Token API provides a single call that receives Basic authentication credentials of a CA Single Sign-On Administrator in the Authorization header. If Basic authentication for the specified administrator account is successful, the API returns a JWT token containing a session ticket.
  71. Then press the OK button to save configurations.
  72. Next, locate the expand the Message Routing folder from the Assertion Palette to locate the Route via HTTP(S) assertion.

  73. Click and drag the Route via HTTP(S) assertion on to the policy.
  74. A window will pop-up to specify the URL that the service will route to. Enter the URL to SiteMinder Policy Server following port 8443 with the following URI – “/ca/api/sso/services/login/v1/token”.

    For example: The URL should look like so in the routing assertion – https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ca/api/sso/services/login/v1/token
  75. Double-click the Route via HTTPS assertion to the SiteMinder Policy Server URL.
    • Ensure the URL field is correct to the SiteMinder Policy Server URL with the URIs needed to obtain the Administrative Token.
    • For the HTTP Method, select the drop-down option and select POST.
    • For the Resource Request, leave the option for <Default Request>.
    • For the Response Destination, enter the value as “sessionKey”.
      Note: This indicates that once the API call is made then the Response will be stored into the context variable, sessionKey.
    • For the Authentication tab, select the radio button for Specify HTTP Credentials. Then the right column of the selected option, enter the User Name and Password.
      Note: The User Name and Password should be the SiteMinder administrator username (the same credentials that an administrator would log into the SiteMinder Administrative User Interface (UI) and its associated password.
  76. Then click the OK button to save configurations. The policy should look like the following:

  77. Next, locate within the Message Routing palette for the Manage Transport Properties/Headers assertion.
  78. Click and drag the Manage Transport Properties/Headers assertion on to the policy.
  79. The Transport Properties/Headers assertion properties window will appear. Configure the following:
    • For Type, ensure the value is set to HTTP Header.
    • For Operation, click the drop-down and select the operation as “Add or Replace”.
    • For Property/Header Name, enter the value as “Content-Type”.
  80. Locate within the Message Validation/Transformation palette for the Validate or Change Content Type assertion.
  81. Double-click the Validate Content Type assertion. We want to ensure that the Content-Type will change to JSON format message. The Content Type properties window will appear. Configure the following:
    • Select the radio button for ‘Change content type’ to change the Content-Type.
    • The field below for ‘New value’, enter the value again as “application/json;charset=UTF-8”.
  82. Locate within the Message Validation/Transformation palette for the Apply JSON Transformation assertion.
  83. The JSON Transformation properties window will appear. Configure the following:
    • Select the drop-down options for Transformation and select “JSON To XML”.
    • Keep the value for Transformation Convention as “Standard”.
    • For Root Tag, enter the value as “rootTag”.
    • Enable the checkbox for Format Output.
    • In the Source and Destination field – for Source, select the radio button for ‘Other Message Variable’ and enter the value as “sessionKey”.
    • In the Source and Destination field – for Destination, select the radio button for Response.
  84. Locate within the Message Routing palette for the Manage Cookie assertion.
  85. The Manage Cookie properties window will appear. Configure the following:
    • For Operation, select from the drop-down options for “Add or Replace”.
    • For Set Attributes – Name, enter the value as “SMSESSION”.
    • For Set Attributes – Value, enter the value as “${siteminder.smcontext.ssotoken}”.
    • Click the OK button to finish configurations.

      Note: The API Gateway has incorporated CA Single-Sign On context variables. The “smcontext” context variable is common to all the CA Single Sign-On assertions. ${ <prefix> .smcontext.ssotoken} = Returns the third party SSO token generated by the Policy Server. This token is used to authenticate a user and can be either returned via a HTTP response or stored in a context variable for subsequent SSO session validation. The token is set only when authentication/authorization is successful. This is essentially what we are setting up in this step.
  86. Expand the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate JSON Path Expression V2 assertion.
  87. Click and drag the Evaluate JSON Path Expression V2 assertion on to the policy.
  88. The Evaluate JSON Path Expression V2 Properties window will appear. Configure the following:
    • For Evaluator, verify the value is “SystemDefault”.
    • For Expression field, enter the value as “$.sessionkey”.
    • Under the Source and Destination tab – for Source column, select ‘Other Message Variable’ radio button option and enter the value as “sessionKey”.Note: The user is indicating that the target message will pull from the context variable sessionKey (this is where the first routing assertion makes the API call to obtain the SiteMinder administrative token and its stored here)
    • Under the Source and Destination tab – for Destination column, enter the desired value name to save the results into as a placeholder.
      For example: “bearerToken”
      Note: This action is indicating that once the JSON request body is pulled from the context variable (sessionKey) that the Evaluate JSON Path Expression will search against the JSON request body for any entries that match the Expression. (i.e. sessionkey) Then exports the matched value into a new context variable defined in Destination – Variable Prefix.
  89. Then press the OK button to save configurations.The policy should look like the following so far:
  90. Next, expand the Policy Logic palette to locate the Set Context Variable assertion.
  91. Click and drag the Set Context Variable assertion on to the policy.
  92. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter the desired value for the Variable Name. For example: “domainRequest”
    • For Data Type, select from the drop-down options for “Message”.
    • For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”.
    • For the Expression field, enter the SmDomain Request value as (listed in the screenshot below):
      Note: This is the request body used from the SiteMinder REST API Documentation for a POST creation of a Domain in SiteMinder.

      You can see for smuserdirectory and smdomain that they do NOT have null values. They have values referencing the context variables of their results pulled from the JSON Expression of each object from the origin request body to the Gateway which are required fields for creating a new Domain in SiteMinder.However, smuserdirectory is referenced by the ID number given to by SiteMinder. So you may in the API testing portion include the User Directory’s ID number as a part of the request to the Gateway or embed the User Directory ID number and do not have to include in the request.For example:“DomainName”: “${smdomain.results}” – From the JSON Expression for DomainName, if the value entered in the request was “Test Domain”. Then “Test Domain” is stored into ${smdomain.results} and will be the value present here in this domainRequest context variable. 

      Note: The use of context variables is resourceful due to the dynamic entries and no present static values are placed in this request body.

  93. Then press the OK button to save configurations.
  94. Next, locate the expand the Message Routing folder from the Assertion Palette to locate the Route via HTTP(S) assertion.
  95. Click and drag the Route via HTTP(S) assertion on to the policy.
  96. A window will pop-up to specify the URL that the service will route to. Enter the URL to the SiteMinder Policy Server following port 8443 with the following URI “/ca/api/sso/services/policy/v1/SmDomains”.
    The Policy Data API allows you to create, read, update, and delete CA Single Sign-On objects in your policy store.

    For example: The URL should look like – https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ca/api/sso/services/policy/v1/SmDomains
  97. Double-click the Route via HTTPS assertion to the SiteMinder URL.
    • Ensure the URL field is correct to the SiteMinder Policy Server:8443 URL with the URIs needed for the Domain.
    • For the HTTP Method, select the drop-down option and select POST.
    • For the Resource Request, select from the drop-down and select the “domainRequest” context variable.
    • For the Authentication tab, keep the radio button selected for None.
    • Go to the Headers tab, enable the checkbox for “Pass through only certain request headers”.
    • Then click the Add button to add a new Header.
    • For the Header Name, enter the value as “Authorization”.
    • Select the radio button for “Customize value” then enter the value as “Bearer ${bearerToken.result}
      Setting this header value captures the value from the Evaluate JSON Path Expression ($.sessionkey) which stored the value from that assertion to a new context variable that we defined earlier called “bearerToken”.Note: Each call to the Policy Data API requires a valid JWT Token obtained from the Administrative Token API as a Bearer Token in the Authorization header. So, the ${bearerToken.result} in this case is the administrative token that was given as a response when making the first request to https://[URLofSiteMinder]:8443/ca/api/sso/services/login/v1/token URL. So, creating this new header will be the Authorization portion that SiteMinder grants for usage of its REST APIs.

  98. Then click the OK button to save configurations.
  99. Next, expand the Policy Logic palette to locate the Set Context Variable assertion.
  100. Click and drag the Set Context Variable assertion on to the policy.
  101. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter the desired value for the Variable Name.
      For example: “agentRequest”
    • For Data Type, select from the drop-down options for “Message”. 
    • For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”. 
    • For the Expression field, enter the SmAgent Request value as (listed in the screenshot below):Note: This is the request body used from the SiteMinder REST API Documentation for a POST creation of an Agent object in SiteMinder.

      You can see for smagent that it does NOT have a null value. Its value referencing the context variables of its results pulled from the JSON Expression of each object from the origin request body to the Gateway which are required fields for creating a new Agent in SiteMinder.
      However, if the SiteMinder Agent is not a typical Web Agent then you will need to create an Agent in the SiteMinder Admin UI reflecting what type of Agent you desire. Then with an API testing tool make a GET request to pull all available Agents and refer to its information. Here we have a typical SiteMinder Web Agent with its own Agent ID (the ID will be DIFFERENT per each company’s built out SiteMinder environment). Its path that defines what type of Agent, the href indicating the full URL to SiteMinder and its Agent ID, and lastly a description.
      For example:“AgentName”: “${smagent.results}” – From the JSON Expression for DomainName, if the value entered in the request was “testagent.com”. Then “testagent.com” is stored into ${smagent.results} and will be the value present here in this agentRequest context variable.
  102. Then press the OK button to save configurations.
  103. Next, locate the expand the Message Routing folder from the Assertion Palette to locate the Route via HTTP(S) assertion.
  104. Click and drag the Route via HTTP(S) assertion on to the policy.
  105. A window will pop-up to specify the URL that the service will route to. Enter the URL to the SiteMinder Policy Server following port 8443 with the following URI “/ca/api/sso/services/policy/v1/SmAgents”.

    For example: The URL should look like – https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ca/api/sso/services/policy/v1/SmAgents
  106. Double-click the Route via HTTPS assertion to the SiteMinder URL.
    • Ensure the URL field is correct to the SiteMinder Policy Server:8443 URL with the URIs needed for the Agent.
    • For the HTTP Method, select the drop-down option and select POST.
    • For the Resource Request, select from the drop-down and select the “agentRequest” context variable.
    • For the Response Destination, leave the option on <Default Response>.
    • For the Authentication tab, keep the radio button selected for None.
    • Go to the Headers tab, enable the checkbox for “Pass through only certain request headers”.
    • Then click the Add button to add a new Header.
    • For the Header Name, enter the value as “Authorization”.
    • Select the radio button for “Customize value” then enter the value as “Bearer ${bearerToken.result}
      Note: Setting this header value captures the value from the Evaluate JSON Path Expression ($.sessionkey) which stored the value from that assertion to a new context variable that we defined earlier called “bearerToken”. The bearerToken in this case is the administrative token that was given as a response when making the first request to https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ca/api/sso/services/login/v1/token URL. So, creating this new header will be the Authorization portion that SiteMinder grants for usage of its REST APIs.
  107. Then click the OK button to save configurations.
  108. Next, expand the Policy Logic palette to locate the Set Context Variable assertion.
  109. Click and drag the Set Context Variable assertion on to the policy.
  110. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter the desired value for the Variable Name. For example: “realmRequest”
    • For Data Type, select from the drop-down options for “Message”.
    • For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”.
    • For the Expression field, enter the SmRealm Request value as (listed in the screenshot below): Note: This is the request body used from the SiteMinder REST API Documentation for a POST creation of a Realm object in SiteMinder.

      You can see for smauthscheme, smrealm, smagent, resourcefilter do NOT have null values. Its values are referencing the context variables of its results pulled from the JSON Expression of each object from the origin request body to the Gateway which are required fields for creating a new Realm in SiteMinder.However, smauthscheme is referenced by the ID number given to by SiteMinder. So you may in the API testing portion include the desired Authentication Scheme’s ID number as a part of the request to the Gateway or embed the Authentication Scheme’s ID number in this context variable and do not have to include in the request to the Gateway.
  111. Then press the OK button to save configurations.
  112. Next, locate the expand the Message Routing folder from the Assertion Palette to locate the Route via HTTP(S) assertion.
  113. Click and drag the Route via HTTP(S) assertion on to the policy.
  114. A window will pop-up to specify the URL that the service will route to. Enter the URL to the SiteMinder Policy Server following port 8443 with the following URI -“/ca/api/sso/services/policy/v1/SmDomains/${smdomain.results}/SmRealms”.
    Note: Here in the URI we are indicating the use of context variables. Again, since the Evaluate JSON Path Expression searches for matches and stores matches into a separate context variable and we are able to view the prefix contexts; this shows that the result of the Domain context variable will be included in the URL.

    For example: The URL should look like – https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ca/api/sso/services/policy/v1/SmDomains/${smdomain.results}/SmRealms
  115. Double-click the Route via HTTPS assertion to the SiteMinder URL.
    • Ensure the URL field is correct to the SiteMinder Policy Server:8443 URL with the URIs needed for the Realm.
    • For the HTTP Method, select the drop-down option and select POST.
    • For the Resource Request, select from the drop-down and select the “realmRequest” context variable.
    • For the Authentication tab, keep the radio button selected for None.
    • Go to the Headers tab, enable the checkbox for “Pass through only certain request headers”.
    • Then click the Add button to add a new Header.
    • For the Header Name, enter the value as “Authorization”.
  116. Then click the OK button to save configurations.
  117. Next, expand the Policy Logic palette to locate the Set Context Variable assertion.
  118. Click and drag the Set Context Variable assertion on to the policy.
  119. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter the desired value for the Variable Name. For example: “ruleRequest”
    • For Data Type, select from the drop-down options for “Message”. 
    • For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”. 
    • For the Expression field, enter the SmRule Request value as (listed in the screenshot below):Note: This is the request body used from the SiteMinder REST API Documentation for a POST creation of a Rule object in SiteMinder.

      You can see for smrule does NOT have a null value. Its value is referencing the context variable of its results pulled from the JSON Expression of each object from the origin request body to the Gateway which are required fields for creating a new Rule in SiteMinder.However, here is where you can define what you want the Rule(s) to be. You can define if it is enabled, the Rule name, may give a description, define the Resource for the Rule (here we have it embedded at asterisk (*)), and the following Web Actions in an array for GET, POST, and PUT.
  120. Then press the OK button to save configurations.
  121. Next, expand the Policy Logic palette to locate the Set Context Variable assertion.
  122. Click and drag the Set Context Variable assertion on to the policy.
  123. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter the desired value for the Variable Name. For example: “idNumber”
    • For Data Type, select from the drop-down options for “String”. 
    • For Content-Type, leave the default value for Content-Type (text/xml; charset=utf-8). 
    • For the Expression field, leave the field blank so it is ready to store information.
  124. Then press the OK button to save configurations.
  125. Next, locate the expand the Message Routing folder from the Assertion Palette to locate the Route via HTTP(S) assertion.
  126. Click and drag the Route via HTTP(S) assertion on to the policy.
  127. A window will pop-up to specify the URL that the service will route to. Enter the URL to the SiteMinder Policy Server following port 8443 with the following URI -“/ ca/api/sso/services/policy/v1/SmDomains/${smdomain.results}/SmRealms/${smrealm.results}/SmRules”.
    Note: Here in the URI we are indicating the use of context variables. Again, since the Evaluate JSON Path Expression searches for matches and stores matches into a separate context variable and we are able to view the prefix contexts; this shows that the result of the Domain, Realm, and Rule context variables will be included in the URL.

    For example: The URL should look like – https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ ca/api/sso/services/policy/v1/SmDomains/${smdomain.results}/SmRealms/${smrealm.results}/SmRules
  128. Double-click the Route via HTTPS assertion to the SiteMinder URL.
    • Ensure the URL field is correct to the SiteMinder Policy Server:8443 URL with the URIs needed for the Rule.
    • For the HTTP Method, select the drop-down option and select POST.
    • For the Resource Request, select from the drop-down and select the “ruleRequest” context variable.
    • For the Authentication tab, keep the radio button selected for None.
    • Go to the Headers tab, enable the checkbox for “Pass through only certain request headers”.
    • Then click the Add button to add a new Header.
    • For the Header Name, enter the value as “Authorization”.
  129. Then click the OK button to save configurations.
  130. Next, locate the expand the Message Validation/Transformation folder from the Assertion Palette to locate the Evaluate Regular Expression assertion.

  131. Click and drag the Evaluate Regular Expression assertion onto the policy.
  132. The Regular Expression Properties window will appear. Configure the following:
    • For Display Name, enter the desire name for the RegExFor example: “ruleId”
    • For Regular Expression field, enter the value as –.\bid[“][:]\s[“][A-Z]+\.[A-Z:]+\[email protected][a-z0-9-]+[“]”
      Note: This expression is capturing the SiteMinder Rule’s ID number.
    • For Source and Destination tab – Source column, select the radio button for “Response”.
    • For Source and Destination tab – Destination column, select the radio button for “Proceed if pattern matches”.
    • For Source and Destination tab – Context Variable field, enter the value as “idNumber”.Note: If the Regular Expression pulls a match then the match result will be stored in the context variable defined.

  133. Then click the OK button to save configurations.
  134. Next, expand the Logging, Auditing, and Alerts folder from the Assertion Palette to locate the Add Audit Details assertion.
  135. Click and drag the Add Audit Details assertion again onto the policy.
  136. The Audit Details Properties window will appear. Configure the following:
    • For the Message field, enter the desire message for the audit. For example: “Rule ID = ${idNumber}”

    • For Category, select the radio button for Audit.
    • For Level, select from the drop-down options for INFO.
  137. Next, expand the Policy Logic palette to locate the Set Context Variable assertion.
  138. Click and drag the Set Context Variable assertion on to the policy.
  139. The Context Variable Properties window will appear. Configure the following:
    • For the Variable Name field, enter the desired value for the Variable Name. For example: “policyRequest”
    • For Data Type, select from the drop-down options for “Message”. 
    • For Content-Type, ensure the value is set for JSON format indicated as “application/json; charset=utf-8”. 
    • For the Expression field, enter the SmPolicy Request value as (listed in the screenshot below):Note: This is the request body used from the SiteMinder REST API Documentation for a POST creation of a Policy object within the Domain in SiteMinder.

      You can see for smpolicy and smuserdirectory do NOT have null values. Its values are referencing the context variable of its results pulled from the JSON Expression of each object from the origin request body to the Gateway which are required fields for creating a new Policy in SiteMinder.Note: smuserdirectory is also present in this request. Remember, you can embed the desired User Directory’s ID in this request or include the ID number in the request to send to the Gateway. However, you can define the authorization for the Users attached to the User Directory in this request. In this case for this policy, we have set the All Users to be authorized against the Policy in the Domain. Also notice the RuleLink section, it is referencing the context variable that was create previously to ensure the Policy knows which Rules/Realms to include as apart of the Policy.
  140. Then press the OK button to save configurations.
  141. Locate and expand the Message Routing folder from the Assertion Palette to find the Route via HTTP(S) assertion.
  142. Click and drag the Route via HTTP(S) assertion on to the policy.
  143. A window will pop-up to specify the URL that the service will route to. Enter the URL to the SiteMinder Policy Server following port 8443 with the following URI – /ca/api/sso/services/policy/v1/SmDomains/${smdomain.results}/SmPolicies”.Note: Here in the URI we are indicating the use of context variables. Again, since the Evaluate JSON Path Expression searches for matches and stores matches into a separate context variable and we are able to view the prefix contexts; this shows that the result of the Domain context variable will be included in the URL.

    For example: The URL should look like – https://[FQDNorIPAddressofSiteMinderPolicyServer]:8443/ca/api/sso/services/policy/v1/SmDomains/${smdomain.results}/SmPolicies
  144. Double-click the Route via HTTPS assertion to the SiteMinder URL.
    • Ensure the URL field is correct to the SiteMinder Policy Server:8443 URL with the URIs needed for the Policy.
    • For the HTTP Method, select the drop-down option and select POST.
    • For the Resource Request, select from the drop-down and select the “policyRequest” context variable.
    • For the Authentication tab, keep the radio button selected for None.
    • Go to the Headers tab, enable the checkbox for “Pass through only certain request headers”.
    • Then click the Add button to add a new Header.
    • For the Header Name, enter the value as “Authorization”.
  145. Then click the OK button to save configurations.
  146. Next, locate within the Message Routing palette for the Manage Transport Properties/Headers assertion.
  147. Click and drag the Manage Transport Properties/Headers assertion on to the policy.
  148. The Transport Properties/Headers assertion properties window will appear. Configure the following:
    • For Type, ensure the value is set to HTTP Header.
    • For Operation, click the drop-down and select the operation as “Add or Replace”.
    • For Property/Header Name, enter the value as “Content-Type”.
    • For Property/Header Value, enter the value as “application/json;charset=UTF-8”.

      Note: The reason we are incorporating this assertion is because we want to ensure that the Response Header is translated into the Content-Type for JSON. Since all SiteMinder REST APIs are in JSON formatting.
  149. Lastly, locate within the Message Validation/Transformation palette for the Validate or Change Content Type assertion.
  150. Double-click the Validate Content Type assertion. The Content Type properties window will appear. Configure the following:
    • Select the radio button for ‘Change content type’ to change the Content-Type.
    • The field below for ‘New value’, enter the value again as “application/json;charset=UTF-8”.
    • Then click the OK button to finish configurations.

      Note: We want to ensure that the Content-Type will change to JSON format message.

Test the API Gateway SiteMinder Policy with an API Testing Tool:

  1. Open an API testing tool client such as Postman.
  2. Generate a new request.
  3. Ensure that the HTTP method for the new Request will be a POST from the drop-down options.
  4. Enter the URL to the API Gateway and the SiteMinder API context URL.
  5. For the Authorization, chose the authentication as Basic Authorization and enter the credentials of the administrator credentials of SiteMinder (same credentials as if the admin user were to log into the SiteMinder Admin UI).
  6. Navigate to the body and select raw for the data to be inputted for the Request.
  7. For the body of the Request, enter the following JSON request:

Note: This request implies the structure that will correlate with enabling the JSON Path Expression assertion. Where the assertion will find the key and once the key matches then will export the value of the key into a context variable.

For example: “DomainName” – this is a JSON Path Expression in the Gateway Policy to search for a match and if presented then take the value of “DomainName” and export into a context variable (i.e. ${smdomain.results}) to be referenced later.

Note: Each object has its own unique ID number. For each object the ID will start with the handle “CA.SM::” then follow with the object type and finally with a base64 format.

UID Example: CA.SM::[email protected]

The request in Postman will look like this for example:

8. Then press Send to send the request to the API Gateway to inherit the Policy that we have created.

Expected Result – 

If the request to the Gateway to execute those transaction was successful, then SiteMinder will response in JSON format of all the data pertaining to each object in SiteMinder.

Example Response:

Verify SiteMinder Objects in the SiteMinder Administrative User Interface (UI):

  1. Login to the SiteMinder Administrative User Interface (UI) through a web browser.
  2. Enter the administrative account credentials for SiteMinder.
  3. Check the following to verify that the request to the Gateway for the SiteMinder API of the SiteMinder objects were successfully created:
    • Infrastructure > Agent > Agents
    • Infrastructure > Domain
    • Domain > User Directories
    • Domain > Realms
    • Domain > Rules
    • Domain > Policy
    • Domain > Policy > Users
    • Domain > Policy > Rules

The user should ensure in the SiteMinder Admin UI that a new Agent was created, a new Domain was created, attached a User Directory to that Domain, a new Realm or Realms were created, an Authentication Scheme attached to the Realm, a new Rule set was created in the Realm, and a Policy was created within the Domain. Within the Policy ensure that the authorization actions for the users in the attached User Directory are assigned as well as the Realms are applied to the Policy.

Summary of Symantec SiteMinder Integration and Automated Creation

Utilizing the SiteMinder REST APIs will provide provisioning of SiteMinder objects. Automation is the key to the future with the use of web services in ways to help provision objects in SiteMinder all with a single click of a request to the API Gateway. Instead of manual inputs in the admin console for creating those objects in SiteMinder. This integration would be beneficial to the business or customer in excelling creations without having to run into mass amounts of cycle time or work time for the business.

Looking for additional help with Symantec SiteMinder integration and the automated creation of SiteMinder objects? ISX Consulting is an elite IAM security firm that offers boundless expertise in a range of cybersecurity and business process services, including Layer7 API Gateway process and Symantec Siteminder management. Take your interoperability to the next level, and contact an ISX consultant today. 

ISXA Step-By-Step Guide to Symantec SiteMinder Integration with Layer7 API Gateway for Automated Creation of SiteMinder Objects

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *