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