Enterprise Middleware Services

1
Enterprise Middleware Services

• Robert Banz banz_at_umbc.edu
• UMBC Office of Information Technology

2
Middleware Services

• Enterprise Directory Service
• Single Sign-On
• Tying it togetherWeb Services Portals
• Current Work

3
Why?

• Enterprise-Wide services, such as portals,
  require
• Identity Management
• Authentication Authorization
• Identity Management, in many spaces, is not
  offered as an Enterprise service
• Managed in multiple silos (SIS, HR, Alumni)
• No one source for applications, staff, etc. to
  consult.

4
The Enterprise Directory

• Functionality
• Components
• A Real-World Example

5
Functionality

• Identity Management
• Authentication Service
• Authorization Service

6
Components
7
Components

• Metadirectory functionality
• Processes where data is collected, transformed,
  and redistributed.
• Metadirectory is an ambiguous term.
• Commercial Metadirectory products contain
  functionality that varies from Registry
  functionality, to pure data translation.

8
Components

• The Registry
• A database representing the join of information
  about an individual.
• Thin simply information for identifier mapping,
• Fat everything imaginable

9
Components

• LDAP Directory
• The public view of data that is collected in
  the registry.
• Ideally, the interface where all applications
  should be looking.

10
Components

• Authentication Service
• Your primary username/password store.
• Examples
• Kerberos
• LDAP Directory

11
Management Applications

• User interface to the directory
• Edit privacy flags
• Self-Service account management
• Email routing
• Administrative Applications
• Manual registry additions
• Etc.

12
Recommendations

• Avoid Confusion!
• Choose one system of record for each data element
  in the registry.
• Two Way Synchronization?
• An advanced feature, not many do it.
• Design a good directory!
• not what vendor X thinks is a good directory.

13
More Recommendations

• Directory Structure does not need to reflect
  Organizational Structure.
• Choose a flat design.
• Will most likely confuse vendor X ?
• Follow good standards practices
• See Michael Gettes LDAP Recipe
• http//www.georgetown.edu/giia/internet2/ldap-reci
  pe

14
UMBCs Enterprise Directory

15
Directory Consumers

• NOS Specific
• Application Specific
• Others

16
NOS Specific Directories

• A directory tightly tied to a specific Network
  Operating System.
• Active Directory (Microsoft)
• NDS (Novell)
• Most are now LDAP-enabled, and very capable LDAP
  servers.
• Some arent, such as NIS
• However, they may not be suitable for general
  purpose use, because of
• NOS-specific schemas
• Design requirements do not fit best practices

17
Application Specific Directories

• Similar to NOS Specific Directories
• Application may require an LDAP design that is
  not compatible with the enterprise directorys
  design.
• Application may abuse the directory
• Litter objects with a large amount of application
  specific data
• May be write intensive(directories, for the
  most part, are optimized for read-intensive
  service)

18
Others

• Course Management Systems
• Back-population of data in source data systems
• Such as email address, new identifiers
• Access Control Systems
• Door, Parking, etc.
• use your imagination

19
UMBCs Consumer Directories
20
Single Sign-On

• The RealityThis is (currently) fantasy in a
  heterogeneous environment.
• With that saidThere are products that try to do
  it, but tend to use techniques that are generally
  considered dangerous.

21
Striving for Single Sign-On

• Reduced authenticators (good)
• Synchronized password stores (better)
• Single authentication system (best!)

22
Striving for Single Sign-On

• Reduced Sign-On
• Kerberos
• User receives ticket granting ticket, which can
  be presented to authorize issuance of service
  tickets
• Applications accept service tickets as
  authentication.
• http//web.mit.edu/kerberos/www
• Web Single Sign On
• Proxy Authentication

23
Aside Proxy Authentication

• User logs into single sign on service
• Single Sign on Service either
• Takes note of users password, and presents it to
  the services the user is logging into on his/her
  behalf,or
• Has a database of the users passwords for each
  service, and
• Doesnt really solve problems of having multiple
  authentication account databases.
• Can be a security exposure.

24
Tying it Together with the Web

• Web services present applications and resources
  over the (current) ubiquitous user interface.
• They can be accessed by multiple client types
  (computers, cell phones, PDAs) over varying
  levels of bandwidth.
• A seamless web experience is key!

25
Web Single Sign On

• BIG win on a campus level
• Can be deployed incrementally
• Though be prepared for a rush once youve got it
  up.
• Could be a key driver for the enterprise
  directory.
• Remember Application programmers should not be
  concerned with authentication!
• However some 3rd party apps can cause problems

26
Advanced WEB SSO

• Authorization
• Joe, the student
• Bob, the CS Major
• Fred, has paid to use this resource with grant
  
• Or, anonymous authorization(the libraries
  will love this)
• the holder of this ticket is a student
• the holder of this ticket is a CS major
• the holder of this ticket has donated lots of
  money to the library, and can do whatever he/she
  likes

27
An Enterprise Application The Portal

• Requires the ability to identify, authenticate,
  and tailor content to the entire campus community
• Students
• Staff
• Faculty
• Alumni
• Prospective Students
• Contractors
• Business Associates
• Donors
• your affinity group here

28
An Enterprise Application The Portal

• Typical of most applications in the enterprise.
• Used by multiple affinity groups
• Just like a phone system, campus ID card, etc.

29
Portals

• In the purest senseUsed to channel
  information from other applications to a user,
  presented in a customized format fitting the
  needs of the institution, organizational
  affinity, or personal preferences.

30
Web Services Portals

• Portal Deployment Plan
• Step 0 Deploy an enterprise directory.
• Step 1 Implement a Web Single Sign-On System
• Step 2 Implement and deploy a portal.
• inevitably, 2 has already happened.

31
Portals

• But in the real worldAre complicated
  applications containing direct interfaces to
  multiple core business systems, such as student
  administration, HR, and course management
  systems, making them large, and unmanageable, and
  bound to specific core business systems, instead
  of an enterprise middleware infrastructure.

32
Portals

• Sometimes take data in XML format, and apply
  appropriate formatting and navigation.
• others simply redirect the user to the
  appropriate application.
• which would be seamless, if Step 1 was already
  done.

33
Portals

• So many to choose from
• Commercial Blackboard, Campus Pipeline, WebCT,
  PeopleSoft, Banner, Microsoft, Sun, Novell,
  Oracle, SharePoint, Cognos, Brio, SAP, yadda
  yadda yadda
• Open Source uPortal
• Commercial portals integrate well with the
  vendors stack. Other vendors? YMMV.

34
Current, and Emerging Work

• Shibboleth
• eduPerson
• VidMid

35
Shibboleth

• http//middleware.internet2.edu/shibboleth
• An open source, standards based inter-domain web
  authentication authorization system.
• Built upon SAML.
• Shibboleth 0.7 is now available.
• Currently in test deployments on some campuses
  with commercial vendors.

36
eduPerson

• An objectClass used to represent an individual in
  an educational environment.
• Currently version 1.6
• Also, see the eduOrg objectClass, used for
  representing organizational information.
• http//www.educause.edu/eduperson

37
VidMid

• Defining an objectClass (commObject) for
  representing audio video endpoints.
• Such as those used for IP Telephony
• Submitted to ITU-T for standardization.
• Working on authentication authorization issues.
• and other work
• http//middleware.internet2.edu/video

38
NMI-EDIT Consortium

• Enterprise and Desktop Integration Technologies
  Consortium
• Internet2 primary on grant and research
• EDUCAUSE primary on outreach
• Southeastern Universities Research Association
  (SURA) primary on NMI Integration Testbed
• Grant funding is 1.2 million a year
• about ½ to short-term partial hiring of campus IT
  staff to develop and document required standards,
  best practices, etc.
• Almost all funding passed through to campuses for
  work

39
NMI-EDIT Goals

• Much as at the network layer, create a
  ubiquitous common, persistent and robust core
  middleware infrastructure for the RE community
• In support of inter-institutional and
  inter-realm collaborations, provide tools and
  services (e.g. registries, bridge PKI components,
  root directories) as required

40
NMI-EDIT Objectives

• Foster the development of campus enterprise
  middleware to leverage both the academic and
  administrative missions.
• Coordinate a common substrate across higher ed
  middleware implementations that would permit
  inter-institutional efforts such as Grids,
  digital libraries, and collaboratories to scale
  and leverage
• In some instances, build collaboration tools for
  particularly important inter-institutional and
  government interactions, such as web services,
  PKI and video.
• Insure that distinctive higher-ed requirements,
  from privacy and academic freedom to multi-realm
  portals, are served in the marketplace.

41
NMI-EDIT Organization

• Overall technical direction set by MACE
• Middleware Architecture Committee for Education
  (MACE)
• Bob Morgan, University of Washington, Chair
• Campus IT architects and representatives from
  Grids and International Communities
• Directions set via
• NSF and NMI management team
• Internet2 Network Planning and Policy Advisory
  Council
• PKI and Directory Technical Advisory Boards
• Internet2 members

42
Sample NMI-EDIT Process (Directories )

• MACE-DIR Working Group prioritizes needed
  materials
• Subgroups established
• revision of basic documents (LDAP Recipe)
• new best practices in groups and metadirectories
• standards development for eduPerson 1.5 and
  eduOrg 1.0
• Subgroups work in enhanced IETF approach
  scenarios, requirements, architectures,
  recommended standards stages
• Working group deliverables announced input and
  conference call review/feedback processes start
  work groups reconvene as needed
• Process takes around 4-6 months, depending on
  product
• 6-8 people drive the process with 15-50 schools
  participating

43
NMI-EDIT Participants

• Higher Ed 15-20 leadership institutions, with
  50 more campuses represented as members of
  working groups readership around 2000
  institutions
• Corporate - (IBM/Metamerge, Microsoft, SUN,
  Liberty Alliance, DST, MitreTek, Radvision,
  Polycom, EBSCO, Elsevier, OCLC, Baltimore)
• Government NSF, NIST, NIH, Federal CIO Council
• International Terena, JISC, REDIRIS, AARnet,
  SWITCH

44
A Few Year-One NMI-EDIT Milestones

• Sept 1, 2001 Grant awarded
• Oct 2001 eduPerson 1.0 finalized outreach
  begins with multiple workshops
• Jan 2002 HEBCA tested first CAMP workshop
  held
• Feb 2002 PKI Lite CP/CPS e-Gov and Management
  and Leadership Best Practice Awards
• April 2002 Shibboleth alpha ships NMI testbed
  selected NIST/NIH PKI workshop
• May 2002 NMI release, with eduPerson 1.5,
  pubcookie, KX.509, groups and metadirectories,
  video white papers
• June 2002 affiliated directories begins Base
  CAMP testbed kickoff
• July 2002 Shibboleth alpha v 2 ships Advanced
  CAMP
• August 2002 LDAP Analyzer testing begins
  Shibboleth pilot-sites selected Work with
  content providers begins
• September 2002 Grant renewed supplemental
  grant awarded for outreach Shibboleth beta ships

45
NMI-EDIT Release 1 Deliverables

• Software
• KX.509 and KCA, Certificate Profile Maker,
  Pubcookie
• Object Classes
• eduPerson 1.0, eduPerson 1.5, eduOrg 1.0,
  commObject 1.0
• Service
• Certificate Profile Registry

46
NMI-EDIT Release 1 Deliverables

• Conventions and Practices
• Practices in Directory Groups 1.0, LDAP Recipe
  2.0
• Metadirectory Practices for the Enterprise
  Directory in Higher Education 1.0
• White Papers
• Shibboleth Architecture v5
• Policies
• Campus Certificate Policy for use at the Higher
  Education Bridge Certificate Authority (HEBCA)
• Lightweight Campus Certificate Policy and
  Practice Statement (PKI-Lite)
• Sample Campus Account Management Policy

47
NMI-EDIT Release 1 Deliverables

• Works in Progress
• Role of Directories in Video-on-Demand
• Resource Discovery for Videoconferencing
• Directory Services Architecture for Video and
  Voice Conferencing over IP (commObject)

48
NMI-EDIT Release 2 New/Revised Deliverables

• Software       
• Programs and Libraries               
• OpenSAML 1.0               
• Shibboleth 1.0               
• Pubcookie 3.0
• Directory Schemas               
• eduPerson            
• eduOrg

49
NMI-EDIT Release 2 New/Revised Deliverables

• Conventions and Practices    
• LDAP Recipe       
• Metadirectory Practices for Enterprise
  Directories    
• Practices in Directory Groups
• Architectures
• Inter-domain Data Exchange (Draft)       
• Services 
• LDAP Analyzer

50
Enterprise MiddlewareEducational Opportunities

• Workshops
• Pre-conference Seminars at EDUCAUSE Regional
  Meetings
• Campus Architectural Middleware Planning
  Workshops
• Base CAMP (Orientation) 5-7 February 2003
• CIO and Technical staff
• Getting started topics
• http//www.educause.edu/conference/nmi/camp031/
• Advanced CAMP July 2003
• Highly technical
• Research topics

51
On-line Resources Available

• Introductory Documents
• Sample Middleware Business Case and corresponding
  Writers Guide
• Identifiers, Authentication, and Directories
  Best Practices for Higher Education
• Identifier Mapping Template and Campus Examples
• And more.
• See resources page of www.nmi-edit.org

52
Websites and Email Lists

• Websites
• http//middleware.internet2.edu
• http//www.nsf-middleware.org
• http//www.nmi-edit.org
• Middleware information/discussion lists
• http//mw-announce_at_internet2.edu
• http//mw-discuss_at_internet2.edu
• NMI lists (see websites)

53
This page intentionally left blank