|
| Sun ONE Directory Server 5.2 Deployment Guide |
Chapter 9 Banking Deployment Scenario
Business Challenge
ExampleBank is an international bank which wishes to provide its customers and employees with e-banking and phone banking facilities. Customers may, for example, want to check their bank account balance, perform intrabank and interbank money transfers, check investment portfolios, set up meetings with bank managers, access the bank's online news service and change profile information, while bank employees may want to login to work from home, perform lookups on the bank's phone book, change profile information or perform bank transactions for customers using the bank's phone banking service. The business challenge for ExampleBank is to allow its users, customers and employees alike, access to their range of banking services in a way that guarantees:
- uncompromised security,
- good performance,
- scalability,
- and manageability.
To rise to this business challenge, ExampleBank has deployed Sun ONE Directory Server 5.2 as the cornerstone of its banking deployment. Directory Server holds all of ExampleBank's user authentication and profile data which is used each time a user authenticates to the bank's online system whether it be via a portal or over the phone. The following deployment scenario details how ExampleBank has implemented Directory Server to achieve their e-banking and phone banking business objectives and is divided into the following sections:
Deployment Context and Replication Topology
Deployment Context
ExampleBank's deployment needs to be able to cater for both the e-banking and phone banking services and ensure that authentication to both services is secure, manageable, swift and scalable. ExampleBank uses the same stack of products to cater for both types of access which we examine a little closer in the following paragraphs.
To access the e-banking facilities ExampleBank users use amongst other things, Sun ONE Portal Server. The portal runs over Sun ONE Web Servers coupled with the Sun ONE Identity Server which offers ExampleBank the single sign-on solution it needs for login manageability. ExampleBank has placed Sun ONE Directory Proxy Server next in line in the deployment stack, as the Directory Proxy Server, with its ability to manage referrals to chosen servers caters for Directory Server's operational flow load distribution and transparent failover needs. At the bottom of the deployment stack sits Directory Server, which holds the user profile and authentication data necessary to conduct banking business.
As regards access to the phone banking facilities ExampleBank users phone a given number and enter their account number followed by their phone banking pin number. A special phone banking authentication module contacts Directory Server to try to find the account number, then verifies if the pin number is correct, and if it is correct, forwards the call to a member of the phone banking team.
ExampleBank's banking deployment stack is illustrated in Figure 9-1:
Figure 9-1 ExampleBank's Banking Deployment Stack
Replication Topology
This section outlines ExampleBank's replication strategy and is divided into the following parts:
Replication Topology Overview
ExampleBank has two major data centers, one in New York and the other in Paris. Because it is essential that services remain accessible 24 hours a day and that local write failover needs be catered for, the replication design choice is to have a pair of masters in each data center. This 4-way master replication topology across two continents in ExampleBank's deployment is made possible by the new 4-way Multi-Master Replication (MMR) over WAN possibilities offered by Sun ONE Directory Server 5.2. Hubs have also been included in the replication topology to facilitate load distribution, and the four consumers in each data center allow this topology to scale for read (lookup) operations. ExampleBank's replication topology for its two, cross-continent data center deployment, is illustrated in Figure 9-2:
Figure 9-2 Example Bank's Two Data Center Replication Topology
Figure 9-2 shows the replication agreements which are enabled by default, between masters and hubs, and hubs and consumers, in addition to two recovery replication agreements between masters 1 and 3 and masters 2 and 4, that could be enabled should a master go offline. Sun ONE Directory Server 5.2 allows you to configure replication agreements and then enable or disable them as and when you need to, which offers a welcome degree of topology flexibility. This not only allows you to prepare for recovery scenarios, but, should you wish to do so, also allows you to optimize network usage and minimize the number of modifications actually being sent at any given time.
Note We recommend the use of multiple WAN connections for the inter-data center links to maintain optimal availability.
Failure and Recovery Scenarios
Any number of failures can occur which compromise your deployment, be they related to network links, the Directory Server process (slapd), hardware, replication failure or an overburden on the system due to an excess of read or write operations. It is vital that your replication topology is configured in such a way as to provide the necessary recovery solutions.
In the event of one master going offline, you would simply enable the appropriate recovery replication agreement (which you would already have configured but left disabled) as indicated in Figure 9-2. However, should two masters go offline in the same data center, then you have a number of options open to you. One recovery solution might be to enable a previously configured replication agreement between one of the masters in the unaffected data center and one of the hubs in the impacted data center. Another recovery solution might be to take advantage of Sun ONE Directory Server 5.2's online replica promotion and demotion feature, to promote a hub in the impacted data center to master to provide local write coverage until the impacted masters are brought back online. For further information related to sample replication topologies, failure recovery, and backup strategies see Chapter 10 "Architectural Strategies". For further procedural information related to replication see the Managing Replication chapter in the Sun ONE Directory Server Administration Guide.
Performance Requirements
Performance is extremely important for ExampleBank as the viability of its e-banking and telephone banking offer depends largely on the rapidity of its operations. In addition to good performance, ExampleBank needs the foundation of its online banking stack to be scalable, as its expected annual growth rate stands at 6%. Directory Server caters for both of these requirements.
This section outlines the performance requirements of ExampleBank and is divided into the following subsections:
User Demands
ExampleBank's current user base is 10 million users, of which 10, 000 are employees. The employee and customer user requirements are described in Table 9-1. It is on the basis of these requirements that ExampleBank will calculate the number of writes and reads per second that its online banking stack will have to manage.
The transactions described in the preceeding table translate into LDAP operations as indicated in Table 9-2:
With this in mind, we can conclude that ExampleBank will need to be able to sustain the following in terms of search, bind and modify operations:
- 687 search operations
- 197 bind operations
- 98 modify operations
Hardware Guidelines
To give you a basic idea of hardware, for this type of deployment, which could be termed as a medium to large-scale deployment, we suggest the following machine type comprising:
- 8 CPUs,
- 32 to 64 GB RAM,
- 3 disk arrays configured as RAID, 655 GB, with for example:
- database on first array
- transaction logs on second array
- changelog, access, and error logs on third array
Schema, Data, and Directory Information Tree Design
This section examines ExampleBank's schema, data, and directory information tree design in more detail and is divided into the following subsections:
- Schema
- Data
- Directory Information Tree
Note The schema and Directory Information Tree provided in this section are examples of what you may want to implement and do not constitute an exhaustive or definitive list. Some of the object classes and attributes are required by Sun ONE Identity Server and Sun ONE Portal Server. Refer to the Sun ONE Identity Server and Sun ONE Portal Server documentation for more information.
Schema
ExampleBank needs schema which describes its user profiles, e-banking services, and phone banking services. This section describes the schema, and is divided into two subsections:
Attributes
ExampleBank only distinguishes between customers and employees at an attribute level using the ebStatus attribute.The attributes relative to user profiles, banking services and additional portfolio management banking services are listed below in the following two tables.
Table 9-3 lists the basic user profile attributes:
In addition to ExampleBank's user profile attributes, the attributes presented in Table 9-4 specify whether ExampleBank's services are enabled for a given user.
Object Classes
The entries in the directory inherit from the inetOrgPerson object class and then the ebPerson object class. ExampleBank uses the object classes presented in the following tables:
Data
Based on the schema we have just examined sample container entries might look as follows:
dn: dc=eb,dc=com
objectclass:top
objectclass: organization
dc: eb
o:ExampleBank
dn: ou=people, dc=eb,dc=com
ou:people
description: Customers and employees of ExampleBank
objectclass:top
objectclass: organizationalunit
objectclass: example-am-managed-org-unitLet us imagine that Bill Smith is an employee of ExampleBank and has both e-banking and phone banking services enabled. However, since his primary mode of access to his accounts is via the web, Bill Smith requested that he be able to check his balance and change his address over the phone, but that the other phone banking services be disabled. His sample entry would appear as follows:
dn:ebid=123456789,ou=people,dc=eb,dc=com
objectclass:top
objectclass:person
objectclass:organizationalPerson
objectclass:inetOrgPerson
objectclass:ebPerson
objectclass:ebEBankingUser
objectclass:ebPhoneBankingUser
objectclass:example-am-web-agent-service
objectclass:example-am-managed-person
objectclass:example-am-user-device
objectclass:inetuser
objectclass:examplePreferences
objectclass:inetOrgPerson
objectclass: sunPortalDesktopPerson
objectclass: sunPortalNetmailPerson
ebid:123456789
displayname:Bill Smith
userPassword:{SSHA}Ek12JHYZ87op9645==
uid: 123456789
inetuserstatus: active
sn:Smith
givenname:William
cn:William F. Smith
mail:Bill.Smith@eb.com
telephonenumber:+1-256-556-5896
facsimiletelephonenumber:+1-256-556-5897
ebStatus:employee
ebAreaCode:CA-17B
ebPreferedLanguage:en
ebSecondaryLanguage:fr
ebCheckingsAccountNumber:133003300
ebSavingsAccountNumber:233003300
ebPhoneBankingEnabled:active
ebPhoneBankingPin:123456
ebEBankingEnabled:active
ebNewsletterSubscription:active
ebNewsletterType:email
ebEBankingCheckBalanceEnabled:active
ebEBankingIntraBankTransfersEnabled:active
ebEBankingInterBankTransfersEnabled:active
ebEBankingChangeProfileEnabled:active
ebEBankingPortfolioManagementEnabled:active
ebEBankingLoanServicesEnabled: inactive
ebPhoneBankCheckBalanceEnabled:active
ebPhoneBankingLoanServicesEnabled: inactive
ebPhoneBankIntraBankTransfersEnabled:inactive
ebPhoneBankInterBankTransfersEnabled:inactive
ebPhoneBankChangeProfileEnabled:active
ebPhoneBankPortfolioManagementEnabled:inactiveDirectory Information Tree
In a desire to guard against the knock-on effect that the frequent reorganizations at ExampleBank could have on the hierarchical organization of its data, ExampleBank has decided to opt for a relatively flat directory information tree structure. This makes a clear distinction between employees, customers and partners by placing them into separate parts of the information tree, as indicated in Figure 9-3.
Figure 9-3 ExampleBank's Directory Information Tree
This distinction between customers, employees, and partners is preferred by ExampleBank for security reasons, as it allows them to implement a separate security policy for each branch. The distinction also provides more economical and easier searches, in addition to improved access control management, all of which translate into optimized performance and improved usability.
Note The directory information tree presented in Figure 9-3 reflects a design choice that presumes no prior directory structure. As many enterprises are likely to have a directory structure in place which does not include the o=enterprise, o=customer, and o=partner level, implementing such an information tree could involve non-negligible reworking of the directory structure and associated overheads. However, in terms of the potential subsequent performance and usability gains, this may prove to be a worthwhile investment.
In addition to the user management achieved through the directory information tree and groups mechanism, ExampleBank has chosen to implement the roles feature supported by Sun ONE Directory Server 5.2. The Directory Server roles functionality allows you to conveniently place users into meaningful sets of users, and can not only be used internally by other Directory Server features such as access control, account lockout and password policy, but also by external applications such as, for example, a phone banking or human resources application that ExampleBank may implement.
Table 9-8 contains a list of roles that might be implemented by ExampleBank to facilitate user management. This is of course not an exhaustive list, but one which serves as a starting point for understanding how ExampleBank might consider grouping users involved in phone banking and e-banking services into roles to facilitate their management.
The roles listed in Table 9-8 are located under the ou=people subtree of the o=enterprise, o=customer or o=partner branches of the directory information tree depending on where they belong. They are managed by a Role Manager entry, which has access to both the roles and the attributes within those roles. This Role Manager entry is located under o=enterprise. Access controls are established to govern the access rights of each role, and the Role Manager.
Code Example 9-1 shows what the Trusted Contributor role entry would look like in an ldif file, providing a more detailed view of how this role functionality might be implemented.
The access control granting all members of this Trusted Contributor role read, search and compare access on phone book data, would appear under o=enterprise,dc=ExampleBank,dc=com as shown in Code Example 9-2:
Note As this extended scope for roles functionality is new to Directory Server 5.2, Sun ONE Identity Server 6.0 would not recognize this new functionality.
Figure 9-4 provides a global view of the role configuration and how it fits into the directory information tree structure:
Figure 9-4 ExampleBank's Roles, Role Manager and Sample Entries
Security Considerations
In a financial environment providing uncompromised security is crucial to success. With Directory Server as part of its online banking deployment stack, ExampleBank can offer optimum security in terms of protecting channels, governing access to data, encrypting sensitive data while in storage, providing flexible password policies, and optimizing SSL connections.
This section describes ExampleBank's security policies and is divided into the following subsections:
Securing Communication Channels
A first imperative for ExampleBank is to ensure that all communication channels between the different elements in the deployment stack are secured. To this end, ExampleBank implements SSL, which ensures the transport security. Furthermore, to enhance the performance for connections using the Secure Sockets Layer (SSL) protocol with certificate-based authentication, ExampleBank takes advantage of the new Sun Crypto Accelerator Board functionality provided with Directory Server 5.2. For information on how to install and configure the Sun Crypto Accelerator Board see Appendix B "Using the Sun Crypto Accelerator Board" in the Sun ONE Directory Server Installation and Tuning Guide.
Securing Data in Storage
A second imperative is to provide maximum protection for sensitive data, such as pin numbers, when in storage. ExampleBank uses Sun ONE Directory Server 5.2's attribute encryption feature to protect data. This attribute encryption feature allows ExampleBank to specify that certain attributes be stored in an encrypted form. This feature is configured at database level, which means that once ExampleBank decides it wants to encrypt an attribute, that particular attribute will be encrypted for every entry in the database. When in storage, encrypted attributes are prefaced with a cipher tag which indicates the encryption algorithm used. An encrypted attribute using the DES encryption algorithm would appear as follows:
{DES}3hakc&jla+=snda%
It is important to realize from a security standpoint, that because the actual encryption is at attribute level, rather than entry level, the only way to encrypt an entire entry would be for ExampleBank to encrypt all of its attributes. It is also important to understand that because the aim is to protect the sensitive data when it is in storage, attribute encryption is always reversible, i.e encrypted attributes are decrypted when returned via search requests, hence the need to secure communication channels with SSL.
Sun ONE Directory Server 5.2's attribute encryption feature provides ExampleBank with the levels of security it requires in that the feature uses the private key of the server's SSL certificate, to generate its own key, which is then used to perform the encryption and decryption operations. ExampleBank is therefore obliged to have an SSL configuration in place which provides the generated key before being able to proceed with encryption, and more importantly decryption operations. What is more ExampleBank benefits from the fact that the Directory Server attribute encryption feature is based on the NSS library, in that it can choose from different encryption algorithms and have guaranteed portability across different platforms.
Securing Password Authentication
ExampleBank has a user population of employees, customers, contractors and business partners, all of whom are authenticating to the online banking stack via the third party single sign-on application. The desire at ExampleBank is to impose more stringent password policies, on certain users such as contractors, and have less stringent password policies governing customers and employees. This desire can be fulfilled due to the fact that the third-party single sign-on application can take advantage of Sun ONE Directory Server 5.2's provision for multiple password policies. Individual password policies can be defined for either a given user or a set of users. A natural way of assigning a password policy to a set of users is to configure the CoS definition to provide values for the passwordPolicySubentry attribute in user entries as a function of the roles that those user entries have.
So, not only does ExampleBank have the ability to tailor password policies to user security requirements, but it can use the roles which are already defined, to make for easier password policy management.
Implementation
Rolling out the Sun ONE Directory Server Online banking stack is a large undertaking, and one which requires extensive planning, analysis, and organizational support.
To gain a comprehensive overview of creating and implementing a directory pilot before you begin your implementation, we highly recommend you refer to Understanding and Deploying LDAP Directory Services (T. Howes, M. Smith, G. Good, Macmillan Technical Publishing, 1999).
The complexity of the implementation requires a phased approach, an outline of which follows. You will need to stagger your implementation over time into logical phases, which are likely to resemble the following:
- Analyze and Plan Your Directory Infrastructure
The functional and business requirements of the Directory Server Infrastructure are assessed and analyzed at this stage. This analysis helps identify any functional gaps that may require system customizing or extension. A technical review of the production environment of the existing implementation will be conducted to determine potential issues with scalability, performance and reliability of the proposed hardware and network environment.
High-level architecture definition follows on from the above analysis and it is at this stage that the recommendations for sizing, scaling, performance, physical distribution, replication and referrals, security, failover, backup, and synchronization with other data sources and authentication mechanisms are drawn up.
- Construct and Design Directory Infrastructure
During this second phase, Sun ONE together with the ExampleBank project team architect, design and construct the core online banking deployment stack. The key areas of activity at this stage include determining server sizing and placements, server configurations, integrating existing backend applications into the directory infrastructure, planning deployment and administration processes and identifying any remaining functionality gaps.
- Implement Core Directory Infrastructure
Sun ONE implements and deploys the core Directory Infrastructure to production during this phase. It is essential that appropriate technology guidance and mentoring in server configuration and administration are made available. Together with Sun ONE the project team assesses the impact on end users and draws up the necessary communication and training plans.
- Enable Enterprise to Employee (E2E) Functionality
The first area of functionality to be enabled is enterprise to employee (E2E) functionality and typically includes the following tasks in the preliminary stages:
- Provide an LDAP-accessible list of users
- Map authoritative sources and clean up user data
- Automatically generate standard IDs
- Flag terminated accounts
- Enable LDAP applications
- Authenticate with intranet applications
Once the above are operational, the finer details of the E2E functionality can be addressed. Linkages between the different data repositories are automated, incremental expansion takes place and any security requirements such as password synchronization are resolved.
The penultimate stage concentrates on providing a scalable single sign-on architecture for all the web and back-end applications. Implementation testing follows and must include integration, performance, negative and user acceptance testing of the E2E functionality. Once again end user impact in relation to the single sign-on architecture will be assessed and provided for in terms of appropriate training and communication.
Finally, once the Directory Server Infrastructure is enabled to provide single sign-on for the platform's web and back-end applications, the project team will document the procedures to assist implementing similar E2E functionality for other applications and business groups within the company.
- Expand Core Directory Server Infrastructure to Support Additional Common Services
The goal is to continue to expand the support additional common services and functionality for further E2E, Business-to-Business (B2B), and/or Business-to-Consumer (B2C) requirements. Specific B2B and B2C functionality will be defined, designed and implemented as and when the business units' requirements are determined and approved.
As you can see rolling out a Directory Server deployment stack is no light affair, and we strongly recommend the involvement of Sun Professional Services, to optimize your implementation. Contact Sun ONE Professional Services at: http://www.sun.com/service/sunps/sunone/