Middleware Planning and Deployment 102: Mapping Out Your

Middleware Planning and Deployment 102:

Mapping Out Your StrategyInternet2 Spring Meeting 6 May 2002

EDUCAUSE October 1, 2002 Middleware Planning and Deployment 1022

Panelists– Tom Barton,

University of Memphis/Internet2– Renee Woodten Frost

University of Michigan/Internet2– Jack Suess,

University of Maryland, Baltimore County– Ann West,

EDUCAUSE/Internet2/Michigan Tech


Agenda

• Introductions and Overview• Two factors for success: Environment and Leadership • Case Study: U of Maryland, Baltimore County• Discussion• Break • Third factor for success: Implementation• Case Study: U of Memphis • Discussion • Research, Resources, and Wrap up


A Bit About Middleware

Middleware makes “transparent use” happen, providing consistency, security, privacy and capability

• Identity - unique markers of who you (person, machine, service, group) are

• Authentication - how you prove or establish that you are that identity

• Authorization - what an identity is permitted to do• Directories - where an identity’s basic characteristics

are kept


Map of Middleware Land


Topics Not Covered

• Business Case• Long-term Value• Technology details


Themes

• Middleware is not just a technology project• Implementation challenges are a reflection

of the –Institutional culture and needs–Installed technology, requirements, and available resources

–Leadership


Contributors to Success

Institutional Culture and Environment

LeadershipImplementation


Institutional Environment


Institutional Environment

• Public vs. Private Institutions• Institutional Vision vs. Local Control• Change Readiness• Strategic vs. Tactical Planning• Role of IT• Policy & Legal Constraints• Resource Determination/Allocation


Institutional Environment:Public vs. Private Institutions

Public and private institutions will be subjected to different governance pressures that may impact how Middleware might be developed and deployed.

• Legal• Financial• Organizational Politics• Governance Structure


Institutional Environment:Vision vs. Local Control

•Effective middleware development will require participation from all quarters

–Is there a strategic vision for the institution or is business done an a day-to-day, year-to-year basis?

–Are business practices and applications well-coordinated?

–How “hardened” are your silos?•Development in a culture of cooperation and information sharing is less effort


Institutional Environment:Change Readiness

• Changes the way we do business – Shifts control of services and/or applications– Relies on unfamiliar technologies– Requires additional communication

• Change is tough– Free agents can be used to innovate– Command-and-control required to ensure stability– Need both. Think about incentives.


Institutional Environment:Strategic vs. Tactical Planning

Middleware development and deployment will require both approaches.

–Strategic planning to define the implementation “road map,” ensure long-term success and ongoing alignment with the institutional mission

–Tactical planning and project management to ensure implementation stays on time and on budget


Institutional Environment:Role of IT

•Perceived Value of Central IT–Is Central IT seen as adding value, or as a barrier to progress?

–Will it accepted in a coordinating role or will a surrogate be required?

•Strategic Resource vs. Tactical Tool–Are strategic decisions made with IT in mind, or is IT a bolt-on after the fact?

–Are funding decisions made with IT input?


Institutional Environment:Policy & Legal Constraints

•Ownership of Data–Is data stewardship well-defined?–Is it centralized or distributed?

•Access to Data–Formally or loosely governed?–Access authority centralized or distributed?

•Data Administration–Centrally managed or distributed?–HIPPA and FERPA compliant?


Institutional Environment:Resource Determination/Allocation

•Financial Resources–Centrally managed or distributed?–Multi-year or annual budgets?

•Human Resources–Centrally managed or distributed?


Leadership


Leadership Requirements

Developing an Enterprise Directory is akin to implementing an ERP project.

• Executive leadership• Developing campus support• Change management• Managing expectations


Leadership:Executive Role

• Unlike ERP, a CIO can’t expect other executives to “sponsor” middleware

• A CIO must make the case, meaning justifying the ROI, of middleware

• Identify the tangible benefits from middleware that matter to your campus

• Make certain you treat this as a major project with a well-defined system development life cycle (SDLC)


Leadership:Developing Campus Support

Laying the groundwork• Meet privately with key leaders and explain

middleware and discuss what it means to their unit. Include faculty leaders in this

• Use all opportunities to discuss the project with faculty, staff, and executives

• Don’t forget to build consensus in your internal IT organization


Leadership:Change Management

• Like ERP, middleware cuts across divisions and requires broad support

• Create a sense of urgency to the project, why is it important?

• It isn’t possible to over-communicate• Identify ways to involve stakeholders in the decision

making process• Make certain you develop some quick wins


Leadership:Managing Expectations and Budget

• Like ERP, middleware development is an on-going process:

• A well-written project plan with quick wins defined at appropriate intervals is key to managing expectations and budget

• Life-cycle budgeting needs to be identified• Middleware’s benefit is often found in productivity

gains or through self-service. Identify ways to measure this ahead of time.


Leadership:Final Comments

• IT is responsible for campus technology architecture, of which, middleware is a fundamental component. No one else will do this for you.

• Every campus has leaders that must be brought on board for major projects. Seek them out.

• Make certain you develop formal plans, identify quick wins, and communicate the benefits and successes

• Success enables more success. Make sure you can accommodate later requests quickly.

Case Study #1:Enterprise Directory Project Planning at

University of Maryland, Baltimore County

Jack Suess, [email protected]

http://umbc.edu/~jack/sac2002


What I Will Discuss

–The business factors driving this initiative–The directory development team and process– Development and deployment of new applications using the directory service

–Creation of a single sign on web authenticator–Future directory plans at UMBC–Applying the lessons learned - how to jumpstart a directory project

–Questions


Business Factors UMBC Needed to Address - Fall 1999

–Finishing up with Y2K.–UMBC decided we would begin discussions to replace our SIS, HR and Finance systems.

–UMBC started two online graduate programs and began planning for a third program. We needed to add more web-based self-service applications, especially account generation.


Business Factors - ContinuedFall 1999

–We had successfully deployed our web portal, myUMBC and were getting requests to extend it to alumni, parents, and prospective students.

–Fall 1999, we saw WebCT usage plateau, discussions with faculty pointed at need to make it “easier” to use course tools.

• Eliminate faculty handling of student account problems• Make it easier to “enroll” students• Eliminate the need to know HTML


Business Requirements

– Applications needed 7x24 access–The indecision over our SIS/HR plans made using those systems directly a mistake.

–We needed to reduce transactions on our overloaded administrative systems.

–We had reorganized support services and made our Helpdesk the focal point. We needed to empower them with ability to manage basic account functions.

–To support alumni we needed to expand authentication services beyond solely using Kerberos


Why Deploy an Enterprise Directory

•Hype- Directories were hot technologies in 1999, though not necessarily mature. •UMBC has a large Unix infrastructure and significant Unix development experience•We didn’t want the complexity or cost associated with using a DBMS •We wanted to solve this in a way that would allow us to collaborate with other schools.


Getting StartedJanuary 2000

–I2 was beginning to focus on the problem of middleware, I saw this as an opportunity for UMBC to be engaged in I2.

–I2 was soliciting schools to participate in an Early Adopters program and UMBC applied.

–I was the initial project sponsor for middleware at UMBC.

–January 2000 we created our middleware project team


Directory Project Team

–A technical lead was identified and the project team created.

• Members represented all areas of IT• I needed to get the team understanding what was meant

by directory services • Sharp differences on team over what directory platform to

use• I2 middleware group was very helpful in framing issues for

consideration


Directory Development -Engaging Non-IT Staff

–I met privately with our Vice Provost for Academic Affairs and CFO to discuss the project and get their support

–I worked through our IT Steering committee and discussed the project in terms of the business factors, not technology.

–In hindsight we should of done a better job broadly communicating this to the campus.


Selecting a Directory Product

–This became contentious - we looked at NDS, AD, Innosoft, iPlanet and Oracle

–Our process looked at initial cost, cost per entry, API, scalability, and availability.

–We had concerns about directory products tied too closely to network LAN products.

–iPlanet had the best product but cost was a concern. Opportunity struck - we purchased Innosoft - iPlanet then bought company and transitioned customers over to iPlanet :-)


Defining Data Access Strategy

–We initially focused on data needed for whitepages and account management.

–We negotiated read access to SIS and HR.– Updates to demographic data would be done through our portal, myUMBC.

–Where duplicate data exists in HR/SIS we used most recent entry as “current”

–Broad IT support was critical here, we needed input from our analysts and DBA’s to fully understand what data was needed and get database triggers defined.


Defining Data Update Strategy

–Goal for account generation was that a PT student could register that day and get an account within 30 minutes.

–We discussed merits of real-time, near real-time, and batch updates of directory.

• Realtime - triggers between DBMS tables• Near realtime - triggers generate a changelog queue• Batch - extract and update periodically

–Selected near realtime to meet our goal for account generation but lessen dependencies.


Directory Development TeamMarch 2000

•1 full-time directory architect•1 directory programmer (.75)•PT access to an Oracle DBA (<.25)•PT access to SIS and HR analysts (<.25)

•Allocated $75,000 in startup funding


Development and Deployment- Phase 1

–Phase 1 – Generate new web-based account management system, go live August 2000

–Decided to load all students in SIS who have ever applied to UMBC to date, ~275000. This was a mistake, we should of limited it to active members only.

–Challenge was how to provide different levels of access to the directory without complex ACL’s and grant this access to other web services.

–We created a service we call webauth, which is similar to Shibboleth’s pubcookie.


Development of Webauth

–Goal was to provide a web-based single sign on (WebISO) that can authenticate across any web-based application.

• In summer 2000, nothing had been released that did this. We modeled our approach on Kerberos and each web service has a unique service ticket

• Created apache module • Created Java and Perl interfaces

–Available upon request but I would strongly suggest you consider I2’s Pubcookie.


UMBC Directory Applications

• Webadmin –web-based tool to enable delegated authority of dir updates

• Course management system – accounts and course auto-enroll

• Windows 2000 migration - supporting Active Directory

• Remedy ticketing system – feed client info• Webauth extended to third parties• VPN access


UMBC Directory Applications - Webadmin

•Created Webadmin, a web-based tool for accessing the directory, released 8/2000

–Allows delegation of control over different functions to groups or people based on roles and needs. Helpdesk group can now reset passwords and quotas.

–Self-service - students can now select username and password, create email aliases, and forward mail without coming onto campus

–Mistake - the user interface could have been better


Delegating AuthorityFall 2000

Goal - Let Helpdesk immediately handle basic account tasks on behalf of users without root access

–Store user preferences in LDAP as attributes, wrote LDAP interface to Unix systems

–Users must use Webadmin to update account–Helpdesk can reset passwords, quota, set forwarding address, and Unix preferences.

–Fall 2000, delegation horror story. Helpdesk student stole class project from another student


Integrating Course Management Tools with the Directory

•One of our initial goals was to simplify the faculty effort when utilizing course management tools.

–Eliminate account management problems–Simplify enrollment of students into a course

•Purchased Blackboard Level 3 license, paid them to accept our Webauth credentials solving account management issue, 1/2001•We developed code for WebCT 3.1 to accept our webauth credentials but decided to drop WebCT


Supporting Windows 2000 Spring 2001

•Goal - Migrate our public labs from Windows NT to Windows 2000. All our labs provided common file access (AFS) and used our Kerberos authentication.•Problem - Windows 2000 requires AD, how do we get our account information now stored in iPlanet into AD?•Spring 2001, tested AD against existing Kerberos environment and got this working


iPlanet to AD IntegrationSummer 2001

•Summer 2001 began work on linking iPlanet directory to Microsoft AD•Reverse engineered Microsoft AD account entries to identify what is needed for an account entry by looking at before/after.•Wrote LDAP connector in Perl to update AD when iPlanet entries are created or change. •Windows 2000 fully deployed in all labs January 2002•Metamerge now provides a connector for this


Remedy IntegrationSummer 2001

•Goal - Keep client information (phone, office, email) up to date in Remedy•Developed a connector between LDAP and Remedy (Oracle DBMS) that updates Remedy whenever certain data elements are updated in LDAP.


Extending Webauth to 3rd PartiesSpring 2002

–Spring 2002 - provided linkage to one-card vendor (DieBold/JSA) for eCommerce. We provide a link from our portal to our JSA.

–We provided JSA with a webauth service ticket for their server and webauth client code to request validated campus-id when presenting a webauthcookie.

–I’d love to do with with other 3rd Parties such as Sallie Mae Solutions


Blackboard Course Auto-EnrollSummer 2002

–Added course containers to LDAP that track enrollments to courses (add/drop)

–Wrote a Java servlet for Blackboard that is updated by LDAP connector

–For fall 2002 we will have students auto-registered into their Blackboard course.

–We use course containers for other services like limiting lab access to students in particular courses, mailing lists, etc.


VPN Access

•Fall 2002 Goal - Rollout VPN services in fall to secure wireless and provide remote access to administrative applications•Driven through LDAP group membership

–Due to limitations in VPN users can only be in one group, we had to be creative in how we defined groups to meet needs of different users.

–Most users automatically defined into a group but some people have to be managed manually


Short Term Plans AY 2002-2003

•The following are project proposals under consideration

–Peoplesoft 8.0 integration with LDAP–Automated account deletion/deactivation–OS/X Netinfo and Novell 6 integration–Shibboleth–Alumni access


Peoplesoft Plans

•Goal - Use LDAP to manage access to Peoplesoft.•Bringing Finance 8.4, HR 8, EPM 8.3 in July 2003. SA development will then start with deployment done by 8/2005•Recently begun testing of using LDAP for authentication and managing user profiles in Peoplesoft 8 with good results.


Automated Account Deletion

•Currently we have the ability to quickly deactivate an account via LDAP with the exception of Novell.•We are working with our IT Steering committee to get deletion procedures defined. •Approach will be to deactivate accounts, then based on the group the user belongs to delete accounts at some point in the future.•I2 has recently put up a discussion paper on account management and deletion


OS/X Netinfo and Novell 6 Integration

•Transitioning to Novell 6 this summer, goal is to look at integrating Novell 6 and iPlanet so we can manage accounts through iPlanet•Goal is to transition Macintosh labs to OS/X over summer 2003. We would like to utilize LDAP and Kerberos for managing OS/X in the labs.


Shibboleth

•Shibboleth provides inter-institutional authorization service where the person controls what information is released to whom.•We will be demonstrating this to our USM library directors in the fall as a possible solution for inter-campus (USM) access to library databases.•We hope to have webauth working with Shibboleth sometime this fall


Alumni Access to our Portal

•An original goal of the directory project was opening our portal to alumni. •To support this we developed an authentication routine that supports both Kerberos and LDAP. Members will use Kerberos and affiliates use LDAP.•We’re working with our Alumni group on whether to release this now or when we complete our new Portal next summer.


Results

–After Kerberos and DNS,the directory service has been our most reliable service, at least 99.99% uptime.

–These self-service applications have revamped the way we support users and the services we provide.

–Automated Blackboard connections were well received by faculty.

–Using a directory allowed us to utilize our institutional data in an academic context. The staff that did this would never be able to directly access and update our legacy SIS tables.


Lessons Learned

1. CIO leadership is important 2. Building support for the project inside and outside

of IT is critical3. This will be a new service that must be continually

supported.4. Managing expectations is important5. The benefits exceed the costs6. Don’t reinvent the wheel


Lessons Learned:CIO Leadership

•Unlike ERP, a CIO can’t expect other executives to “sponsor” middleware.•A CIO must make the business case for middleware and find the money•Identify the tangible benefits from middleware that matter to your campus•Look at Middleware Business Case on the CD, it identifies 24 possible applications


Lessons Learned:Developing Campus Support

•Laying the groundwork:•Meet privately with key leaders and explain middleware and discuss what it means to their unit. Include faculty leaders in this•Use the opportunities a CIO has to discuss the project with faculty, staff, and executives•Don’t forget to build consensus inside your IT organization for the project.


Lessons Learned:Planning For Support

•Treat this as a formal application development project•Don’t skimp on hardware or redundancy•Be prepared to redefine responsibilities of people as workload changes•Initial development team might not be the best to support this once it is in production•Look for ways to make IT services easier and better as a way to build internal support


Lessons Learned:Managing Expectations is Important

•Middleware development is an on-going process:•A well-written project plan with quick wins defined at appropriate intervals is key to managing expectations and budget•Life-cycle funding needs to be identified•Middleware’s benefit is often found in productivity gains or through self-service. Identify ways to measure this ahead of time.


Lessons Learned:The Benefits Exceed the Cost

•Problems related to accounts - account generation, forgotten passwords, and disk quota represented 1/3 of our helpdesk requests, we can now handle 90% of these over the phone. This essentially freed 1.5 sysadmin positions.•Infrastructure projects by their nature usually provide many unintended benefits. In our case we never expected to use this system for our one-card or VPN. I’m sure over the next few years we will find many other benefits


Lessons Learned:Don’t Reinvent the Wheel

–UMBC started this process 2.5 years ago. Many of the technical issues we found difficult now have solutions - WebISO, Blackboard, and AD.

–I2, NMI, and Educause now have a wide array of material on their web sites that will help you get started.

–NMI is running middleware camps, my suggestion is for any campus considering this to take their team to the camp, learn from others, and plan your strategy


Discussion


Contributors to Success

Institutional Culture and Environment

Leadership Implementation


Implementation


Implementation

• Issues, factors and choices that determine how IT does the implementation.

• Previous section examined the institutional environment and how it will influence your middleware implementation.

Now the rubber starts to hit the road…


Implementation: Organization Culture & Structure

• Number of IT departments outside central IT–MW is integrative infrastructure –If existing services are compartmentalized

• slower progress• more effort is need for organizational engineering

• Consolidate organizational functions or separate reporting structure–Build or reinforce communication/coordination channels

–Find “wormholes.”


Implementation: Organizational Culture & Structure

• Competitive or collaborative–Challenges “ownership” –Can feel disenfranchised–Anticipate clear needs and keep everyone on the same page

• Willingness to change–Technical infrastructure –Formally or informally, organizational structure must change too


Implementation:Skill Sets & Roles

• Technical architecture planningGrasps the breadth of databases, applications, security, and their interrelationships. Understands organizational needs and values and can map those into functional and security requirements for MW.

• Project managementThis person needs to have a level of influence equal to being near the top of the central IT org chart. Might be the same as the technical architect.


Implementation:Skill Sets & Roles

• Systems analysis & interpersonal communicationsInteracting with data stewards. Ensuring that detailed designs mesh with real practices in business & academic offices.

• Systems, database & application developmentPeople who can implement the selected technologies and who understand the details of how they must be integrated into the existing infrastructure.


Implementation:Staff Resources

• FTE requiredHeadCount/10000 + numberPlatformTypes/3+ numberApps/4 + numberCBSs/2Increase for shorter implementation time or for complex policy requirements. It depends….

• Ongoing staffing >= initial levelAnticipate success. More MW services will be built to integrate more apps over time.


Implementation:Staff Resources

• Train staff-in-residence, hire new staff, use consultants…– Creative management– Acceptability of outsourcing

• Sharing the vision–Key technical people must understand the strategic value of the project

• Providing the middleware-architect skill may determine how a project is done or whether it requires new money

• Offering incentives to other staff


Implementation:Project Resources - Summary

• “Assimilate” or fund a “New Activity”– For assimilation, must have sufficient

• Skills• Time• Money

– For new activity, must lack• Skills, staffing time, a natural “home” within your existing

organizational structure• Nothing, but you can get more by asking for it


Implementation:Communication Plan

• Champion–Must share the vision at meetings/presentations and be

supported from the top –Tailor the message; financial officer, data owners,

IT stakeholders, techies –Emphasize ROI, identity management, security,

applications–Use Public Affairs, PR offices if available

• Website and personal touch–Consistent message–Continual flow of info for a diverse audience– Personal visits tailor the message for the specific audience


Implementation:Middleware and its Role

•Middleware Must Be Defined–Do the stakeholders understand what it is?–Have the components and their relationships been defined?

•Benefits of Middleware Described–Do program managers understand how middleware can help improve/increase service?

–Do end-users understand how it will affect their activities?


Implementation: Middleware and its Role

•Business & Academic Drivers Defined–Internal drivers:

• Transactions between members of campus community• Transactions between members and institution

–External drivers:• Transactions between institutions

•Mapping Benefits Against Drivers–Match priority applications against the appropriate middleware components


Implementation:Technology

• New vendors or technologies needed?–Plan up front for time to assess what you have–See how that meshes with the proposed technical architecture

• Metadirectory processing–Expect your technical architecture to include a “metadirectory”.

–Spend some time to carefully consider its design and component technologies – you will have to live with this for a long time.


Implementation:Technology

• New hardware needed? Plan on it–Meet performance & functional requirements–Avoid side-effects occurring with multiple services–Provision for scalability, it will payoff

• Solid network infrastructure–Network must work flawlessly –Remediate before you start–Relies completely on the integrity and performance of the network

Case Study #2:A Decade of Directory Services at

The University of Memphis~~~~~ in 30 minutes! ~~~~~

Dr. Tom [email protected]


Three Phases of Middleware

I. Initial IntegrationFirst community wide services.

II. Common IT PlatformCommon identifiers, authentication, authorization, & messaging services, and account provisioning reduce complexity for users and for IT staff.

III.Rational Identity ManagementBPR & architectural changes to have an authoritative database for identity, enable earlier & remote engagement of constituents.


I. Initial Integration

• What – Initial SIS & HRS “feeds” integrated for CSO Nameservice

(aka Ph)– Dialup authentication & authorization– Email routing for @memphis.edu– White pages

• Drivers– Inadequate dialup service– Frustration with central IT

• How– Stealth, 1 FTE. Central IT management not involved!!


I. Initial Integration• Organizational interactions

– Heretical idea to use data for other than original purpose– Adversarial relationship between central IT & business

offices– Circumstantial solution: academic proponent (a non-

combatant!) with gloss of executive blessing• Demonstrated values & lessons

– Possible to provide popular services with little staff overhead

– Beginning of an organizational learning curve for central IT management and key business offices

– Data integrated across core business systems is the foundation for community wide applications


II. Common IT Platform:Continuous Improvement Cycle

What– Common username for all basic services– Password synchronization across several

authentication services– Integration of suite of basic services with directory

services for authentication & authorization: mailbox, many COTS & custom web applications, CMS, calendar, dialup & wireless, group messaging, authenticated email, computer labs, shell accounts, network registration, guest registration, card swipes, …

– Automated resource lifecycle management


II. Common IT Platform• Drivers

– Avoid requiring users to know where in the network they are as our services become more complex

– Provide competitive level of service within severe resource constraints

• Simplicity of operational management• Delegation of selected authorization management to

appropriate departments• Self serve account maintenance• Automation or avoidance of otherwise manual tasks

commonly left for central IT


II. Common IT Platform• How

– Earlier additions stealthy, some later ones declared projects. – 1.5 FTE ongoing– No additional funding – assign normal resources according to

priority• Organizational interactions

– Earlier: wormholes between traditionally siloed groups in central IT.

– Later: absorbed into basic function of several standing teams – IT leadership that promoted Learning Organization principles

and a more flexible approach to organizational structure– Institutional IT governance & strategic planning processes


II. Common IT Platform

Demonstrated values & lessons– “Middleware Business Case” values drawn from

our experience & vetted by other Internet2 Early Adopters.

– Additional funding & dedicated project teams are nice, but might not be a necessity.

– Effective institutional IT governance processes and a flexible central IT organizational structure can alleviate organizational pain with middleware implementations.


III. Rational Identity ManagementWhat– A single authoritative source for identity related

data which is made to appear wherever else it needs to be

– Business process tinkering so that business offices actually maintain identity data in the identity database and not directly (or solely) in their own system.

– Further tinkering so that self-serve online processes are used with new affiliations, enabling the constituent’s ID info to be automatically populated by reference to their online account.


III. Rational Identity Management:A Scenario

1. Prospective student X uses http://iAM.memphis.edu to get account with self-asserted, unvalidated ID info. Being foreign, a bogus SSN is generated for X in case it is needed.2. X uses account to applyuses account to apply for admission online. This creates a record in SIS with unvalidated ID info. ID database now also has SIS identifier for X.3. Admissions Office validates X’s ID info as they deem appropriate & admits, conditionally updating ID database.4. X enrolls. Campus ID card office updates ID database with correct birthdate from driver’s license. Correction flows back to SIS as well.5. Becoming a student worker, X gives HR a real SSN. HR updates ID database with real SSN, enabling HRS and SIS updates pertaining to X to be integrated by the metadirectory. SIS receives updated SSN.


III. Rational Identity Management

How– Initial phase will supply ID database query & update tools to

supplement existing record creation and maintenance processes.

– Determine per-affiliation ID data validation requirements & solutions.

– Determine online affiliation engagement processes.– Remote account initialization for those following existing

affiliation engagement processes.– Later, automate the record creation & maintenance

processes for identity data in major ERP systems. – 1.5 – 3.0 expected FTE during each of several ≈2 month

conversion periods, drawn from Systems, Developers, and Business Offices.


III. Rational Identity Management

• Organizational interactions– Idea viewed as helpful but heretical by most data

stewards.– Executive officers have bought in, on the promise

of enabling online services to reach a broader constituency, and thus improvement to the bottom line.

– Piggyback on all of the BPR that will attend an upcoming ERP conversion project.


Metadirectory Extension Project

What– Add new major affiliations of “admitted student”,

“registered student”, “faculty” (as opposed to “staff”), “alum” to existing affiliations of “enrolled student”, “staff”.

– Remote account initialization.– Provision resources to enable limited access to

“prospective” members of community, and to support outsourced services for alums.

– Example of “continous improvement cycle” to the “common IT platform”.



• Drivers– Online post-admission process – Improve service to new faculty– Job search & email redirection services for alums– Email communication with new constituencies– Improve “class e-mail”

• How– 2.5 FTE among 7 members of a project team – no new funding– Extend existing provisioning state machine; augment

http://iAM.memphis.edu website




• Organizational interactions– Requests from Provost, Registrar, & Student

Services handled cooperatively. – Administrative systems developers now

reasonably aware of metadirectory and its value.– This has become business as usual.

• Demonstrated values & lessons– Check back same time next year!!


Discussion

Research and Resources


Research Community• Expert, diverse leadership and collaborators• Broad participation and review

–MACE and related working groups–NSF catalytic grants –Early Adopters–Higher Education Partners

• campuses, CNI, CREN, GRIDS, NACUBO, NACUA…–Government Partners

• NSF, NIH, NIST, fPKI TWG…–Corporate Partners

• IBM/Metamerge, Liberty Alliance, Radvision, Sun…–International communities–Standards bodies


NSF Middleware Initiative

• NSF award for middleware integrators to– GRIDS Center

• Globus (NCSA, UCSD, University of Chicago, USC/ ISI, and University of Wisconsin)

– NMI-EDIT Consortium• Internet2, EDUCAUSE, and SURA

• Separate awards to academic pure research components• Build on the successes of the Globus project and

Internet2/MACE initiative • Multi-year effort• A practical (deployment) activity that necessitates some research• Releases occur every six months, roughly May and October


ResearchWorking Groups/Projects

• Directories– LDAP Analyzer– Practice Papers– Object Classes

• Shibboleth - Inter-institution web access• PKI – HEPKI-TAG & PAG, S/MIME, PKI Labs• Middleware for Video – VC, VoD• Digital Rights Management• Medical Middleware• Implementation Roadmap


Enterprise Middleware Resources Available

• NMI-EDIT Release ComponentsSoftware

Directory Object Classes Conventions and Practices

Recommended PracticesWhite Papers

PoliciesServicesWorks in progress: White Papers


Enterprise MiddlewareEducational Opportunities

• Workshops– Pre-conference Seminars at EDUCAUSE Regional

Meetings– Campus Architectural Middleware Planning Workshops

• Base CAMP (Orientation) – Feb 5-7, 2003– CIO and Technical staff– Getting started topics

• Advanced CAMP– July 2003– Highly technical– Research topics


On-line Resources Available

• Introductory Documents

– Sample Middleware Business Case and corresponding

Writer’s Guide

– Identifiers, Authentication, and Directories: Best Practices

for Higher Education

– Identifier Mapping Template and Campus Examples

• See handouts


• Websiteshttp://middleware.internet2.eduhttp://www.nsf-middleware.orghttp://www.nmi-edit.orghttp://www.grids-center.org

• Middleware information and discussion listshttp://[email protected]://[email protected] lists (see websites)

Websites and Discussion Lists


CDROM Materials Contents

• Presentations • Practice papers• Tools• Software


Session Wrap-up

• Middleware is:– A strategic infrastructure– 50% technical and 100% political

• Don’t reinvent the wheel – Each implementation is different– Big picture process and requirements are the same– There are resources that can help

• Assess strengths and weaknesses and plan accordingly

• Communication and relationship management is key


Questions and Comments?

– Tom Barton, [email protected]

– Renee Frost, [email protected]

– Jack Suess,[email protected]

– Ann West, [email protected]