Hardware Background Luminis is the premier portal application in use today by school and organizations that use SunGard HE's Banner system. A significant amount of hardware is required in order to run Luminis. SUNYIT has two immediately obvious options for hardware to run the Luminis Platform: Acquire the hardware and run Luminis locally at SUNYIT Outsource the hosting of Luminis and have it hosted elsewhere The Luminis platform is actually installed (i.e. physically at SUNYIT or remotely) needs to be installed close to the Banner data because Luminis integrates closely with Banner. Local installation hardware requirements Luminis Platform (LP) 3-4 have the option of running with either a single server deployment in the portal tier or a parallel deployment in the portal tier. LP5, however, only runs in parallel deployment. This means that there is a larger hardware requirement for a LP5 installation as compared to LP3 or LP4. The recommended best practice is to create two separate environments--a production environment and a test / development environment. This is because: a) changes made in a single server environment frequently don't work when they're set to run in a parallel environment (nor vice-versa); and b) it requires a system rebuild to migrate a server from single server to parallel deployment. As test environment will work fine in a VM environment, the recommended best practice is to build a test environment and a production environment that mirror each-other from a logical point of view with the production environment residing on separate systems and the test environment residing on virtual systems. Parallel deployment requires a network load balancer to a) balance traffic between online systems; b) provide SSL support for the parallel deployed portal servers. Other organizations that have brought up Luminis suggest running Dell Intel-based hardware. Some are using Dell 2950s while others are happy with Dell blade servers. They're also recommending that the portal servers come with no less than 16gb of ram; with less memory, stability issues including daily crashes were reported with as little as 8gb of memory. Last updated 04/03/09 Page 1 of 8
Systems The hardware needed to bring an environment that will support LP4 and, more importantly, LP5, includes: load balancer 2+ portal (application) servers (16+ gigs of memory) database server LDAP (directory) server administrative server CAS server mail server VM server (for development / test) Remote Hosted Luminis The other hardware option to support Luminis is to have Luminis hosted with a third party. The most obvious choice for this is the Information Technology Exchange Center (ITEC). ITEC is a part of the larger SUNY organization that, in addition to other tasks, assists member schools with hardware and database hosting and support. They are physically located at the Buffalo State College campus. Closely aligned with ITEC is the Student Information and Campus Administrative Systems (SICAS). SICAS, located at the SUNY College at Oneonta campus, supports member schools with software, services, and training. Specifically, SICAS supports SunGard HE Banner and related products, such as Luminis. Between ITEC (hardware / systems) and SICAS (applications / Luminis), we could have a successful Luminis installation up and running in an effective, cost-efficient, and timely manner. Transitional Hosting Additionally, it's a viable option to move forward with the portal project by setting up a test Luminis installation in a test in a remotely hosted at ITEC with SICAS support and then move to a more permanently hosted option at SUNYIT. Both ITEC and SICAS have signaled that they can provide remote assistance, support, and administrative services. This is the best option as it integrates well with our Banner 8 plans, is the most expedient way to a functional Luminis environment, and allows us to learn about how to setup, administer, and develop Luminis from organizations that know these platforms and products well. It also minimizes our exposure to risk while providing a pathway back to local hosting if we should conclude that we should be hosting Banner and Luminis physically at SUNYIT. Last updated 04/03/09 Page 2 of 8
Software CAS Central Authentication Service (CAS) is an authentication service, based in HTTP, that Luminis uses to provide Single Sign-On (SSO). With SSO, when a user logs into Luminis, no additional logins are required by the end-user to access other web services, even by external applications. There is an open-source CAS project put together by Jasig: SAML v2.0 http://www.jasig.org/cas/ Luminis also ships with it's own internal CAS implementation. Security Assertion Markup Language (SAML) is an XML-based mechanism for authentication, authorization, and access control. Information on SAML is online at: http://www.oasis-open.org/specs/index.php#saml There is an open-source PHP-based implementation of SAML available called simplesaml.php and it's online at: http://rnd.feide.no/simplesamlphp/ As SAML can use LDAP as a backend, can setup SAML servers on our LDAP servers. The simplesaml project requires Apache and PHP, both of which are open-source. LDAP Luminis uses it's own LDAP server for data storage. The LDAP servers for Luminis will be outside of the existing LDAP environment at SUNYIT. Linux By far and away the most utilized platform for Luminis is Linux. Most organizations are using some variation of Red Hat Enterprise Advanced Server. With the 4.2 release of Luminis, Sungard has certified Advanced Server 4. Oracle Unbreakable Linux is a distribution of Red Hat Enterprise Advanced Server with additional patching features as well as certification to run Oracle database products. Most schools running Linux suggest that the 64 bit kernel with the hugemem option be used. Last updated 04/03/09 Page 3 of 8
Messaging / calendar One of the core components of the Luminis Platform is messaging--the ability to send targeted messages to users. LP3 and LP4 ship with connectors to work with Sun's messaging and calendar software. LP5 ships with connectors to work with Microsoft Exchange server and with Google Gmail. We've only found a single organization that has been able to build a connector to Lotus Notes for LP3; we haven't seen anybody pull this off with LP4. There were several presentations at Summit describing integrating Google Apps / Gmail with Luminis. Gmail can perform authentication using SAML which allows for a seamless integration with our environment once the SAML servers are up and running. In addition to Gmail's use of SAML, several other platforms either support or are working on support for SAML for authentication, including Angel and itunes U. Luminis strongly suggests a messaging component as much of the reason for the product is lost without the ability to send targeted communications. If Gmail were used as a messaging component, we wouldn't need to setup / integrate a local mail server into the Luminis environment. Single Sign On Once these applications are tied to SAML, we can offer Single Sign On (SSO) support for them. That is, once a user logs into Luminis, we can link to these applications so that the user doesn't have to login again. In fact, some organizations have a mail tab that makes Gmail look like just another tab within Luminis. Closely related to SAML is CAS. Once CAS is setup, we can use a CAS PHP library written by the folks at Plymouth State University to "CASify" our web applications such that once a user is logged into Luminis and they go to one of our web applications, they don't have to login again; their credentials are passed along by CAS. The groups that presented at Summit all speak very positively about SSO. Most schools that we talked to told us that if an application didn't integrate with SSO through SAML or CAS, they refused to use it. There is a gotcha, however, in if the CAS / SAML server(s) go down, applications that use SSO become inaccessible. Last updated 04/03/09 Page 4 of 8
Implementation Prerequesite Projects Before SUNYIT brings up Luminis, several projects will need to be completed first. LDAP Banner Authentication SAML / CAS Server(s) Network Load Balancer Messaging (Gmail?) Timeline These projects can occur simultaneously and are not co-dependent. Once these projects are completed, most organizations questioned at Summit report implementation timelines that take roughly 12-18 months with the largest amount of time spent integrating Luminis with other software applications and services. How to move forward There are generally three ways that other organizations have used to get their Luminis implementations up and running: Do it themselves Hire Sungard consultants Retain "consultants" from other organizations (other schools, SICAS) Folks who have gone the DIY route mention that the Sungard documentation is terrible and lacks steps that are necessary to bring Luminis up. Folks who have hired Sungard say that the Sungard consultants who come in do not describe the work that they're doing and do not show the schools how to maintain the software. As a result, once the system is up, there remains no knowledge at the organization as to how the system was built or how to maintain it. Two schools were abandoned by their Sungard consultants partially through the process and were left with incomplete, inoperable installations and no knowledge of how to complete the process. The general consensus is that the best way to move forward is to retain consultants from other organizations--schools, generally, although the SICAS organization would certainly fit this description--and have them walk us through the installation and configuration of Luminis. Last updated 04/03/09 Page 5 of 8
Soft Resources Schools that were interviewed continue to hold that there should be at least one fulltime Luminis administrator / developer involved whose sole task is to maintain and develop Luminis. Luminis developers should have experience with Banner and Oracle, knowledge of UNIX system administration, and a computer programming / software development background. In addition to the technical resources, once Luminis is up and running but before it is deployed, key individuals need to be involved in the steering of the Luminis portal. Ideally, the Luminis documentation says that there should be representatives from every constituent group that is affected by the portal. This includes staff members, faculty, administrators, and students (future (perspective), current, and past (alumni)). Also, after the portal is up and running but before it is launched and made public, individuals throughout the campus community, particularly representatives from major offices on campus, need to be made aware of their responsibility in maintaining content that is accessible through the portal and they need to be trained in how to fulfill that responsibility. 1.10): The following text is from the Luminis Platform Content Customization Guide (page To keep the channels and the information that they contain fresh, you should identify the individuals, groups, and departments that need to supply content. While these individuals and departments will vary from organization to organization, SunGard Higher Education recommends putting together an advisory group or content team consisting of the following: One or more faculty members who can advise on instructor-related content A representative from the athletic department who can advise on contnet related to your institution's athletic programs A representative from your institution's newspaper who can help update content related to campus news A representative from your student government who can help advise on or update content related to the student government One or more representatives from major clubs or the advisory boards that help manage the interaction of your school with extracurricular groups One or more representatives from the registration or financial aid departments that can help manage the integration of administrative options available through your student information system The best practice for maintaining and developing content for Luminis is to use the Last updated 04/03/09 Page 6 of 8
portal to pull in content from other resources such as the official web site. That way, contributors only need to know how to develop content for the official web site and can use the tools that currently exist to support the web site. ITS's role in maintaining the portal content is to provide a platform so that other areas can contribute content. The CMS is positioned well for this role and can be used--without modification--to backend the portal content. Failing to continually develop new content results in the long, slow, painful death of the portal. Last updated 04/03/09 Page 7 of 8
Conclusions Hiring ITEC to setup the systems for us and for SICAS to install Luminis is the best recommended approach. Two identical environments should be setup, one for production, one for development. The environments should be setup to run parallel application-level servers. A portal committee should exist for the purpose of steering the continued development of the portal. At least one additional staff member should be hired for the express and sole purpose of administering the portal, developing new content and applications for the portal, and training users and contributors in how to effectively use the portal. The campus community needs to be made aware of the necessity of continual development of the portal and be provided the tools to fulfill this responsibility. Last updated 04/03/09 Page 8 of 8