Enterprise Middleware Services - PowerPoint PPT Presentation

1 / 53
About This Presentation
Title:

Enterprise Middleware Services

Description:

Middleware information/discussion lists. http://mw-announce_at_internet2.edu ... NMI lists (see websites) Websites and Email Lists. This page intentionally left blank ... – PowerPoint PPT presentation

Number of Views:139
Avg rating:3.0/5.0
Slides: 54
Provided by: rober147
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com