Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Eliminating Ad Hoc Security Strategies

When new applications are deployed without a common identity infrastructure, security decisions are often made in an ad hoc manner by developers and system administrators. Line-of-business managers cannot ensure that the right people see the right content at the right time. Managers must enforce security policies centrally and apply them locally. Security policies define how users are identified or authenticated, and also which users are authorized to access specific information.

Some services or transactions require stronger forms of authentication than others. For some applications, a name and password might be sufficient. Other applications, for example, those that enable high-value financial transactions, can require increased levels of security. These stronger levels of security can be in the form of a digital certificate and personal identification number (PIN), depending on the information and transactions involved.

Authorization to view certain uniform resource locators (URLs) should be restricted to different sets of users based on the users roles. When roles change, changes to privileges should be propagated across all systems. For example, when an employee changes departments or leaves the company, information about that user should be modified or deleted across all accounts immediately. Inconsistent processes for account deactivation is one of the major security risks that enterprises face every day. When you develop applications with your own individual security and access controls, OpenSSO Enterprise provides a centralized security policy and infrastructure to mitigate the risks from both internal users and external threats.