CA SSO: On-Premise or Cloud? Now you can do both!

 Image courtesy of CA Technologies

Image courtesy of CA Technologies

 

The entire CoreBlox team was excited about the announcement that the latest CA Single Sign-On release (R12.6.02) includes integration with CA Identity Service!  I had a chance to see CA Identity Service in action at CA World last November. As impressive as it was as a standalone solution,  I think everyone knew that it would go to another level once it could work hand in hand with CA SSO. This announcement is a major step forward for CA, as companies that are already running CA SSO can now transition to a true hybrid cloud environment by pairing with CA IDaaS. Got Salesforce? Dropbox? Google G Suite? Office 365? No problem.  Your existing CA SSO users can now seamlessly transition from their on-prem apps to their cloud/SaaS apps with a single click.

Step-By-Step: CA SSO WebAgent Request Flow

 Photo credit: Dean Hochman, via Flickr

Photo credit: Dean Hochman, via Flickr

When a user opens a new browser session and navigates to a CA SSO protected resource, the Agent intercepts the request at the webserver end where the protected resource resides. At the Agent end there are different Managers that each perform different actions. The following describes the flow:

1.     To start, the HighLevelAgent (HLA) passes the request to the Resource Manager. It is the responsibility of the Resource Manager to extract information about the requested resource such as HTTP_Host, Client IP address, Agent Name, URL, Method (Get, Post etc), Cookie Domain. Furthermore, it does some checks such as CSSChecking, BadURLChars, AutoAUthorize URL etc.

2.     Next comes the Session Manager. Since there is no session established yet, the Session Manager will return no action.

3.     At this point the Protection Manager is called. Now the agent, via the Low Level Agent (LLA), makes a TCP/IP connection to the Policy Server. The Policy Server, based on the Agent name and resource URL (already captured by Resource Manager above), is able to identify if the resource is Protected by CA SSO.  This information is captured by the Realm\Rule objects at Policy Server. Once the Policy Server identifies this information, it sends the response back to the Agent via TCP/IP. If the resource is protected, Agent pass on to the next manager.

4.     The Agent calls the Credential Manager.  Since there are no credentials present, the Credential Manager calls the Challenge Manager.

5.     The Challenge Manager, based on the Authentication Scheme selected (this information is captured at the Protection Manager step from the Realm), processes the credential collection mechanism via HTML Form credentials, NTC etc.

6.     At this time the user is presented with a credential collection page (based on the authentication scheme defined).

7.     On supplying the credentials, the Webagent calls the Authentication Manager. The agent again makes a TCP/IP connection to the Policy server via LLA as it cannot make this decision on its own. The Policy Server at this point tries to disambiguate/Authenticate the user based on the User Directories selected for that Domain Object. Once it authenticates the user, it generates a SessionSpec and encrypts it with SessionTicket Key and sends it along with SessionID and other Authentication responses to the Webagent.

8.     The Webagent at this point declares that the user is Authenticated and passes the request on to the Session Manager.

9.     The Session Manager at this point generates the user session, creates a SMSESSION cookie and writes to the user’s browser.

10.  Finally, the Agent calls the Authorization Manager. Since the agent again does not have the capability to make this decision it calls the Policy Server via TCP/IP. The Policy server, based on the ‘Policy’ object definition for that domain, makes the Authorization decision. It then sends the Authorization responses to the Webagent.

11.  At this point,  the Webagent has all the information it needs to make the decision. Now the Webagent passes on the control to the webserver to show the target page to the end user.

 

If the user tries to browse another protected resource using the same browser session, it will have the same flow but a few things will be different such as, the Session Manager at step 2 decodes the SMSESSION cookie already present in the browser and checks if it is a valid cookie (session timeouts etc). Furthermore, the Credential Manager at step 4 uses session information and by-passes the challenge Manager step to perform the authentication. This way single-sign-on is achieved without challenging the user while Authentication/Authorization occurs in the background.

Hopefully you will find the information above useful as you troubleshoot Webagent-related issues.

Hacking CA SSO (SiteMinder) Password Services Redirects

Password Services Logo

CA SSO Password Service redirects work great if you want to use the default forms that ship with the Web Agent. While modifying the "fcc's" is a potential option, how do you take advantage of your existing password change forms? What about ignoring those pesky Active Directory password redirects?  Let's get hacking. There are a couple of settings you can use with Password Services beyond configuring a Password Policy within the Admin UI. The settings must be obvious, right? Well... Keep reading for the scoop.

Hack 1: Changing the Password Services Redirect When no Password Policy is defined, CA SSO redirects to the default Password Services FCC URL. You can override this behavior by setting the NETE_PWSERVICES_REDIRECT environment variable to the relative URL where you want to redirect the user. While the documentation says the path must be relative, I have successfully set it to a fully qualified redirect URL. Give that a shot, but the official means of setting a full qualified URL is in the Password Policy itself.

Password Policy Image
Password Policy Image

Keep in mind that the environment variable is set on the Policy Server(s) and not the Web Agent server(s).

Bonus: Take a look at the path in the Password Policy. If you ever wanted to exclude users based upon a LDAP attribute, you can use a search expression instead of a specific branch.

Hack 2: Disabling Password Services Redirects By default, CA SSO redirects natively disabled Active Directory users to Password Services, even if Password Services is not enabled for the authentication scheme protecting the resource or a Password Policy is not defined. To disable this behavior, set the IgnoreDefaultRedirectOnADnativeDisabled registry entry on the Policy Server(s). Configure the following registry entry:

Name

: IgnoreDefaultRedirectOnADnativeDisabled

Location

: HKEY_LOCAL_MACHINE/SOFTWARE/Wow6432Node/Netegrity/Siteminder/CurrentVersion/Ds/LDAPProvider

Type

: DWORD (32-bit) Value

Values

: 0 (disabled) or 1 (enabled).

Default

: 0. If the registry key is disabled, the default behavior is in effect.

Registry Entry Image
Registry Entry Image

Have Fun Storming the Castle and let us know if you have any other Password Services tricks.