| This section discusses best practices and pitfalls that are related to implementing quality security service provisioning systems. Best practices for service provisioning include having a robust application design, achieving quality of services (such as reliability, availability, and scalability), having an appropriate server sizing, putting the right planning and management in place, and mitigating known security risks and threats. Application Design Adopt a lightweight provisioning solution architecture that avoids heavy data replication from the data store (maintained by the provisioning service targets) to the provisioning system (or Password Synchronizer). A database-centric replication architecture usually brings a relatively large data store overhead and potential data synchronization issues. Cater to rule-based workflow requirements. Rule-based workflow is very useful for handling security service provisioning, including user account password synchronization. It is helpful to provide scripting support (for example, calling a UNIX shell script) to define rule-based work flow. Some software products may have a visual rule-based workflow user interface and drag-and-drop features for defining the work flow sequence. Use standards-based integration protocols (such as JDBC, servlet, JNDI, or SMTP) for accessing resources. Avoid using proprietary application protocols.
Quality of Service Quality of service refers to the service attributes of how reliable, available, and scalable a system is. This section discusses options that support reliability, availability, and scalability when implementing security service provisioning. Use persistent mode for processing service provisioning requests. It increases reliability to persist service provisioning requests using an intermediary so that the service requests can be reprocessed after any server restart or service recovery. For example, service provisioning requests can be written to JMS in persistent mode for better reliability during message delivery or routing. Add availability options. Service availability is essential for service provisioning functionality such as user password reset or password synchronization. Clustering the service provisioning server and enabling session failover for the service provisioning application in the application server provides high availability practices. Add scalability options. When the volume of service provisioning requests or user password synchronization requests increases drastically, scalability becomes a concern. A simple rule of thumb for scaling up service provisioning servers is to deploy three instances of the service provisioning servers with a load balancer (sometimes known as "the rule of three"). When one service provisioning server is down, the other two servers are load balanced and are still in service. Use open standards for interoperability. Interoperability between the service provisioning server and the back-end systems is important. Proprietary middleware or vendor-specific connector technology often requires a system rewrite or upgrade when the underlying operating system or product is upgraded or becomes obsolete. Thus, the use of open standards (such as SPML) or J2EE technology (such as JMS) is a key to interoperability between J2EE-based implementations. Define quality of service. The quality of service (such as system response time) for the security service provisioning system depends on the system response time of the Provisioning Service Targets. It is fairly difficult to define the quality of service (such as a five-second response time) for the security service provisioning system if some of the depending Provisioning Service Targets have unpredictable system response times (such as if one has three seconds, but another has seven seconds). Thus, security architects and administrators may want to customize what key attributes (such as availability) are appropriate for the quality of service measurement. Customize your support strategy. Traditional system support for an IT solution often requires that IT support staff only know the product details, because the software systems have been self-contained and do not usually have many external interfaces. Service provisioning solutions have multiple external interfaces to a variety of back-end systems. The root cause of a service incident may span different back-end systems, which may make troubleshooting and diagnosis very complex. The IT support personnel need to be familiar with the dependency of the external interfaces for further escalation if necessary. Thus, security architects and administrators need to define and adopt a flexible support strategy that can accommodate the complexity of cross-product troubleshooting and the escalation procedures.
Server Sizing Consideration Inappropriate server and application sizing can create considerable impact on the system performance. This is particularly critical when the service provisioning system stores all user profiles and the service configuration for a large number of Provisioning Service Targets. The following tips may be helpful: 1. | Start with a small server sizing estimate. The nature of processing service provisioning requests does not require a heavyweight infrastructure. Thus, a service provisioning server does not usually require a high-end or heavy-duty server (four CPUs with 10 GB of memory). The server sizing can be estimated in the same way the size of an entry-level Directory Server (a single CPU with at least 2GB of memory) is estimated. Security architects and administrators need to consider additional storage and memory requirements (for example, LDAP calls to retrieve user credentials or to update user passwords), depending on the number of user accounts to be processed and the audit log requirements. For example, a storage requirement totaling seven years is fairly common for many companies for auditing or compliance reasons. The Sarbanes-Oxley Act (refer to [SOX1] for details) requires complex auditing reports and analysis for any user password changes. These data mining and reporting functionalities impose additional server memory and storage capacity requirements.
| 2. | Check for the underlying container architecture. Some service provisioning solutions use servlets in a Web container instead of EJBs to implement the service provisioning engine and password synchronization component. Server sizing for a Web container architecture instead of an EJB container architecture is less demanding for hardware and storage requirements. A typical server sizing for a Web container architecture (as in Web servers) is a single CPU with 1 to 2 GB of memory. An EJB container architecture (as in application servers) requires multiple CPUs and additional physical memory.
|
Security Risk Mitigation Data privacy and message replay are two major security risks to service provisioning. Risk mitigation measures that can address these security risks include: 3. | Defining your privacy policy. There are potential privacy issues associated with the service provisioning solution. Each provisioning service target or resource needs to intercept service provisioning requests and may need to disclose user account profiles or information in responses. This unfolds a few privacy issues, such as what authorized or unauthorized disclosure of user account profile should be and what defines a minimal and consistent set of personal data (for example, just user name and ID) across users and systems for service provisioning processing requirements. For example, should the service provisioning system require personal data such as Social Security number or date of birth to provision a new user account? These personal data items are sensitive to data privacy issues and may be easily exploited for unauthorized use in the event that the service provisioning request is hijacked.
| 3. | Adding preventive measures against message replay. Service provisioning requests are easily open to attacks by message replay techniques, such as message insertion, message deletion, and message modification. Use Web services security protection measures such as using timestamps, correlation ID, XML Encryption, and XML Digital Signature (refer to Chapter 11 for details on Web services security patterns) to mitigate the message replay security risk.
|
|
