We installed agents on our IIS and Apache Web servers, which we set up to communicate with SiteMinder's central policy service. All policies, agents and authentication schemes are configurable on the policy service. When a user attempts to access a protected resource, the agent intercepts the request and presents the user with a credentials form. These credentials are passed to the policy service, which verifies them against the identity store and then grants or denies access based on the policies in place. When a user is granted access to the resource, SiteMinder can pass user profile information, through HTTP headers, to the secured Web application to enable the customization of content.
SiteMinder is controlled through a Web interface, which launches a Java applet. At first, we were comforted by the interface's similarity to the MMC (Microsoft Management Console). However, we soon realized that we needed to study Netegrity's security model and learn a new vocabulary--with terms like realms, policy domains and identity environments--before we could configure anything. Although this isn't necessarily a bad thing given the complexity of the technology, Netegrity's interface was the most difficult to manage. For example, though the configuration interface has a help button, it didn't always lead us to relevant information, forcing us to search in more than one place before we found what we needed.
Using SiteMinder, an administrator can configure one or more Policy Domains. For our tests, we created a single domain, which contained our realms, policies and administrators. A realm is a group of related resources that must be secured. We configured a realm with several folders on an IIS 6.0 Web server as the resources to be protected and assigned an "authentication scheme" using Active Directory as the identity data repository for authentication.
SiteMinder supports several authentication schemes, including HTML forms-based authentication, digital certificates, token authentication and custom-built authentication libraries. We defined a numeric "protection value" from 0 to 1,000 for each authentication scheme. Thus, different realms within our domain could require different protection levels. Users logging in with basic form-based authentication would have single sign-on to all realms of equal or lower protection levels, but might have to reauthenticate using a token if they wanted to access a realm with a higher protection level.
Within a realm, we could set up rules, responses and policies. A rule indicates which actions are permitted for a given resource; responses define the action that should be taken when a rule is triggered; and policies tie rules and responses together. In addition, policies could be used to place time- or IP-address-based restrictions on the resource. We were happy to see that SiteMinder supports multiple user stores (directories or relational databases) and lets administrators specify the order in which they are to be searched when a user logs in. Finally, with its latest releases, Netegrity (which is actively involved in the Liberty Alliance) supports both inbound and outbound FIM.
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
