Introduction to Middleware - PowerPoint PPT Presentation

1 / 74
About This Presentation
Title:

Introduction to Middleware

Description:

This creates a data ... Processed data to create standard methods for AuthZ. 41. IdM ... A toolkit to help create and manage the 'Group Registry' ... – PowerPoint PPT presentation

Number of Views:92
Avg rating:3.0/5.0
Slides: 75
Provided by: tylerw5
Category:

less

Transcript and Presenter's Notes

Title: Introduction to Middleware


1
Introduction to Middleware
  • Eric Galyon
  • etg_at_colostate.edu
  • January 2005

2
Topics
  • What is Middleware?
  • Middleware Initiatives
  • Specific Middleware Technologies
  • Middleware at Colorado State University

3
Hope to answer the following
  • What is Middleware?
  • Who is developing Middleware?
  • What does it do?
  • How does it work?
  • What is Middleware at Colorado State?

4
What is Middleware?
5
Description by Analogy
  • What is the Internet?
  • The Internet is not any single physical or
    conceptual entity
  • The Internet is a set of
  • Physical network devices and connections
  • Protocols
  • Services
  • Standards

6
Internet
7
Making Sense of the Internet
  • Understanding the broad goals and objectives of
    the Internet create a better picture than any one
    individual technology
  • End users should not perceive the complexity
  • Even Information Technology professionals should
    only need to know subsets of Internet Technologies

8
Internet Goals
  • Get the data where it needs to go. Both
    unreliable best-effort and reliable guaranteed
    delivery in a guaranteed order.
  • Provide standard services for specific types of
    data (web, e-mail, file transfer, etc.)

9
Services
10
Addressing and Name Resolution
11
Internetwork Data Transport
12
Routing
13
Link/Segment Data Transport
14
Back to Middleware
  • What is Middleware?
  • Middleware is not any single physical or
    conceptual entity
  • Middleware is a set of
  • Protocols
  • Application services
  • Standards

15
Middleware
16
Making Sense of Middleware
  • Like the Internet, understanding the broad goals
    of Middleware creates a better picture than any
    one individual technology
  • End users should not perceive the complexity
  • Application Developers and Information Technology
    professionals should only need to know subsets of
    Middleware Technologies

17
Middleware Goals
  • Simplify the end user experience
  • Centralize common data at an institutional level
  • Increase Security (beyond just transport
    security)
  • Increase Privacy

18
Integrated/Simplified Data Management
19
Authentication
20
Authorization
21
Digital Certificates
22
Standard Naming Conventions
23
Domain Specific Middleware
24
Middleware Services
  • Identification
  • Authentication
  • Authorization
  • Central Data Consolidation
  • Network Layer Encryption
  • File Encryption
  • Digital Signing
  • Federated Trust

25
Differences Between the Internet and Middleware
  • Intended Audience
  • Internet Concerned with delivering data and
    services between network nodes.
  • Middleware Concerned with delivering data and
    services to applications.
  • Lifespan
  • Internet Many technologies have existed and been
    refined for decades.
  • Middleware Still in development. Middleware
    technologies will continue to evolve some may
    never mature.
  • Proprietary versus Standard
  • Internet Many protocols and standards have
    matured and become ubiquitous.
  • Middleware Many institutions, including CSU,
    have developed their own Middleware until
    standards are finalized.

26
Middleware Initiatives
27
Who is developing Middleware?
  • Internet2 Middleware Initiative
  • http//middleware.internet2.edu/
  • Coordinating body for research and standards
    development of Middleware technologies
  • NSF Middleware Initiative (NMI)
  • http//www.nsf-middleware.org/
  • Provides funding for Middleware research
  • Packages mature Middleware technologies into
    NMI Releases

28
Who is developing Middleware
  • nmi-edit
  • http//www.nmi-edit.org/
  • National Science Foundation Middleware Initiative
    Enterprise and Desktop Integration
    Technologies)
  • Collaboration between Educause, Internet2, and
    the NSF
  • Coordinates educational activities (Middleware
    conferences) and sponsors specific
    implementations at institutions for real-world
    feedback
  • Individual Institutions
  • Proprietary solutions developed at institutions
    to address data management, security, and/or
    privacy
  • Institutions can contribute solutions and
    feedback to Internet2 Middleware Initiative

29
Who is developing Middleware
  • Commercial Companies
  • Microsoft, IBM, Oracle, Sun, Novell, etc.
  • Each has developed applications related to some
    aspects of Middleware
  • Commercial products, to date, do not tend to
    address complexities in the higher education
    community and do not address research needs
    (http//middleware.internet2.edu/overview/middlewa
    re-faq.html)

30
Specific Middleware Technologies
  • A sampling of the developing Middleware
    technologies

31
Middleware Technology and Service Summary
32
Middleware Services
  • Identification
  • Who are you?
  • Authentication (AuthN)
  • Are you really who you say you are?
  • Authorization (AuthZ)
  • Are you allowed to use this service?
  • Central Data Consolidation
  • Enables multiple applications to use the same
    source of information. Per application storage of
    central data is no longer required.

33
Middleware Services
  • Network Layer Encryption
  • Encryption of data as it is sent over the
    network.
  • File Encryption
  • Encryption of the contents of a file.
  • Digital Signing
  • The ability of a person or network device to
    encrypt a file or communication in a a way that
    ensures the file or communication came from them.
  • Federated Trust
  • Allows the delegation of Certificate Authorities
    to institutional, or more granular, levels while
    insuring a specific trust path between the
    delegated institutions.

34
Systems of Authority
  • Not specifically a Middleware technology but an
    important concept in middleware
  • System of Authority (SOA) An authoritative
    source of data
  • Universities have several SOAs
  • Student Information System
  • Human Resource System
  • Net Identity System
  • Associates/Affiliates System
  • Library Patrons Database
  • SOAs often contain duplicate information about
    individuals.

35
Problems with Systems of Authorities
  • Applications rarely have direct access to data
    stored in an SOA. This creates a data
    propagation problem.
  • When a person has duplicate information in more
    than one SOA, which do you use?
  • Attributes in SOAs are often needed for AuthZ
    decisions. How do applications get to and use
    this information?
  • Actions/changes in SOAs often lead to actions in
    other applications (granting or removing access,
    creating or deleting an account, etc.)

36
Identity Management (IdM)
  • Addresses the limitations of multiple,
    non-standardized SOAs
  • SOAs remain the source for authoritative data
  • IdM identifies business rules for consolidating,
    storing, accessing, and using SOA data in
    standard, reusable ways
  • Identity management is the set of business
    processes, and a supporting infrastructure, for
    the creation, maintenance, and use of digital
    identities The Burton Group

37
IdM Functions
  • Keith Hazelton, Identity Management,
    http//www.aarnet.edu.au/events/middle/2004/camp/i
    dm-intro-041209-01.ppt
  • Reflect
  • Track changes to institutional data from changes
    in Systems of Record and other IdM components.
  • Join
  • Establish and maintain person identity across SoR
  • Credential
  • Issue digital credentials to people in the
    community
  • Manage Affiliations
  • Manage affiliation and group information

38
IdM Functions
  • Manage Privileges
  • Manage privileges and permissions at system and
    resource level
  • Provision
  • Push IdM info out to systems and services as
    required
  • Deliver
  • Make access control/authorization information
    available to services and resources at run time
  • AuthZ
  • Make the allow deny decision independent of AuthN

39
A Few IdM Details
  • The Join function finds duplicate person
    entries and applies business logic to consolidate
    data
  • The result of the Join is typically stored in a
    Person Registry
  • Attributes beyond general person data but
    important for AuthZ/roles/affiliates often stored
    in a Groups Registry
  • Data from the Person and Groups registries
    usually made accessible to applications through
    LDAP

40
IdM Provides
  • Processed data from Systems of Authority
  • Data Consolidation
  • Central Data Integration
  • Processed data to create standard methods for
    AuthZ

41
IdM Specific Toolkit Grouper
  • Provides a common infrastructure for managing
    groups, affiliations, roles, and
    correlations
  • A toolkit to help create and manage the Group
    Registry
  • Intended to support
  • Near real time provisioning
  • Subgroups and compound groups
  • Extensible typing of groups
  • Automatic, configurable aging of groups and of
    individual memberships
  • Still very new Grouper 0.5 released 12/14/04

42
Grouper Provides
  • AuthZ management and standards for describing
    AuthZ information
  • Unclear if it will provide the ability for
    applications to directly query AuthZ information
    or if other technologies (Shibboleth/LDAP) access

43
LDAP
  • Lightweight Directory Access Protocol
  • LDAP servers provides storage for data
  • Quick lookups of data (faster than databases)
  • Standard, simplified query syntax
  • Schema describes the objects and attributes of
    objects stored in the server
  • LDAP query syntax provides applications the
    ability to find and retrieve data
  • ((ObjectClassUser)(snGalyon))
  • Standard schema for describing people objects is
    the inetOrgPerson object class

44
LDAP Advantages
  • Applications can share common data
  • Applications can extend the LDAP schema to store
    additional, application specific data
  • Only the LDAP repository needs to be updated
  • Redundant, load sharing solutions are possible
  • Can be used for AuthN (?)

45
LDAP for Higher Ed eduPerson
  • An extension of the inetOrgPerson LDAP object
    class to include attributes specific to Higher
    Education
  • Inludes attributes needed to facilitate other
    Middleware technologies (Shibboleth, PKI, etc.)

46
LDAP Provides
  • A storage point for the results of the IdM Join
    operation
  • Central Data Integration
  • AuthZ
  • AuthN (?)

47
Kerberos
  • The preferred AuthN solution to LDAP
  • Secure
  • Credentials never passed in clear text
  • Credentials not passed repeatedly, only to
    authenticate. Additional authentications do not
    pass credentials again.
  • Can allow single-sign-on between applications

48
Kerberos Internals
  • KDC The Key Distribution Center stores user
    credentials, called principals, and performs
    AuthN
  • tgt Once AuthN completed, a user receives a
    special ticket called a ticket granting ticket
    (tgt).
  • Tickets When a user want to access a kerberized
    service, the tgt is used to receive a specific
    service ticket
  • Kerberos Client Software installed on a client
    workstation that perfrom AuthN against a KDC and
    manages/requests service tickets
  • Kerberized Service A service that uses Kerberos
    for AuthN
  • Kerberized Application A client side application
    that knows how to communicate with a kerberized
    service

49
Kerberos Disadvantages
  • Kerberos clients must be installed, configured
    and maintained on all client workstations
  • Kerberized services are not always available.
    Even if available, they may require a client
    application that is not as fully featured as
    existing non-kerberized applications.

50
Kerberos Provides
  • System of Authority for user credentials
  • AuthN
  • Network Layer Encryption for some services

51
WebISO
  • Web Initial Sign-On
  • Primarily used for web application AuthN
  • Many institutions have built their own
  • Pubcookie
  • CAS
  • A-Select
  • CoSign
  • eIdentity WebAuth
  • WebISO solutions are designed with the same
    principles as Kerberos
  • Require secure network transmission of
    credentials
  • Do not allow applications to have direct access
    to credentials

52
WebISO Provides
  • AuthN
  • Minimal AuthZ in some implementations

53
Shibboleth
  • AuthN and AuthZ with a strong focus on privacy
  • Applications are not provided/preloaded with
    information. Instead they request information.
  • The information request process can be tightly
    controlled by end users allowing control over
    information release

54
Shibboleth Key Concepts
  • Federated Administration
  • Users indicate where they are from and
    authenticate against their home institution. A
    single service can allow logins from multiple
    institutions and each institution can manage
    their own logins.
  • Access Control Based on Attributes
  • AuthZ attributes can be requested by the target
    application and passed back from the institution.
  • Active Management of Privacy
  • End users can be prompted before releasing
    attribute information to an application. End
    users control their own privacy.

55
Shibboleth Inroads
  • Shibboleth has been adopted and implemented for
    several services
  • WebCT and Blackboard
  • Library journal systems
  • EBSCOhost databases available
  • JSTOR is testing
  • Napster
  • GridShib Shibboleth for GRIDs

56
Shibboleth Provides
  • AuthN (mainly supports Apache authentication but
    other components can be plugged in)
  • Delivery of AuthZ information to applications
  • Privacy since end users may control which of
    their attributes are sent to which applications

57
PKI
  • Public Key Infrastructure
  • Uses public/private keys to encrypt information
  • Communications can be encrypted
  • Files can be encrypted
  • Files can be digitally signed meaning a person or
    device can apply an encyrption signature to
    verify the creator/senders authenticity

58
PKI Internals
  • A Certificate Authority generates each
    person/device a public key and private key
  • Math tricks involving modulus math and very large
    prime numbers result in an encryption algorithm
    where anything encrypted using a public key can
    only be decrypted by the matching private key and
    vice versa

59
PKI Internals
  • Encryption
  • A user wanting to send someone else a document
    that only that person can read encrypts the
    document using the receivers public key. Only
    the recipient has access to their private key to
    decrypt the document.
  • Digital Signing
  • A user wanting to verify the authenticity of a
    sent document encrypts the document using their
    private key. The recipient can very the
    authenticity by decrypting with the senders
    public key.

60
PKI Challenges
  • How do applications and users find each others
    public keys?
  • How do you securely store the private keys?
  • How do you create a trust framework that allows
    delegated creation and management of keys?
  • How do you securely recover lost private keys?

61
HEBCA/FBCA
  • The Higher Ed Bridge Certificate Authority and
    Federal Bridge Certificate Authority address some
    of the PKI challenges
  • Allows trust relationships between institutions
    to allow Certificates issued from one institution
    to be accepted by another Federated Trust

62
S/MIME
  • A specific application of PKI
  • Allows for encryption and signing of e-mail
    messages
  • Potential killer app for PKI? Imagine reducing
    SPAM by requiring anyone sending you mail to
    digitally sign it first

63
PKI Provides
  • AuthN
  • Network Layer Encryption
  • File Encryption
  • Digital Signing
  • HEBCA/FBCA Provides
  • Federated Trust

64
Domain Specific Middleware
  • GRIDs
  • Middleware for high performance, collaborative,
    distributed computing environments
  • VidMid
  • Middleware for Video Conferencing and Video on
    Demand
  • MedMid
  • Middleware for healthcare

65
Middleware Technology and Service Summary
66
Middleware at Colorado State University
  • Systems of Authority
  • Identity Management
  • eIdentity
  • WEID
  • LDAP
  • Kerberos
  • WebISO
  • eIdentity WebAuth
  • Other Middleware

67
CSU Systems of Authority
  • ISIS, migrating to SCT Banner by Fall 2006, for
    student information
  • Oracle HR for employee information
  • The Associates Database for all other
    non-students, non-employees
  • eIdentity for AuthN credentials

68
CSU Identity Management
  • eIdentity has created a single username/password
    for each individual associated with CSU.
  • Central Unix services
  • Windows Active Directory (in some cases)
  • WebCT
  • RamPoint
  • RamWeb
  • Others
  • WEID serves as a scaled down version of a Person
    Registry

69
CSU LDAP
  • Three LDAP Servers at Colorado State
  • White Pages LDAP server used for e-mail client
    directory data, web page person look-ups
  • No Credentials
  • The RamPoint portal maintains a proprietary LDAP
  • Does not use the correct structure
  • The Windows Active Directory serves as an LDAP
    server
  • Is not overly extensible
  • None of the current LDAP directories at CSU meet
    the full Internet2 Middleware directory
    recommendations

70
CSU Kerberos
  • The Windows Active Directory can serve as a KDC.
    The RamPoint portal currently uses the AD KDC for
    AuthN.
  • Working groups have twice met and discussed
    implementing a true MIT Kerberos V5 KDC but
    neither attempt resulted in a production
    implementation.

71
CSU WebISO
  • eIdentity WebAuth is the currently recommended
    WebISO solution at CSU
  • Allows dynamic web applications at CSU to use
    eIdentities for AuthN
  • ColdFusion
  • ASP
  • Java
  • PERL

72
CSU Other Middleware
  • Portal RamPoint in production Fall 2004.
    Single web presence for numerous web resources at
    Colostate State.
  • Shibboleth Nothing yet, a few discussions have
    started. The College of Engineering has
    successfully tested an implementation but there
    are not currently plans for production.
  • PKI Nothing yet.

73
CSU Future Initiatives
  • Banner integration with eIdentity/WEID
  • Need to evaluate current state of affairs and
    begin planning direction for
  • Near Term
  • LDAP
  • Kerberos
  • WebISO
  • Longer Term
  • Shibboleth
  • PKI
  • Group Registry

74
Resources
  • Internet2 Middleware
  • http//middleware.internet2.edu/
  • nmi-edit
  • http//www.nmi-edit.org/
  • NSF Middleware Initiative
  • http//www.nsf-middleware.org/
  • eIdentity/WEID/eIdentity WebAuth
  • http//www.colostate.edu/Services/acns/eid/index.h
    tml
Write a Comment
User Comments (0)
About PowerShow.com