A Beginner’s Guide to Symantec SiteMinder: Part 1 – How does SiteMinder Work?

This guide is designed to help examine the basics of Symantec SiteMinder and how the components work together to protect online resources and provide a single sign-on experience. The following information will be at a high level to foster a good grasp of the basic concepts before moving on to more specific parts in this beginner’s guide.

The Basics of Symantec SiteMinder

SiteMinder operates based on logging a user into a website and generating a cookie for their browser. SiteMinder will then use that cookie to provide other protected resources with the user’s login information without needing to ask for credentials again.

SiteMinder protects all of its resources using what is referred to as a policy. A policy is essentially an association of a URL and a set of rules and regulations that you set for it.

Note: SiteMinder uses the name “policy” to refer to multiple things, so pay close attention to the verbiage and the images to avoid getting mixed up. This theme exists throughout SiteMinder and its agents as well.

Architecture of Symantec SiteMinder

This section discusses the architecture of SiteMinder and what the different components do, and when you would use some of them. Below is a simple diagram of how the components communicate.

Symantec SiteMinder Components

There are some components that every deployment of SiteMinder will have, and there are others that are used on a case by case basis depending on the requirements of the business. There are other components available that are less commonly used. If you need information on those components, you can find it in the Broadcom documentation

Required Components:

  • Policy Store
  • Key Store
  • Policy Server
  • Admin Interface (Admin UI)
  • Webagents

Optional Components:

  • Access Gateway
  • Session Store

The policy store is the storage location for all of the configurations that you make for agents and policies. It is arguably the most critical component. The policy server cannot operate or even start if there are problems with the policy store.

The key store is the storage location for all of the encryption information that the policy server uses to establish secure communication with the agents that you deploy onto your web resources. Often, you’ll use the policy store as the key store as well. 

The session store is a storage point for user session information after they log in to a SiteMinder protected resource. This store is not necessary unless there are configurations in place that require a persistent session. A persistent session means that when the user logs in, their session info that normally gets stored in a browser cookie now gets stored in the session store as well.

The policy server component acts as the brain for the SiteMinder system. This is the piece that will process all of the logic and make all of the decisions about an authentication attempt based on the information that agents send back about the request. The policy server will compare the info that the agent has with the policy that is written for the resource and agent in question. After comparing the request to the policy, the policy server will instruct the agent on how to handle that request. We will break down this process further in a later section.

The administrative user interface, or Admin UI, is the graphical interface that you use to manage all of the policy objects. It is your main tool for interacting with the policy server and the policy store. All of the changes you make in the Admin UI correlate to modifications on the objects that are stored in the policy store and offer you a simple way to manage user stores as well as simple policy server management like flushing the cache.

Webagents act as a sort of traffic cop for the requests that come through on the servers where they get deployed. You install agents for your specific web or app server and then the agent will start to inspect all of the traffic that comes into that web or app server. It takes the information from that inspection and asks the policy server if there are any policies written for the resource or URL that the request was made for. If the policy server comes and says that it found some policies that match the URL then the agent will ask the user that made that request to authenticate themselves, otherwise the traffic goes right through with no interference.

Access Gateways are a powerful multi-tool that the SiteMinder application can use to provide a single point that manages multiple SiteMinder resources. An Access Gateway is a bundle that you can install that has an integrated and pre-configured Apache web server, Tomcat app server, and a SiteMinder webagent in one single install. The purpose of the Access Gateway is to act as a proxy server for a number of backend web resources that may want to use the Access Gateway as their web tier in front of an application server, or even just a single web access point that forwards or redirects to any number of other web tier components for applications. These applications do not even need to be SiteMinder protected to consume the proxy services. In addition to proxy abilities, the Access Gateway is also configured to be a federation gateway and is commonly used for this purpose.

How Policies Work in Symantec SiteMinder

To explain a policy, we need to look at the structure of a policy. You can break a policy down as follows: domain, realm, rule, and policy. 

The domain defines what user source or sources we are going to reference for authenticating users.

The realm will define what agent or agents this policy applies to and what resource they are protecting. Resources in terms of realms are always the URI value following your domain. For example, if we want to protect the page hostname.domainname.com/home/finances, then our resource would be /home/finances.

Rules are created under, and associated with, a single realm. The rules set under a realm exist to allow slightly more fine grained control over the access to a resource listed in that realm, or to act as logic triggers that the policy server can use to process a response. We will talk about responses in a later part of the guide when we discuss the process of creating a policy in depth.

The actual “policy” portion of a SiteMinder policy is where we specify who is actually allowed to see the resources that we protect, even if they already logged in. We do this by associating the policy we create with one or more of the rules we made for the realm. The users that we designated in the domain portion can always authenticate successfully into a resource, but the policy dictates whether they are authorized to see it or not. An example of this would be an employee home page for a company, employees.company.com/home. Every employee needs to log in when they hit that page and every employee is authorized to see the front page. Now let’s imagine that there are links on the page for each

business unit; one for /HR, one for /accounting, and one for /IT. We don’t want them having access to each other’s applications, so in our policy we designate that only people in the HR subset of employees are authorized to actually see the page behind the /HR resource and everyone else, although properly authenticated already, will be rejected because they were not in the subset of users designated on the policy.

That may be a bit hard to take in at first, so we’ll sum it up in the order that we need to make them.

Domain -> Realm -> Rule -> Policy

  • Domain – Who can authenticate.
  • Realm – What resource is protected and how do they authenticate.
  • Rule – The trigger that fires off the policy.
  • Policy – What set of users in the Domain are authorized to see the page.

How a Policy is Processed in Symantec SiteMinder

Now that we know what goes in a policy, let’s break down how the agent and the policy server actually process a policy.

Every time an agent intercepts traffic coming into the server, it asks 3 questions.

  • Is this resource protected?
  • Is this user authenticated?
  • Is this user authorized?

The first thing the agent does is read the request, grab the URI, and report back to the policy server to ask that first question. Is this resource protected? The policy server will look for any policies with a realm that associates the asking agent with the reported resource. If there is a realm associating the agent and that requested resource, then the policy will answer that question with a “yes.” If the agent receives a yes from the policy server, it will move on to question 2. If the does not receive a yes, then the agent will behave as though the requested page is not protected by SiteMinder and the request will go through to the server as normal.

Once the agent knows that the resource is protected, the agent has to ask, is this user authenticated? It does this by checking for the browser cookie SM_SESSION. If there is a session cookie for that user and the user is in the domain associated to this policy, then the answer to this question is yes and it moves on to the third question. If the answer is no, and the user is not authenticated and the cookie cannot be found, then the agent will look at the realm for the policy for instructions on how to authenticate the user and then provide that prompt to the user. Often this is in the form of a login page, but can be anonymous or multi-factor. After authenticating the user, the agent presents them with a new SM_SESSION cookie and proceeds to question three.

Is this user authorized? The agent will look at the rules associated to the realm that the user is asking for. Using that, it will find the policy object and confirm that the user falls into the subcategory of the domain users. If the user is indeed a part of the subcategory, then they are authorized and allowed to see the page. If the user is not authorized, then the agent will either process a response that lets the user know that, or if there is no error handling then it will be left up to the discretion of the browser to provide the Error 403 page, Not Authorized.

Summary of Symantec SiteMinder Basics

We’ve made it through an entire policy being processed for a requested resource. What does that mean?

It means that we now have a Single Sign-On session with every application that is integrated into our SiteMinder environment (that we’re authorized to see). Using this we’re able to provide users with a simple and convenient method of traversing and using the organizations applications and managing the security of the web access all from a single solution.

Hopefully this introduction to Symantec SiteMinder has been helpful. Stay tuned in for Part 2, where we start looking into and breaking down how to actually operate the SiteMinder system. 

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

ISXA Beginner’s Guide to Symantec SiteMinder: Part 1 – How does SiteMinder Work?

Related Posts

Leave a Reply

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