Symantec Access Management

The zip file has been copied to github.com located at: https://github.com/tc09-brcm-social/smCurl

To All,

You are invited to help contribute to this effort. Please add your comments/inputs for all to see and discuss. With your participation, I am hoping to have an official github presence for this work in the long run. Attached is a zip file contains the framework as it is. It also contains the .git structure so that you can start forking your own branches as well.

This framework is a SiteMinder implementation based on my article at the API academy site. I am also using it to create another similar framework for "CA Directory."

DevOps: REST API Execution Through Bash Shell Scripting
DevOps: REST API Execution Through Bash Shell Scripting II
DevOps: REST API Execution Through Bash Shell Scripting III

To get you started, you need to download the jq 1.5, jq 1.6 seems to work w/o issues too, from https://stedolan.github.io/jq/download/ and store it as jq or jq.exe if it is on Windows platform. If you are on Windows, you also to install the git bundle for Windows at  https://git-scm.com/download. This framework has been tested on both the "Git Bash" of Windows and the common Linux. There is a simple README.md on the home directory once you have unzipped it. The jq or jq.exe is assumed to be on the home directory as well.Then you will need to copy the authn.sample to authn to create your own working copy. You need

• SiteMinder AdminUI machine name and port number, standard port 8443 but needs not to be. (SiteMinder 12.7 and later)
• A Legacy SiteMinder ID/Password with appropriate privileges
• Create a utils/env.shlib file using the utils/env.shlib.sample.
• Modify your env.shlib for your Admin UI machine name and port number, and ID/password.
• Run
  bash utils/makeauthn.sh to create an "authn".
• Run
  bash isOK.sh
  to confirm that it is working.
• You can then delete your utils/env.shlib file. Your ID and Password to the AdminUI is base64 encoded in the authn file. So, you need to guard it carefully.

Then you can start exploring. There is an examples subdirectory you can look around. This framework assumes all commands are issued from its home directory. For examples,

bash SmAgentConfigs/list.sh

would list out all the existing Agent Config Objects.

Structures

At the top level of the unzipped download, you are seeing a number of familiar subdirectory names. Most of them represents SiteMinder RestAPI for each object type we have tested. You would probably notice that the list is not complete and that means none of the unlisted objects has not yet to be fully tested. For the core tools, they are designed to run at the top level. For example, we have mentioned the "bash utils/makeauthn.sh", "bash isOK.sh", and "bash SmAgentConfigs.sh". For the included examples, they are designed to run at each of the particular subdirectory. For examples, you can do

cd examples/app1
bash make.sh

to try out the app1 example that assume the existence of a SiteMinder user directory and then create other necessary objects to construct a set of SiteMinder policy. The make.sh script actually changes directory to the top level when invoking any of the core tools. 

Core Files and Concepts

There are the create.sh, read.sh, update.sh, and delete.sh that exist under most of the SiteMinder object types. They do as the names suggest. There are also maketemp.sh's that take an existing object and make a simple template from it. A template is actually a bash script one could modify to further customize its behavior. The output of a template is a JSON payload that is usually fed into create.sh in order to create a new object. There are also cleanse.sh's that are meant to clean up the JSON representation of an existing object and make it suitable to create or update another object. You may have guessed, maketemp.sh's actually invoke the cleanse.sh's when preparing a simple template script.

Develop Own Scripts

When creating your own devOp scripts, you are encouraged to first create a subdirectory under projects. For example, for a testing project, you may have a subdirectory of projects/testing. Under there you can then develop your own bash scripts and other supporting files. With this structure, you can use other scripts under the examples subdirectory as references.