SCT Luminis III Technical Implementation Approach · PDF fileSCT Luminis III Technical Implementation Approach . 2 . 1. ... MSU’s SSCT Luminis III.2 ... SCT Luminis III Technical

SCT Luminis III Technical Implementation Approach

Prepared for:

Montana State University

Prepared by:

Russell Wright, Principal Technical Consultant

SunGard SCT Luminis Services

December 3, 2004

rrpauley

Text Box

Randy Pauley 1006-007


ii

Table of Contents

1. Background and Objectives ................................................................................ 2

1.1. Background and Introduction....................................................................... 2

1.2. Technical Planning Objectives ..................................................................... 2

2. Technical Implementation Approach.................................................................. 2

2.1. High Level & Detailed Architecture ............................................................ 2

2.1.1 High-Level Architecture........................................................................... 2

2.1.2 Hardware & Operating System ............................................................... 3

2.1.3 Relational Database Requirements ......................................................... 4

2.1.4 Authentication (Luminis Platform)......................................................... 5

2.1.5 Luminis Account Provisioning & Custom Roles ................................... 5

2.1.6 E-mail ......................................................................................................... 6

2.1.7 Calendar..................................................................................................... 6

2.1.8 External System Integration .................................................................... 7

2.2. Operational Readiness .................................................................................. 7

2.2.1 Roles and Responsibilities ........................................................................ 7

2.2.2 Server Certificates .................................................................................... 8

2.2.3 Backup and Recovery ............................................................................... 8

2.2.4 SCT Luminis Support Site ....................................................................... 9

2.2.5 Post Installation Check List ..................................................................... 9

3. Customizations.................................................................................................. 11

4. Technical Implementation Project Milestones.................................................. 13

5. Open Technical Issues ...................................................................................... 14


2

1. Background and Objectives

1.1. Background and Introduction

On October 11-12, 2004, representatives from each of the four Montana State University institutions/campuses gathered in Bozeman, MT to begin the technical planning process for MSU’s SSCT Luminis III.2 implementation. Through Luminis, MSU plans to deliver to their constituents secure access to enterprise applications, web services, course tools, and communication and collaboration tools including SCT Banner Self-service, WebCT, Luminis Group Studio and enterprise e-mail and calendaring. In addition, the Luminis platform will provide an integration framework through which users can be securely authenticated to the portal and to other external web applications and services and through which enterprise data can be shared between administrative systems and the portal. A custom account provisioning process will also be implemented. As part of the kick-off, a separate 2-day break was held to identify technical requirements and to begin planning the technical aspects of the implementation. The session was led by Russell Wright, an SCT Principal Technical Consultant, and the following individuals from MSU participated in the workshop: Cherie Eck Mike Campbell Marianne Hoppe Scott Hersrud Mark Sheehan Julie Pester Roger VanArdt Rock Brown Tom Morrison Allen Porter Damien DeZurik

Mike Phillips Diane Wefn Craig Denton Christy Cousino Ritchie Boyd Moss Hartt Jacob Dolan Paul Lambeth Doralyn Rossmann Derek Kowalke Jerry Spicher

Sam Bennett Cheri Jimeno Tom Hoffman Jacob Hahn Mari Haynes Alicia Murphy Willie McGee Steve Burk Lindi Whan Nancy Powell

1.2. Technical Planning Objectives

The objectives of the technical workshop were as follows:

• To review in detail the Luminis architecture

• To discuss implementation options for each of the core Luminis components

• To discuss MSU’s implementation requirements and understand how they relate the baseline implementation options

• To identify customizations to the baseline Luminis Platform that might be required to support MSU’s unique technical requirements

• To make decisions, insofar as possible, regarding how MSU will implement each component of the Luminis architecture

• To gather the information to draft this technical approach document

• To gather the information needed to draft an initial technical project plan

• To establish initial project milestones around the technical implementation


2

The purpose of this document is to record the implementation decisions specific to this institution and provide an overall narrative description of the implementation approach. As a companion to this document, a technical work plan will also be delivered. In addition, a section will be included to catalog open issues that still need to be addressed as part of completing the technical implementation.

2. Technical Implementation Approach

The sections that follow describe the high level architecture as well as a detailed implementation explanation of each of the specific Luminis sub-components as they have been defined to date. Where appropriate, customizations required to implement the proposed architecture will be explained. The effort and costs associated with any customization will be summarized later in the document in order to separate the technical discussion from the contractual and budgetary impacts. Note that the following discussion applies to the production environment only. It is assumed that a similar test environment will be established. However, all costs estimates apply to a single environment (i.e. the production environment).

2.1. High Level & Detailed Architecture

The following sections define the current high level architecture for the Luminis implementation as well as the defined implementation approach for each sub-component of the architecture. Unless otherwise specified, it is assumed that these components will be implemented identically in the test and production environments and that budget will be allocated for the implementation of each component in each environment separately.

2.1.1 High-Level Architecture

The below diagram represents the proposed high level Luminis technical architecture as it will look for the initial production roll-out (separate Visio file also provided). A detailed presentation of each sub-component follows in sub-sequent sections of this document. The diagram below assumes a full implementation of LDI for e-Learning; however, MSU has not yet determined their approach for implementing integration with WebCT. Therefore, the WebCT integration components represented in this diagram could change in the future.

(high-level architecture diagram on next page)


3

Luminis III.2 High Level Architecture (Production)

Internet Mail

Sun ONE

Messaging

Server

SSO

E-mail Relay

Sun ONE

Calendar Server

Message Events

(CORBA)

GradesGrades GradesBanner 6.x

IntComptriggers MsgQ

LMG

Learning Mgmt.

Gateway

LMB

Luminis Msg.

Broker

SunONE

LMS

WebCT

CE 4.1

Luminis III.2

Luminis LDAP

Synch Events Synch Events

(LDIS-P)

Synch Events

(IMS)

Synch Events

(IMS)

SCT Integration Components

- Event Dispatcher

SCT Integration Components

- Authenticator

Banner Self Service

Key:

data flow

control msgs

data record Grades

protocol (IMS)

AEACSSO

SSO

E-mail RelayCampus IMAP

Servers

SSO SSO

2.1.2 Hardware & Operating System

MSU will be implementing the Luminis Platform III components on Intel hardware and the Microsoft Windows 2000 operating system in the production. The test environment would ideally be implemented on similar hardware; however, a test environment could be supported on scaled down hardware due, in part, to a significantly smaller user base. It is recommended that the Luminis Platform and its components be implemented according to the hardware specifications outlined in the SCT Luminis Product Family Hardware Requirements document. The minimum recommended requirements for MSU’s production environment, based on an anticipated user base of 35,000-50,000 users—are as follows: Luminis Platform III.2 Server

• 8 x 700 MHz processor (2 MB cache) • 10 GB RAM • RAID-5 disk array (estimated 5 MB per user)


4

• dual+ 10/100/1000 NICs to Gigabit switch recommended. Calendar Server (Sun ONE Calendar Server)

• 8 x 700 MHz processor (2 MB cache) • 4 GB RAM • RAID-5 disk array (estimated 3 MB per user) • dual+ 10/100/1000 NICs to Gigabit switch recommended.

E-mail Server (Sun ONE Messaging Server)

• 8 x 700 MHz processor (2 MB cache) • 10 GB RAM • RAID-5 disk array (estimated 3 MB per user) • dual+ 10/100/1000 NICs to Gigabit switch recommended.

The MSU test environment is currently installed on the following hardware:

Luminis Platform III.2 & Sun ONE Calendar Server (co-located) • 1 x 3.2 GHz Processor (Xeon) • 4 GB RAM • Local disk

E-mail Server (Sun ONE Messaging Server)

• 1 x 3.2 GHz Processor (Xeon) • 4 GB RAM • Local disk

2.1.3 Relational Database Requirements

The Luminis platform requires a relational database to support the uPortal framework as well as the Group Studio, Targeted Announcements, and Message Board applications. Both Oracle 9i and SQL Server 2000 are supported database platforms. MSU will be implementing Oracle 9i to support the Luminis environments. SunGard SCT does not provide hardware sizing recommendations for Oracle. You should work with your Oracle technical representative or resident Oracle DBA to determine hardware requirements. The Luminis Platform III databases are relatively lightweight databases. The following are the Oracle configuration requirements for Luminis Platform III:

• UTF-8 character set • Row-level locking • Tablespace(s) to support uPortal and Luminis application tables. These can optionally be

a single tablespace or two separate tablespaces (one for uPortal tables and one for the Luminis application tables). Either approach is acceptable. The following is the sample SQL code for creating a single tablespace and the associated user needed to support all Luminis tables and to grant the appropriate rights to the user:


5

CREATE TABLESPACE "LUMINISDB" DATAFILE

'/u01/oracle/oradata/LUMINIS/LUMINISDB.ora" SIZE 100M EXTENT MANAGEMENT

LOCAL SEGMENT SPACE MANAGEMENT AUTO;

CREATE USER "lumuser" PROFILE "DEFAULT" IDENTIFIED BY "lumuser_password"

DEFAULT TABLESPACE "LUMINISDB" TEMPORARY TABLESPACE "TEMP" ACCOUNT

UNLOCK;

GRANT CONNECT, UNLIMITED TABLESPACE TO "lumuser";

2.1.4 Authentication (Luminis Platform)

By default, Luminis users are authenticated against Luminis’ internal Directory Service (also known as the Luminis Pipeline Data Store (PDS) or Luminis LDAP). Luminis can be optionally configured to authenticate users against an external authentication source such as Microsoft Active Directory, Novell e-Directory, or a Kerberos-enabled source. This configuration is referred to as an External Authentication Service (EAS). Because MSU does not currently have a single authoritative source for user authentication/authorization, all users will be authenticated against the Luminis LDAP, and an EAS will not be configured.

2.1.5 Luminis Account Provisioning & Custom Roles

MSU has determined that all users who need Luminis Platform accounts will also receive a Banner user account. Therefore, Banner will be considered the single authoritative source for Luminis user account provisioning data, and portal user accounts will be provisioned through the Luminis Data Integration (LDI) integration components. In addition, it has been determined that each of the baseline Banner and Luminis roles (Student, Faculty, Employee, Alumni) will have a campus-specific custom role counterpart as follows: BZStudent BIStudent GFStudent HAStudent BZFaculty BIFaculty GBFaculty HAFaculty BZEmployee BIEmployee GBEmployee HAEmployee BZAlumni BIAlumni GBAlumni HAAlumni The exact name of these roles may change slightly, but these represent the concept. Customizations required to implement this architecture (which will be itemized in the “Customizations” section of this document) include the following:

• SunGard SCT will hold a 1-week on-site training session at MSU with the intent of developing a single custom role and its associated event and trigger required to support integration with the Luminis Platform. MSU will then develop the remaining custom roles over time.

• MSU will need to define business rules and complete development to implement each custom role with its associated event, trigger, and batch extract impact.


6

2.1.6 E-mail

MSU currently provides e-mail services through several campus-hosted email servers. With the implementation of the Luminis Platform, student e-mail services will be provided through a single instance of the Sun ONE Messaging Server which will point to the Luminis LDAP for user data. Faculty and staff e-mail services will be provided through a number of existing IMAP servers located on each campus. The Sun ONE Messaging Server will be installed with a generic e-mail domain which will be translated to a campus-specific e-mail address by the MSU e-mail gateway/relay. The e-mail address will be translated by reading a custom user attribute in the Luminis LDAP called “campusEmailAddress”. This attribute will be created and populated through a custom script that will be developed by SunGard SCT. The script will evaluate users’ custom roles and will then set the campusEmailAddress according to the business rules that MSU will define. These business rules will specify the campusEmailAddress domain value based on a combination of roles and campus affiliation. Customizations required to implement this architecture (which will be itemized in the “Customizations” section of this document) include the following:

• Enhanced E-mail Account Creation module. This module allows the institution to define the e-mail account creation host based on users’ role(s).

• campusEmailAddress management script (described above).

Open Issues related to this approach include the following:

• MSU will need to define the business rules for setting the campusEmailAddress before the script can be developed.

2.1.7 Calendar

Currently, there is no single MSU-wide enterprise calendaring application. Microsoft Exchange is implemented at the campus level. With the Luminis Platform implementation, the Sun ONE Calendaring Server will be implemented, and users, courses, and groups will receive auto-generated calendars. Faculty and staff will continue to use the Microsoft Exchange Calendar Server, but no integration will be provided with the Luminis Platform. Faculty and staff will use the Sun ONE Calendar Server as per policies instituted at the campus and departmental levels.


7

2.1.8 External System Integration

2.1.8.1 LDI for e-Learning

Luminis Data Integration (LDI) for e-Learning is comprised of (1) data integration between SCT Banner, SCT Luminis Platform III, and, in the case of MSU, WebCT. Please refer to the LDI for e-Learning Implementation Guide for a detailed overview of the LDI for e-Learning architecture. The technical details for LDI for e-Learning will be documented in the LDI for e-Learning Pre-installation Checklist which MSU is in the process of completing at the time this document was delivered.

2.1.8.2 Other External System Connectors

No external systems have been identified for integration for the initial implementation of the Luminis Platform.

2.2. Operational Readiness

Although the following operational readiness tasks do not represent an exhaustive list, they do represent several areas that are considered essential to an effective implementation. A thorough review of the Luminis administration, configuration, and content customization guides is suggested as a basis for evaluating all of the operational readiness needs for your particular implementation. Additional recommended details will be included in the technical work plan.

2.2.1 Roles and Responsibilities

The following list outlines some of the basic roles associated with the deployment and operation of a campus wide Luminis system. Under each role is a partial list of corresponding responsibilities. While more than one role may be assigned to an individual, clearly identifying these individuals early in the process will greatly improve planning and operational readiness. Preparation for the various responsibilities will be developed during technical and user training as well as during knowledge transfer with SCT implementation consultants. Note that other roles specific to your institution’s technical environment may also be appropriate.

A. Help Desk

• Password changes • Tracking of user-reported errors or problems • Reproduction of user-reported problems before escalating to the Luminis System

Administrator • Q&A related to usage of Luminis • Compilation of FAQ’s into user-accessible document

B. Luminis System Administrator

• Backups and recovery • Implementation of technical policies


8

• System monitoring • Primary technical contact with SCT ActionLines • Research into Luminis API’s and SDK’s, as they are released to the public from the SCT

Campus Pipeline and Luminis development team • Installation of Luminis-related patches and upgrades (unless outsourced to the SCT

Luminis Professional Services team) • Communication with System Administrators at other schools via listservs:

[email protected] and [email protected] • Delegation of system-administration duties and permissions, where applicable • SSL certificate management • uPortal management: aggregated layouts and channels • Management of Luminis user accounts, groups (including courses and user-defined

groups), and terms

C. Database Administrator

2.2.2 Server Certificates

The Luminis Platform server will require an SSL certificate, signed by a recognized Certificate Authority such as Verisign. The “common name” on the certificate should match the fully-qualified domain name that users see in their Web browser’s “Address” field. This could be the actual hostname of the Luminis Platform Server, or it could be the DNS cname used to alias the server.

Example: if the Luminis III Platform is installed on a machine named (canonically) “server.domain.com”, but users access the box using an alias like http://myportal.domain.com, then the latter name would be considered the “common name”. If MSU elects to serve web mail traffic over SSL, the Sun ONE Messaging Server will also require a certificate.

2.2.3 Backup and Recovery

The Luminis Platform III uses a directory server, as well as a variety of configuration files and internal databases to manage, display, and store system and user information. Recommended are the standard backup routines provided by each of the component systems – Sun ONE Directory Server (using db2bak or db2ldif), Sun ONE Calendar Server (csbackup), etc. These procedures are outlined in detail in the Luminis Administration Guide. Note: There are no baseline scripts provided with the Luminis product suite for the purposes of backing up each of the components in Luminis, but many institutions have developed their own scripts. During the Luminis Platform installation, the Technical Services representative (the “Installer”) will discuss this topic in greater depth with the Luminis System Administrator(s) and can provide a sample script that the institution is responsible for implementing/maintaining. Note, also, that it is essential that the Luminis relational database be backed up at the same time as the components on the Luminis server (e.g. the Luminis LDAP, calendar database, etc., so as to create a seamless “backup snapshot” of all data. Taking a backup of the database that does not coincide with the backup of the rest of the Luminis system files and data could result in backups that cannot produce an effective recovery in the event of a system disaster. The backup process should begin with the cptool set hotbackup on and should end with the cptool set hotbackup off


9

command. Backing up the relational database somewhere between these commands will ensure that the relational database data is “in sync” with the rest of the Luminis Platform environment.

2.2.4 SCT Luminis Support Site

A support account should be created by the Luminis technical staff at the Campus Pipeline Technical Support site – http://www.campuspipeline.com/support. The best practice is to create a single alias (for example, [email protected]) to use as the support account so that all incidents reported are logically connected. (This also ensures that new members of the Luminis technical team can easily be added to the support-contact distribution list, and departed members can easily be removed.)

2.2.5 Post Installation Check List

The following are various topics which need to be addressed after an installation of the Luminis Platform. The system administrator should review in detail each area prior to making modifications to the system. IT Policies

A. Infospace settings

Infospace provides the content for the My Headlines section of the Campus Pipeline system. After software installation, edits to the site configuration directory should be made to define the type of services that will be displayed to your users (news, weather, stock quotes, etc.)

B. Session Timeout settings (refer to the Luminis Administration Guide)

To maintain security, the Campus Pipeline software enforces a timeout. If a user is inactive in the browser for a certain amount of time, an alert will be displayed informing the user that the session is about to time out. The timeout setting should reflect the school’s web usage policy. Through custom service, Campus Pipeline can install role-based timeout. For more information about this service, please speak to your Account Manager.

C. Password Security settings (refer to the Luminis Administration Guide)

If users are allowed to change their passwords through the Campus Pipeline system, there are five password-security measures that can be employed. The above-mentioned section of the Luminis Administration Guide describes these measures and why they help strengthen password security. During the technical planning workshop, the attendees determined that password should consist of between 6-12 characters, and include both numbers and letters.

D. Secret Store Backup settings (refer to the Luminis Administration Guide)

When users forget their Luminis login passwords, the system administrator can reset them. Resetting the Luminis login password will allow a user to regain access to the Luminis system. However, if the password has to be reset by the administrator (rather than the user) the user will no longer be able to seamlessly access external accounts. Seamless access is corrupted because the secrets (i.e. the external account passwords) are stored in a repository


10

that can only be decrypted with the user’s original Luminis login password, which was lost when the administrator reset the login password. To address this inconvenience, the Luminis ships with a feature that is called the Pipeline Secret Store Backup. If this feature is enabled, your users can recover their external passwords even when an administrator resets their login passwords. By default, this feature is disabled. If you decide to enable it, you should be aware of various security issues that arise with its use. For ease of implementation, the attendees of the technical planning discussions typically decide that the best practice for enabling the Secret Store Backup is to require a single agent – the “system” user – to validate password changes. This, in effect, means that no “recovery session” will be required; the system user will validate each password change – and re-encrypt the user’s secret store accordingly – without any other administrative intervention. The command to enable this is: cptool configure secretstore –ar=1 system Once the administrative team has developed experience with the system, a more rigid and secure policy may be put in place. Your SCT technical consultant will enable this feature during the installation process.


11

3. Customizations

The following is a summary of the product customizations and custom services required to implement the features presented in this document. Detailed statements of work will be provided when the decision to move forward with the proposed customizations is confirmed. In some cases, additional effort may be required to drive out detailed requirements for a customization. The following estimates are provided to aid in the decision-making process. All estimates are provided on a per-environment basis.

Description Cost Maintenance Confirmed?

Custom Banner Role, Event/Trigger Development Training (on site)

A SunGard SCT technical services engineer will provide one week of training during which a single custom Banner role will be created along with the associated event/triggers required to support integration of the custom role with Luminis Platform through the LDI architecture.

32 hours on-site training

8 hours travel

4 hours

prep/follow-up

n/a

Yes

Enhanced (Role-based) Automatic E-mail Account Creation Module This module will enable LMU to specify, by role, on which server a new portal user’s e-mail account should be generated. Student accounts will be auto-generated on the integrated Sun ONE Messaging Server, and faculty/staff account creation will be ignored (since they are being provisioned by a separate process).

50 hours 18% annually Yes

Custom script to populate campusEmailAddress attribute in the Luminis LDAP. The Sun ONE Messaging Server will be installed with a generic e-mail domain which will be translated to a campus-specific e-mail address by the MSU e-mail gateway/relay. The e-mail address will be translated by reading a custom user attribute in the Luminis LDAP called “campusEmailAddress”. This attribute will be created and populated through a custom script that will be developed by SunGard SCT. The script will evaluate users’ custom roles and will then set the campusEmailAddress according to the business rules that MSU will define. These business rules will specify the campusEmailAddress domain value based on a combination of roles and campus affiliation.

40 hours 18% annually Yes


12

Custom Algorithm for Generating GOBTPAC_External_User User value It is possible to customize the Banner PL/SQL package that governs the generation of the GOBTPAC_External_User value. The SCT ActionLine can provide the details for how to do this.

$0

Will be implemented by MSU

technical staff

n/a Yes

LDI for e-Learning

160h n/a No


13

4. Technical Implementation Project Milestones

The following technical project milestones are proposed:

Milestone Owner Estimated

Completion Date

Project Launch SCT Completed

Training

SCT Luminis Sys Admin Training SCT TBD

Luminis SDK Training SCT TBD

Custom Role Development Training

(requires upgrade of Banner INTCOMP) SCT / MSU 12/10/2004

Planning SCT / MSU 12/15/2004

Req. Gathering Preliminary Deliverable SCT Completed

Technical Approach Finalized and Documented SCT Completed

Technical Work Plan SCT 12/15/2005

Test Environment LP III.2 Install/Configure

Baseline installation/configuration SCT Completed

Test Environment Customizations: TBD

Install / configure LMB and LMG SCT 12/17/2005

Custom Role/Events/Triggers Completed

(requires upgrade of Banner INTCOMP) MSU TBD

Enhanced AEAC installed/configured SCT TBD

Script for campusEmailAddress implemented SCT TBD

Custom username algorithm in Banner MSU TBD

LDI for e-Learning Configuration

(requires upgrade of Banner INTCOMP) SCT TBD

Production Environment LP III.2 Install/Configure SCT TBD

Baseline installation/configuration SCT 01/31/2005

Production Environment Customizations:

Install / configure LMB and LMG SCT 01/31/2005

Custom Role/Events/Triggers Completed

(requires upgrade of Banner INTCOMP) MSU TBD

Enhanced AEAC installed/configured SCT TBD

Script for campusEmailAddress implemented SCT TBD

Custom username algorithm in Banner MSU TBD

LDI for e-Learning Configuration

(requires upgrade of Banner INTCOMP) SCT TBD

Operational Readiness Processes Verified MSU TBD

Beta Readiness Testing MSU 02/28/2005

Beta Testing MSU 03/15/2005

Portal policies developed MSU TBD

Early Production Rollout MSU 06/1/2005

Full Production Rollout for Back-to-School MSU 8/30/2005


14

5. Open Technical Issues

Issue # Description Status Assigned To

1

Randy, Bert, and Russ need to review/confirm proposed customizations and draft statements of work as appropriate.

Open Randy Pauley Bert Kennedy Russ Wright

2 MSU needs to define business rules for campusEmailAddress population script.

Open Craig Deaton

3 Need to define generic email domain for integrated Sun ONE Messaging Server

Open MSU

4 Need to determine which of the Luminis SDK sub-modules MSU wants to take (Generic Connector Framework or Channel Development kit)

Open Bert Kennedy

Documents

SCT Luminis III Technical Implementation Approach · PDF fileSCT Luminis III Technical Implementation Approach . 2 . 1. ... MSU’s SSCT Luminis III.2 ... SCT Luminis III Technical