SSOGEN / SiteMinder vs SSOGEN: What Each Product Documents

Compare

SiteMinder vs SSOGEN: What Each Product Documents

SiteMinder vs SSOGEN is a comparison of two ways to protect web applications: SiteMinder places an agent in front of the application that asks a Policy Server for a decision, while SSOGEN is an identity provider with a Web Agent for Apache and Oracle HTTP Server and a Gateway proxy. The table sets out what each documents.

SiteMinder vs SSOGEN is a question for teams that protect web applications with a SiteMinder agent and a Policy Server. Both products put a check in front of the application, so sign-in, authorization and the identity the application receives are handled outside the application.

SSOGEN does this as a complete identity provider. Its Web Agent runs inside Apache or Oracle HTTP Server and protects Oracle E-Business Suite, PeopleSoft and JD Edwards.

The Gateway publishes other web applications, and any application that speaks SAML 2.0 or OpenID Connect connects directly.

The table sets the two side by side, row by row, where we have a SiteMinder statement we can cite. It does not rank the products and says nothing about price or quality.

To plan a move, read the SiteMinder alternative page for inventory and migration order.

Capability table

Last compared 2026-10-09. Vendors change their products, so check the current release of each.

SiteMinder statements come from Broadcom’s archived CA SiteMinder 12.5 and 12.51 documentation and from the SiteMinder 12.8 TechDocs, all read 2026-10-09:

The archived guides cover older releases, and they differ by release, so check the one you run.

Capability SiteMinder (Broadcom documentation, 12.5, 12.51 and 12.8, read 2026-10-09) SSOGEN (own documentation)
Component in front of the application The archived 12.51 guide says the request “is received by the Web Server and intercepted by the CA SiteMinder Web Agent”, which “gathers the user’s credentials and passes them to the Policy Server” (policy overview). The 12.8 guide says: “The Web Agent intercepts user requests for resources and checks with the Policy Server to see if the requested resource is protected” (Web Agents Overview). The Web Agent for Apache 2.4, Apache 2.2 and Oracle HTTP Server. The Gateway App Proxy for applications that cannot host a module. SAML or OpenID Connect where the application supports them.
Who decides The archived guide says the Policy Server “authenticates the user against native user directories, then verifies if the authenticated user is authorized for the requested resource based on rules and policies contained in the Policy Store” (policy overview). SSOGEN is itself an identity provider. Sign-in and authorization are decided in SSOGEN, per registered application.
Policy objects Policies bind users, rules, responses and optional time and IP restrictions. Policy domains group user directories, administrators and realms. Realms identify a group of resources. Rules identify a resource and the actions allowed or denied for it (policy overview); the rules page says rules “can also be used to trigger responses when authentication or authorization events take place” (rules). Assignments, named sign-in policies and rules with conditions such as network zones. SSOGENProtection off, optional or on per location, and a registered application per site.
User directories The archived guide says a policy domain is “a logical grouping of one or more user directories, administrators, and realms” (policy overview). Active Directory or LDAP over LDAPS or StartTLS, local accounts and CSV import. One directory for every protected application, whichever way it connects.
Identity passed to the application “A response is a Policy Server object that determines a reaction to a rule” (policy overview), and user attributes can be specified as response attributes for Web Agent responses (generated user attributes). The 12.8 guide says the web agent places the user name in an HTTP header variable for all requests (12.8); the archived guide adds that the variable is not set when a user does not provide a user name, such as with certificate-based authentication, or when a user name is not known (generated user attributes). Identity sent to app attributes as request headers or cookies. The Web Agent passes the user name the way the application already reads it: unchanged, or in capitals with the legacy values Oracle applications expect.
Importing the other product’s policies Not applicable to this comparison. Each SiteMinder rule maps to a registered application with its own sign-in policy and assignments. Applications move one at a time, and Test shows the headers before cut-over.

Rows appear only where we read a Broadcom source. A missing row was not researched; it does not mean SiteMinder lacks the capability.

SSOGEN also provides three things the table does not compare:

  • Sign-in strength. The sign-in policy sets sign-in strength, including a second factor.
  • SiteMinder as a source. SSOGEN accepts SiteMinder as a SAML 2.0 identity provider (SiteMinder SSO with SSOGEN), so applications move one at a time.
  • One identity provider. The Web Agent runs in Apache and Oracle HTTP Server and signs people in through SSOGEN, so one identity provider serves every protected application.

Two models for the same request

In Broadcom’s model, the agent intercepts the request and the Policy Server checks the rules and policies in the policy store.

Administrators maintain policies, policy domains, realms, rules and responses. A response is how the application learns who the user is, and the unit you inventory is the rule.

In SSOGEN the unit is the registered application:

  1. Register it under Applications, then Web Agent, and give it its client URL.
  2. Pick the attribute that names the person to the application.
  3. Attach a named sign-in policy for strength, and assignments for who may open it.

The Test action lists every value the Web Agent would send for a real person before anyone signs in. That matters when an application depends on the user header a SiteMinder agent set.

The Web Agent is compiled on the server that runs it, as a module in Apache or Oracle HTTP Server.

The person signs in to SSOGEN against Active Directory, LDAP or a local account, and the agent passes the result to the application. Applications behind other web servers connect through the Gateway, SAML or OpenID Connect.

Where SiteMinder fits

  • User header. Your applications already read the user header from a SiteMinder agent, and you have no reason to change them.
  • Policy store. Your rules live in a policy store with many realms and responses, and you prefer not to map them to registered applications.
  • Directory. Your user data sits in a directory you do not want to connect to another system.
  • Other web servers. The application sits behind a web server other than Apache or Oracle HTTP Server, and you prefer not to add a proxy or switch the application to SAML or OpenID Connect.

During a move, SSOGEN accepts SiteMinder as a SAML 2.0 identity provider, so people sign in through it while applications move one at a time.

Design and test the mixed setup before cut-over.

When SSOGEN fits

  • One product. You want the identity provider, MFA policy and the web check in one product.
  • Oracle applications. Your Oracle E-Business Suite, PeopleSoft or JD Edwards site sits behind Apache or Oracle HTTP Server and you want the check inside it. The Web Agent sends the legacy Oracle headers those products read. See Oracle EBS SSO and PeopleSoft SSO.
  • Choice per application. You want the web check, a Gateway proxy and SAML or OpenID Connect as ways to connect each application, chosen one at a time. The guide to choosing how to connect an application shows how.

SSOGEN has protected these applications in production since 2016. For the full product, see single sign-on software.

Questions people ask

Does an application that reads the SiteMinder user header need code changes?

No, in most cases. The Web Agent passes the user name unchanged, the way the application already reads it. Match the attribute to the value the application reads today, and confirm it with Test before you cut over.

Does SSOGEN import SiteMinder policies?

Policies move per application. You register each application in SSOGEN and set its sign-in policy and assignments from the matching SiteMinder rule.

How does a move from SiteMinder to SSOGEN work?

SSOGEN registers applications one at a time and accepts SiteMinder as an upstream SAML provider. Design the mixed setup and test it before cut-over.

Which costs less, SiteMinder or SSOGEN?

This page makes no pricing claim. We read no price list from either vendor. Cost depends on licensing, hosting, and how many applications and users you protect. Ask each vendor to quote the same list of applications, and include the work of mapping SiteMinder rules to SSOGEN applications.

Sources, all read 2026-10-09: Broadcom CA SiteMinder 12.5 and 12.51 archived guides and SiteMinder 12.8 TechDocs (linked above).

About this comparison. SSOGEN Corporation prepared this page from Broadcom’s public documentation and web pages, last read on 2026-10-09.

We took care to be accurate, but products, plans and prices change, and we may have misread or missed something, so some statements may be wrong or out of date. This page is for general information only and comes without any warranty.

SSOGEN is not responsible for errors, omissions or decisions made from it. Check the vendor’s own pages and test the products yourself before you decide. If you see a mistake, tell us and we will correct it.

SiteMinder, CA SiteMinder, Broadcom, Oracle E-Business Suite, PeopleSoft, JD Edwards, Oracle HTTP Server, Apache and Active Directory are trademarks of their respective owners. SSOGEN is an Oracle partner, but Oracle has not reviewed or endorsed this page.

Except for Oracle, the owners named are not affiliated with, endorsed by or sponsored by SSOGEN.