I have few question related to SDK generated SmHost file. i.e., SmHost file generated by smreghost.BAT or smreghost.SH scripts.
- I guess, it is possible to generate SmHost file on one machine (using SDK), and use it on other machine. However, I hear some concerns about it not being usable on Solaris. Can anyone give me the justification about why it is not only portable on Solaris ?
- Is it Okay if I generate 100 different SmHost files using SDK, and put one each in 100 different Web Agents, instead of specifically configuring the agent ?
how do you plan to handle trusted hosts?
This is neither recommended nor supported.
The main problem here is the shared secret that is created for the trusted host.
On all non-Windows platforms, the agent code used to encrypt and decrypt the shared secret uses a key that is derived from a hard coded value combined with the results of calling gethostid() on the platform in question. gethostid() is a standard C Library function that returns a 32-bit long value.
Different UNIX system implements this function differently. For e.g Linux, AIX and solaris , the system implementation for the gethostid() C library function is not the same.
As such, SiteMinder web agent might not be able to decrypt the shared secret generated in one UNIX system when moved to other system.
Not only that, if the host ID of the same system changes (due to change in IP, hostname etc ) , the webagent will not be able to decrypt the shared secret which was originally generated on the same system, in which case you need to re-register the trusted host.
Hope this helps.
Thanks for detailed insight Ujwol.
So, is it that same with SmRegHost.BAT, the sdk version of it ?
I understand that the SmHost from OOTB version of smreghost (.EXE) doesn't work on cross platforms. However, it might work within Windows Policy Server(s).
I have verified that the SmHost generated from BAT file using com.ca.siteminder.sdk.agentapi.SmRegHost on a Windows machine working on RHEL 6. Both Custom and OOTB agents were able to load that. However, I couldn't verify that on Solaris.
I don't think smreghost.bat or smreghost.sh or smreghost.exe will make any difference as all of them should eventually be calling the same API for registering the trusted host.
java -classpath "$SM_SMREGHOST_CLASSPATH" com.ca.siteminder.sdk.agentapi.SmRegHost $*
java -classpath "%SM_SMREGHOST_CLASSPATH%" com.ca.siteminder.sdk.agentapi.SmRegHost %*
As you can see above, they are just different client interface for calling the same internal API.