Fit/Gap Analysis of LDAP Services for the myufl Portal

Transcription

1 Fit/Gap Analysis of LDAP Services for the myufl Portal The purpose of this document is to document the LDAP requirements of the myufl portal; provide a fit/gap analysis of the current system; and to make recommendations on ways to fulfill the requirement shortfalls. MyUFL Portal LDAP Requirements The myufl portal was quietly launched on March 31 st, Since the launch, there have been several occasions where the portal became unstable due to problems with the LDAP server that were primarily caused by excessive load on the primary LDAP server. Other issues have also existed where the role-based security privileges for a user were incorrect due to the lack of processes to keep the role information updated in the LDAP server. On October 6 th, 2003, a significant publicity campaign will be launched advertising the myufl portal and usage is expected to increase substantially. It is important that the UF constituents using the portal have a positive experience in terms of functionality, reliability and security. To ensure that the LDAP services can properly meet the demands of the myufl portal, the services must: Functionality 1. Provide current and accurate information to authentication and basic authorization requests by the myufl Portal 2. Provide current and accurate information to role-based authorization requests by the myufl Portal 3. Provide current and accurate information for user attributes including UFID, preferred address and full name Reliability 4. Be available on a continual basis without unplanned downtime and with minimal planned maintenance 5. Respond to myufl requests quickly and efficiently Security 6. Assure that communication with the myufl server is secure Fit/Gap Analysis Requirement Analysis 1. The myufl portal must be able to authenticate users dynamically against the LDAP server when they sign on to the portal. The user s GatorLink authentication credentials should be accurate and up-to-date in the LDAP server so that a user does not needlessly receive a sign on error message. The LDAP server is currently updated with user information every 15 minutes while the Kerberos server used to store the user s password is updated in real-time when the

2 password is changed. Based on the validation of the user s credentials, the myufl portal automatically assigns a base level of authorization. Fit: The 15 minute update timeframe of the user s information used for authentication and basic authorization is acceptable. The myufl requirement is met. 2. In addition to the basic authorization that is assigned when a user provides current GatorLink credentials, the myufl portal needs to provide additional authorization based on a user s role. This role can be one or more of the following three: Faculty, Staff and Student. The portal assigns these roles and the associated security authorizations dynamically to users when they sign on to the portal based on the dynamic role lists maintained by the portal. There is one list for each of the three roles and this information is updated via requests to the LDAP server. Each list has a matching group in the LDAP server and this group is downloaded into the portal (replacing the current list) via a manually initiated process. The groups in the LDAP server are also updated from the contents of the UF Registry database via a manually initiated process. The manual update of the groups in the LDAP is currently in two parts. The first part of the update gets the new group information from the database and takes 4-6 hours. The second part assembles the information and loads it into the secondary LDAP server (taking another four hours). The final step is replacing the database of the production LDAP server with a copy from the secondary server. This step can only be performed manually the primary LDAP server is not updated directly due to load issues. Gap: The portal authorization information should be updated at least on a daily basis. This process should occur nightly so that any changes to the Registry during the previous day will be active at the start of business the following day. The manual processes on the portal and the LDAP server do not lend themselves to providing consistent information and need to be automated. The LDAP process should occur first, followed by the portal process, in order to ensure that the role lists are properly updated with the most current information. Allen Rout mentioned that it may be possible to update the with only changes that have occurred since the last update. This should greatly reduce the load on the LDAP server, shorten the time required for the update and allow an automated update of the primary LDAP server to occur. 3. The myufl portal must be able to assign and update key user attributes dynamically against the LDAP server when they sign on to the portal. These attributes currently include the user s UFID, preferred address and full name. The LDAP server is currently updated with user information every 15 minutes. Fit: The 15 minute update timeframe of the user s information used for updating user attributes is acceptable. The myufl requirement is met. 4. The myufl portal is expected to meet a goal of 99.9% uptime on a 24/7 basis and includes planned maintenance windows. As a critical element in all user sessions, the LDAP server must be available on a 24/7, 365 days per year, with minimal planned maintenance windows and will thus be required to operate at a level substantially better than 99.9% uptime. The portal includes a capability to

3 make requests to a backup LDAP server in the event that the primary server is unavailable. This has been implemented and a second LDAP server is in production; however, this only works for a complete failure of the LDAP server. If the primary server is acknowledging requests but not providing results to the requests, then the portal will not switch over to the secondary LDAP server and authentication requests will fail. For development and testing to occur, the secondary LDAP server must be taken offline and used. There are no formal testing processes or roll-out plans in place. Gap: The built-in failover capability of the portal is inadequate. Another mechanism must be implemented that will switch the portal to the secondary LDAP server under any circumstances where the primary LDAP server is unable to fulfill requests. An appropriate testing process/environment and roll-out plan should be in place to help assure that potential bugs are identified and that maintenance windows are minimized. 5. In addition to the LDAP servers being available for requests, they must also be able to respond to requests in a reasonable timeframe. The two types of requests made by the portal are user authentication requests (includes basic authorization and attribute updating) and role-based authorization requests. The authentication requests occur in real time during the sign on process. A user must be able to sign on to the portal in less than 15 seconds which would require the LDAP server to respond in a fraction of that time. The role-based authorization requests occur in a batch process that can be scheduled to occur during off-peak hours. It is critical that the server be available but the batch process can be much more tolerant of latency in requests. The LDAP server is normally able to fulfill real-time authentication requests in under a second while the batch role update process typically takes less than a minute. When the LDAP server is under conditions of heavy load, these times can grow substantially, with the real-time authentication times exceeding 15 seconds in some cases. Generally, these load conditions are not due to daily, interactive requests but rather due to batch updates of the LDAP database. The primary server currently serves all requests until it completely fails, at which time the secondary server would be engaged through the portal s built-in LDAP redundancy. Gap: The LDAP servers should be effectively load balanced. The load balancing should be based on the ability to service authentication requests in less than 5 seconds. The servers should be sized appropriately so they can manage the anticipated daily, interactive load. Batch jobs to update the server databases should be scheduled during off-peak hours where possible and at alternate times on each server if during peak hours. Load testing should be applied to validate sizing and load balancing settings. Allen Rout also mentioned that the structure of the LDAP database could be redone to substantially improve performance. 6. The communication between the LDAP servers and the myufl portal should be secure so that a user s credentials and other attributes cannot be accessed by unauthorized individuals. Both the LDAP servers and the myufl portal reside at the CNS datacenter and are connected by a network that maintains the traffic inside the datacenter. The data passed between the portal and the LDAP servers

4 is not currently encrypted. Fit: Although the network traffic should be encrypted at some future point, it is currently acceptable for the connection to exist on the controlled network in the datacenter. Fit/Gap Recommended Actions Processes must be put in place to automatically update the portal with role-based authentication information on a nightly basis The primary and secondary LDAP servers should be setup so they can achieve fault-tolerance and load balancing Performance enhancing changes should be applied to the update process so it can be fully automated A testing process and environment should be in place for patches and development work; load testing should be included in addition to functional testing A roll-out plan should be developed as an outline for production LDAP changes (optional) The LDAP database should be re-architected to deliver improved performance (optional) The portal/ldap communication should be encrypted with SSL Proposed Solutions Immediate/Short-term Solution Resources: man hours IBM 615 Server (or equivalent) 2) Modify the group update process so that only changed records are moved into the 3) Automate and schedule the update processes to occur nightly in both the portal Recommended/Long-term Solution Resources: man hours IBM 615 Server (or equivalent ~$15k)

5 2) Add new server that will be used as a development and test platform but can also function as at hot spare during migrations into production Long-term Variation #1 Resources: man hours Server ($2-3k) 2) Add new server that will be used as a development and test platform ONLY it will not be appropriate for load testing Long-term Variation #2 Resources: man hours 2) Use the existing secondary server for development; replace in production when finished