Skip navigation
All People > SungHoon_Kim > Sung Hoon Kim's Blog > 2015 > November > 27

I wrote this article 2 years ago and I am moving it here from Integration - SM + SOI + EEM






SOI 3.0 Installer shows the following components to install

Install them in the listed order. Connectors are optional.






Java runtime (required by EEM installation) : JRE 1.6.0_05 (32bit)



CA Embedded Entitlements Manager (EEM)



CA Service Operations Insight



CA Service Operations Insight - Integration Services



CA Service Operations Insight - Sample Connector



CA Service Operations Insight - Domain Connector





1. JRE 1.6.0_05                   : 32bit, C:\Program Files (x86)\Java\jre1.6.0_05

                                                   Installed from SOI 3.0 installation

2. EEM                                  : 32bit, C:\Program Files (x86)\SC\

                                                   Installs CA Directory (32bit, C:\Program Files (x86)\CA\Directory)


                                                   C:\Program Files (x86)\CA\SharedComponents\Embedded IAM

                Integrated with SM. (Follow EEM documentation of  SM integration)

                Can view SM user directory list if correct values are entered.


                Check the following log for any error if this does not connect to SM.

                C:\Program Files (x86)\CA\SharedComponents\iTechnology\eiamsm.log

                Or try restarting dxserver and iGateway service.


3. SOI 3.0                             : 32bit, C:\Program Files (x86)\CA\SOI

                Service Assurance Administrator Credential:



                As EEM is now integrated with  SM, you need to configure EEM.

                Logon to SOI application SSA-SOI as Eiam/password


Goto "Manage Identities" and click "Go" button.



Click on the user(in my case it is "Sung Hoon Kim"), click "Add Application User Details"!!!

make  sure user is in adequate group and save.


You can logout and login to SOI using the SM users.


console will  also show your username





DB Admin Credential


                Database Name: SAMStore


4. MSSQL 2008 R2



5. Adobe Flash  Player


6. Apache 2.2.17 installed as reverse proxy


#============ Added for SOI Integration ==============#


ProxyRequests off

ProxyPreserveHost on



<Location /sam>






<Location /sam/admin>





<Location /sam/debug>






                and you get access to the backend SOI


                some additional proxy is setup for troubleshooting




7. SiteMinder Web  Agent

                As the web server is 32bit, I installed R12.51CR1 Web Agent.

                Agent Configuration Wizard detects the apache web server successfully.

                Configured to protect /sam/ui/(normal agent) and /iamt.html(4.x agent)

                Authenticates and authorizes users from "CA Directory", which is selected in the

                EEM side configuration

                Please follow the EEM document for SM side configuration.


                /sam/ui/ is protected by HTML Authentication Scheme to make it easier to

                differentiate whether the login challenge is from SiteMinder or SOI.



VERY IMPORTANT: Apache Proxy should proxy "/sam" to backend SOI.

But WebAgent must not protect "/sam", it should protect "/sam/ui/"

Otherwise, you will get multiple unexpected challenges and get exception when accessing "console".


1st challenge (in this  sample, I used Basic Auth for easier view)


2nd challenge


3rd challenge










Applied SOI 3.1

SOI 3.1 console requires JRE 1.6.0_25+ so existing JRE1.6.0_05 will not work.

Workaround is, login from client that has 1.6.0_25+.

Or, if you need to login from SOI machine, you can install 1.6.0_25+ on SOI machine.

Note: DO NOT UNINSTALL existing JRE 1.6.0_05 because EEM will not display the SM integration and will fail to connect to SiteMinder Policy Server.


VERY IMPORTANT: You MUST have at least SOI 3.1 to SSO with SiteMinder. 3.0 does not recognize SMSESSION cookie so the SSO will not work.


Steps to upgrade

  1. 1. Shutdown all SOI services.

C:\Program Files (x86)\CA\SOI\jsw\bin> SAM_Services.cmd stop


  1. 2. Run the SOI 3.1 installer


                Select "Do not start services", this can be done manually after upgrade.


  1. 3. Install JRE 1.6.0_25+ (32bit)

I installed 1.6.0_45 (32bit).

                Do not uninstall the previous JRE 1.6.0_05 (32bit) from this maching as it is

                required by the EEM. SM integration will break if you uninstall JRE 1.6.0_05

                In case if you did, you must update the "C:\Program Files (x86)\CA\SharedComponents\iTechnology\igateway.conf" file, locate <JVMSettings>.


If your JRE is not 1.6.0_25+, SOI console will fail to load and throw exception.

If you will not logon to SOI from this machine, you can skip this step.

You can also install 1.7.x (32bit) on client machine that you will be logging on to SOI from, I tested and worked. But it is always a best practise to match the major version required.



  1. 4. Startup SOI services.

C:\Program Files (x86)\CA\SOI\jsw\bin> SAM_Services.cmd start


  1. 5. Test logging on to SOI using SiteMinder user

If this fails, the upgrade is not successful.

                If the upgrade is deemed failure, you can uninstall 3.1.


  1. 6. Uninstall 3.1 if the upgrade failed.

cd "C:\Program Files (x86)\CA\SOI\Patches"

You will find "Uninstall_<Patch Name>" folder

cd "Uninstall_SOIPatch_RO56291"

run "Uninstall_RO56291.exe"



After posting this to the communities, yuhung asked if IWA can be used for authentication.

SiteMinder picks up username as "Domain\UserID" thus no matching user will be found from SOI.


Option is to use a Solution Module called "SmOverrideAuth" which will use "UserID" and strip-off the Domain from IWA.

Or, customer can develop a custom authentication module to do the same.

This is something I like to do once in a while. It takes long time to setup everything but to me it is a hobby. It is like putting zigsaw puzzles.




Following configuration will be setup.


01. Basic setup - Create application and protect using Forms Authentication.

     - Service configuration

     - Startup/Shutdown scripts

     - Logging

     - Basic Concepts

02. Standard Authentication Schemes

     - Basic Concepts

     - Basic

     - HTML Forms

     - HTML using UID and EMAIL

     - Basic over SSL

03. Certificate Authentication Schemes

     - X.509 Certificate Only

     - X.509 Certificate or Basic

     - X.509 Certificate and Basic

     - X.509 Certificate or Form

     - X.509 Certificate and Form

04. Windows Authentication Scheme

05. OAuth Authentication Scheme

06. Cookie Provider

07. Directory Mapping

08. Password Services

09. Impersonation

10. Session Assurance

11. SAML 2.0 Partnership Federation - SSO

12. SAML 2.0 Partnership Federation - SLO

13. SAML 2.0 Partnership Federation - RelayState

14. SAML 2.0 Partnership Federation - Negative Assertion

15. SAML 1.x Partnership Federation

16. Audit Log import

17. Generating Reports

18. SiteMinder Test Tool

19. Global Delivery Modules

20. Troubleshooting



01. Basic setup - Create application and protect using Forms Authentication.

     - Basic Concepts


This is continuing from Part 1 where we were creating basic objects to protect a resource.


Next is creating a Domain.

Navigate to "AdminUI ==> Policies ==> Domain ==> Domains" and click on "Create Domain".

Enter the required field.


Name: "www.sso.lab"

This is just a name, it does not need to reflect your FQHN of your web server.

You can just name it "Test1" as well.

But to me it is easier to use the FQHN.


Now, you can see that the first thing you do with this Domain is to link a User Directory.

That is the reason why you must have a User Directory configured first.


Click on "Add/Remove" under User Directories.

Select "SSO LAB Domain Users" from the left pane and move it to the right pane by clicking on the "arrow" button and click "OK".


Then click on "Realms" tab and click on "Create Realm" button.

Enter required Fields.

Name : Basic Realm

Agent: agent.iis

Resource Filter: /basic/

Authentication Scheme: Basic

Scroll down and click "Create" for Rules.

Enter required fields.

Name: Access Basic

Resource: *

Scroll down and select Action: Get and Post

Then click "OK

Click on "Policies" tab and click "Create".


Entered the required fields.


Name: Basic Policy


Then click on the "Users" tab.

In general, if you click on "Add Members" it will present you with a list where you can choose from.

But if it does not give you the desired list, then you can enter manually by clicking on "Add Entry".


I choose, "Validate DN" because I just want to check if the user is found to be within this DN.

Click "OK" and click on "Rules" tab.

As the Rule is already created, click on "Add Rule".

You will be presented with a list to choose from.

Check "Basic Realm" and click "OK".

Click "OK" and you will.back at "Policies". Click "Submit"

This is how you protect a resource using "Domain" type


What you configured is:


You created a User directory that contains user who you want to grant access.

Then you created an Authentication Scheme, how the users will be submitting their credentials to prove their identity.

Then you created a Domain and linked the User directory.

You created a Realm for "/basic/" URI to protect it.

Then you linked the Authentication Scheme to the Realm so when users acess /basic/ they will be prompted with Basic Authentication.

In the same Realm, you created Rules for "GET" and "POST" Method/Action.

This means requests that are submitted to /basic/ Realm are evaluated for authorization only for the GET and POST requests. Other requests are all rejected.

You have created a Policy to link those Rules and added "CN=Users,DC=SSO,DC=LAB" for authorization.

What this means is that, if the user is found to be located within this "CN=Users,DC=SSO,DC=LAB", they will be authorized. Others will be rejected.


So, in simple terms, you are creating all these to "Authorize" the user for resources.

Now, if you access "http://www.sso.lab/basic/" then you will get challenged as below.

From the Basic prompt, you can see it is saying "The server reports that it is from Basic Realm".

This shows it is from SiteMinder and not the web server because it is saying the resource is "Basic Realm" which is the Realm Name we entered.


Let's login as "smuser"


You can see above that "smuser" is logged on as the "USERNAME" shows "smuser".

You can also find "SMSESSION" cookie.

If you scroll down, you can also see the user is accessing "Basic Realm".

The User Directory is "SSO LAB Domain Users".

UserDN is "CN=smuser,CN=Users,DC=sso,DC=lab".


Now, access "http://www.sso.lab/logout/" which in previous configuration we have defined "/logout/" as "LogoffURI".

You can see "USERNAME" no longer shows "smuser" and the SMSESSION cookie has value of "LOGGEDOFF".

You have successfully logged out.

If you go to "http://www.sso.lab/basic/" you will be prompted to enter user credential again.


Now, I am going to delete all the configuration and show you how to create the same using "Application" type.

To delete all the configuration, goto "AdminUI ==> Policies ==> Domain ==> Domains".

Select "www.sso.lab" and click on the "X" button at the right end.

This will delete everything but not the "User Directory" and "Authentication Scheme" because they are stand-alone objects and not a child object belonging to a domain. They are only referenced objects.


Now, let's perform the same thing using "Application".

Goto "AdminUI ==> Policies ==> Application ==> Applications" and click "Create Application"


You should be familiar with all the information displayed here.

Enter the required fields.


Name: www.sso.lab

Component Name: Basic Realm

Agent: agent.iis

Resource Filter: /basic/

Authentication Scheme: Basic

User Directory: SSO LAB Domain Users.


Then navigate to "Resources" tab and click "Create".

Enter required fields.

Name: Access Basic

Action: Get and Post

Then navigate to "Roles" tab and click "Create Role".


Scroll down to "Advanced ==> User Expression" and enter the following.



In general, SiteMinder will list all the groups and OU and O for you to choose from.

But this "CN=Users" is a unique use case because it is a user container but is not using OU.


So, that is the reason why it was not listed when you were trying to create a Policy in the Domain.

You are faced with the same problem here as well.


For this specific use case, or any similar special conditions, you can enter the expression manually as above.


That that expression means is, if the user is "AT" the "CN=Users,DC=sso,DC=lab" based on the UserDN, then the user matches this role.

This "AT" condition means you must be exactly at the "CN=Users", not further below.

If the UserDN is "CN=User1,OU=ABC,CN=Users,DC=sso,DC=lab" then the user does not match this role. <== You must remember this!


Click on the "Validate" button to ensure there is no typo error.

Navigate to "Policies" tab. Check the "Basic Role" for "Access Basic" Resource and then click "Submit"


Now you have protected /basic/ using Application mode.

Goto "http://www.sso.lab/basic/" and logon as smuser.





You can see all the information is the same as when you protected this resource using Domain or Application.


I hope this gave you a good comparison of both.

They are the same, just slight difference as Role is introduced.


I will not delete this Application. I will be adding more Components(Realms) to this Application.

Next article will be creating Authentication Schemes.


Stay tuned!!!


This concludes "Configuring an ALL-IN-ONE VM Image - Part 2"