Michael R. Gettes
Principal Technologist
Georgetown University gettes@Georgetown.EDU
http://www.georgetown.edu/giia/internet2
“Middleware is the intersection of what the
Network Engineers and the Application
Programmers don’t want to do”
- Ken Klingenstein
Chief Technologist, Univ. of Colorado, Boulder
Director, Internet2 Middleware Initiative
Lead Clergy, MACE
PS of LC
Middleware makes “Transparently use” happen
Internet2 Middleware
If the goal is a PKI, then you need to consider:
• Identifiers (SSNs and other untold truths)
• Identification & Authen process (“I & A”)
• Authentication systems (Kerberos, LDAP, etc)
• Lawyers, Policy & Money (lawyers, guns & $$$)
• Directories (and the applications that use them)
• Certificate Mgmt System (CMS) Deployment
– CA Certficate, Server Certificates, Client
Certificates
• Authorizations (a real hard problem, Roles, etc)
3
Internet2 Middleware
• Building Application/System Infrastructure
• What is missing in Internet 1
• Not “Network Security” (wire level)
• Assumes the wire is insecure
• Assumes the Application is insecure
If security was easy, everyone would be doing it.
• http://middleware.internet2.edu
4
National Science Foundation
NMI program
• $12 million over 3 years
• www.nsf-middleware.org
• Middleware Service Providors, Integrators,
Distributors
• GRID (Globus)
• Internet2 + EDUCAUSE + SURA
• May 2002 – first set of deliverables from all parties
5
MACE
Middleware Architecture Committee for Ed.
IT Architects – meet often – no particular religious affiliations
MACE-DIR – eduPerson, Recipe, DoDHE
MACE-SHIBBOLETH – global AuthN/Z
MACE-PKI
HEPKI (TAG/PAG/PKI-Labs)
MACE-WebISO – Web Initial Sign-on
VID-MID – Video Middleware (H.323/SIP)
MACE-FDRM – Federated Digital Rights Management
NMI - NSF Middleware Initiative
6
MACE-ochists
RL “Bob” Morgan, Chair,
Washington
Steven Carmody, Brown
Michael Gettes,
Georgetown
Keith Hazelton,
Wisconsin
Paul Hill, MIT
Ken Klingenstein,
Colorado
Mark Poepping, CMU
Jim Jokl, Virginia
David Wasley, UCOP
Von Welch, ANL/Grid
Scott Cantor, Ohio St
Bruce Vincent,
Stanford
Euro: Brian Gilmore & Ton
Verschuren, Diego Lopez
7
A Map of Middleware Land
8
MACE-DIR
Keith Hazelton, Chair, Wisconsin
• eduPerson objectclass
• LDAP-Recipe
• Dir of Dirs for Higher Education (DoDHE)
• Shibboleth project dir dependencies
• Meta Directories – MetaMerge
• Groups (Dynamic vs. Static; Management)
• Afilliated Directories (Stitched, Data Link)
• http://middleware.internet2.edu/directories
9
MACE-DIR: eduPerson 1.0 (1/22/01 release)
• MACE initiated (Internet2 + EDUCAUSE)
• Globally interesting useful attributes
• Get community buy-in, must use it also eduPersonAffiliation (DoDHE), eduPersonPrincipalName (Shibboleth)
• “Less is more”, how to use standard objectclasses
• http://www.educause.edu/eduperson
10
Included as part of the NSF Middleware
Initiative (NMI) Release 1.0 May 7 th, 02 eduPerson 1.0 is the production version,
1.5 status is “released for public review” (RPR)
Next NMI release will include final 1.5 based on review period discussions
11
Changes from 1.0:
• Introductory section added
• RFC2252 style definitions included for the eduPerson object class itself and for each of the eduPerson attributes.
• Notes on additional attributes from existing object classes, existing notes clarified, syntax and indexing recommendations updated.
12
Two new attributes: eduPersonPrimaryOrgUnitDN eduPersonEntitlement
• Simple case: value is the name of a contract for licensed resource
• http://xstor.com/contract1234
• Values of eduPersonEntitlement can be URLs or
URNs
13
eduPersonEntitlement
• Values of eduPersonEntitlement can be URLs or
URNs
– http://www.w3.org/Addressing/
– RFC2396 Uniform Resource Identifiers
– RFC2141 Uniform Resource Names
• URNs to allow federation of name creation without name clashes.
– urn:mace:brown.edu:foo
• mace-submit@internet2.edu for information on
URN registration
14
eduOrg 1.0 released as “Experimental” object class
• Basic organizational info attributes from X.520
– Telecomm, postal, locale
• eduOrgHomePageURI
• eduOrgIdentityAuthNPolicyURI
• eduOrgLegalName
• eduOrgSuperiorURI
• eduOrgWhitePagesURI
15
•
•
•
•
16
•
•
•
•
•
•
•
17
• Groups, Groups, Groups
• Static, Dynamic, app issues, builds on “NMI Groups Doc”
• E-Mail Routing considerations
• Attribute firewalling, Sendmail, app issues
• eduPersonOrgDN and eduPerson{Primary}OrgUnitDN
• Original Intent for eduPerson 1.0 and Primary
• RDN Issues (a must read)
• Software reference (small, needs to grow)
18
MACE-DIR:
Directory of Directories for Higher Education
Web of Data vs. Web of People
Prototype: April, 2000 (by M. Gettes)
Highly scalable parallel searching
• Interesting development/research problems
• Configs, LDAP libraries, Human Interface
Realized the need to:
• Promote eduPerson & common schema
• Promote good directory design (recipe)
Work proceeding – Sun Microsystems Grant http://middleware.internet2.edu/dodhe
19
MACE-DIR:
DoDHE and LDAP Analyzer
Todd Piket, Michigan Tech
Web based tool to empirically analyze a directory eduPerson compliance
Indexing and naming
LDAP-Recipe guidance (good practice)
Beta: http://morpheus.dcs.it.mtu.edu/~tcpiket/dodhe
20
• Technical Advisory Board
• eduOrg, eduPerson, edu???????
• Shibboleth and other related work
• Roles (RBAC)
• Group Implementations (Eileen Shepard, BC; Tom Barton, Memphis)
• Blue Pages
• LDAP-Recipe (next?)
• Affiliated Directories (Rob Banz, UMBC)
• pkiUser/pkiCa, Bridge CA, etc…
• Video Middleware (commObject{Uri} OCs)
• GRID interoperability
• Directory Policy
21
EduOrg “blue page” entries
EduOrgUnit 1.0 object class and attributes
Affiliated directories scenarios
• Identity management in Health Sciences
• Assembling info on the fly
• Data/Metadata bundles as units of exchange
• Exploring with our Technical Advisory Board
22
MACE-SHIBBOLETH
Steven Carmody, Brown, Chair
A Biblical pass phrase – “password”
• Get it right or “off with your head”
• Inter-institutional
Authentication/Authorization
• Web Authorization of Remote Sites with
Local Credentials
• Authentication via WebISO
• October, 2002 – Version 1.0 with NMI
• http://middleware.internet2.edu/shibboleth
23
MACE-WEBISO
Web Initial Sign-on
Based on University of Washington “pubcookie” implementation
Washington will developing and steward with external funding
JA-SIG uPortal, Blackboard, WebCT, Shibboleth – will do or are highly likely to do.
http://www.washington.edu/computing/pubcookie
24
VID-MID
Video Middleware
Authentication and Authorization of H.323 sessions.
Client to Client
Client to MCU
Directory enabled
How to find video enabled people?
What is necessary to describe video capabilities?
Will likely extend to IP Telephony and so on…
25
Policy
Technical
26
HEPKI
TAG – Technical Activities Group
• Jim Jokl, Chair, Virginia
• Mobility, Cert Profiles, PKI-Lite, etc, etc, lots of techno
PAG – Policy Activities Group
• Default Chair, Ken Klingenstein, Colorado
• Knee-deep in policy, HEBCA, Campus, Subs+RP
PKI Labs (AT&T) – Neal McBurnett, Avaya
• Wisconsin-Madison & Dartmouth
• Industry, Gov., Edu expert guidance http://www.educause.edu/hepki
27
• Survivable PKI
• Cross Certificates allow for
“one/two-way policy”
• Directories are critical in BCA world.
http://www.educause.edu/
Transforming Education Through Information Technologies
Common Solutions Group, January, 2002 (Sanibel Island)
28
29
DOD PKI
Illinois PKI
CANADA
PKI
Federal Bridge CA
NASA PKI
NFC PKI http://www.educause.edu/
Transforming Education Through Information Technologies
Higher Education Bridge CA
University
PKI
Common Solutions Group, January, 2002 (Sanibel Island)
Special Relationships
UNIVERSITY
UNIVERSITY
UNIVERSITY
Georgetown
University
. . .
Peer-to-peer
USA
Higher Education
BCA
University of
W ashington
Special
Relationships
Peer-to-peer
USA Government
Federal
BCA
Peer-to-peer
USA Health Care
"Health Key"
BCA
UNIVERSITY
UNIVERSITY
University of
Edinburgh
Peer-to-peer
European
Higher Education
BCA
NIH
Mayo
Clinic
DoD
NASA
NCHICA
30
Bridge CAs
• Higher Education Bridge CA – FBCA peering
• We have a draft HEBCA CP (Net@EDU PKI WG) FBCA Compatible
• How many HEBCAs? (EDUCAUSE!)
• Do we really understand PKI implementations with respect to policy needs? (proxy certificates, relying party agreements, name constraints, FERPA, HIPAA, who eats who?)
• BCA seems to be the most promising perspective. Will each person be a BCA?
• Does ALL software (Client/Server) need to be changed?
• Mitretek announces new BCA deployment model 2/15/2001
• Scalable & deployable
• Server plug-ins make client changes less likely
31
The PKI Puzzle
Fed Bridge
Ser v er
Cer t s
CREN Root CA
Vendor
Resources
Campus
Resources
Shib
Campus
PK I
Campus
Sy st ems
Direct ory
Educause HE Bridge
Campus
PKI
Campus
Sy st em s
Dir ec t o r y
EDU
PK I
Hierarchy
COM
PK I
Hierarchy
Medical
PK I
Hierarchy
By David Wasley, UCOP
PKI provides:
• St rong Aut hent icat ion
• Flexible Aut horizat ion
• Secure Digit al Signat ure
• Powerful Dat a Securit y
32
domainComponent (DC=) Naming
• Traditional X.500 naming: cn=Michael R Gettes, ou=Server Group, ou=UIS, o=Georgetown University, c=US
• domainComponent (DC) naming: uid=gettes,ou=People,dc=georgetown,dc=edu
• HEPKI is issuing guidance and advice on DC= naming
33
Attributes for PKI
Store them in a Certificate?
• Attributes persist for life of Certificate
• No need for Directory or other lookup
– The Certificate itself becomes the AuthZ control point
Store them in a Directory?
• Very light-weight Certificates
• Requires Directory Access
• Long-term Certificate, Directory is AuthZ control point.
How many Certificates will we have?
Pseudonymous Certificates
34
Steven Carmbody, Brown University
Project Leader, Shibboleth
Michael R. Gettes, Georgetown University
Shibboleth Architecture
Concepts - High Level
Browser
Pass content if user is allowed
Authorization Phase
Authentication Phase
First Access - Unauthenticated
Origin Site
Target Site
Target
Web
Server
37
Shibboleth Architecture
Concepts (detail)
Entitlements
Attribute
Server
Ent Prompt
Web
Login
Server
Req Ent
Browser
Auth OK
Authentication
Second Access - Authenticated
Pass entitlements for authz decision
Target
Web
Server
Origin Site
Target Site
38
Shibboleth Architecture
39
Shibboleth Components
40
Descriptions of services
1. local authn server - assumed part of the campus environment
2. web sso server - typically works with local authn service to provide web single sign-on
3. resource manager proxy, resource manager - may serve as control points for actual web page access
4. attribute authority - assembles/disassembles/validates signed XML objects using attribute repository and policy tables
5. attribute repository an LDAP directory, or roles database or….
6. Where are you from service - one possible way to direct external users to their own local authn service
7. attribute mapper - converts user entitlements into local authorization values
8. PDP - policy decision points - decide if user attributes meet authorization requirements
9. SHAR - Shibboleth Attribute Requestor - used by target to request user attributes
41
Shibboleth Flows Draft
42
Shibboleth Architecture --
Managing Trust
Attribute
Server
Browser
Origin Site
TRUST
Shib engine
Target
Web
Server
Target Site
43
Personal Privacy
Web Login Server provides a pseudononymous identity
An Attribute Authority releases Personal Information associated with that pseudnonymous identity to site
X based on:
• Site Defaults
– Business Rules
• User control
– myAA
• Filtered by
– Contract provisions
Site
Defaults
My AA
Contact Provisions
Browser
User
44
45
Drivers of Vapor Convergence
Shibboleth Inter-Realm AuthZ We all get Web SSO for
Local Authentication and
OKI/Web Authentication an Enterprise
Authorization Framework
JA-SIG uPortal Authen
Local Web SSO Pressures with an Integrated Portal that will all work interinstitutionally!
47
Grids
Middleware Inputs & Outputs
OKI
Licensed
Resources
Embedded
App Security
JA-SIG & uPortal
Inter-realm calendaring futures
Shibboleth, eduPerson, Affiliated Dirs, etc.
Enterprise authZ
Campus
Web SSO
Enterprise
Directory
Enterprise
Authentication
Legacy
Systems
48
The Liberty Alliance www.project-liberty.org
Sun Microsystems, American Express, United Airlines, Nokia,
MasterCard, AOL Time Warner, American Airlines, Bank of
America, Cisco, France Telecom, Intuit, NTT DoCoMo,
Verisign, Schlumberger, Sony …
Initiated in September 2001.
Protect Privacy, Federated Administration, Interoperability,
Standards based but requires new technology, hard problems to solve, a Network Identity Service
Funny, doesn’t this stuff sound familiar?
50
Techniques for Product
Independence
Good/Evil – make use of cool features of your product.
• Does this make it more difficult or impossible to switch products later?
• Does this make you less interoperable?
Standard?
• Does this limit your ability to leverage common solutions?
All the above applies to enabled apps as well.
52
Groups, Groups, Groups
Static vs. Dynamic (issues of large groups)
• Static Scalability, performance, bandwidth
• Dynamic Manageability (search based, but search limits)
Is there something neutral?
Indexed Static Groups
• MACE-DIR consideration (Todd Piket, MTU)
• Index unique/member
• The likely approach, IMHO, doesn’t inhibit dynamic stuff
Group Math
(& (group=faculty)(!(group=adjunct)) (member=DN) )
53
Roles
Is this an LDAP issue?
• MIT roles DB – a roles registry
Are groups good enough for now?
• Probably not, see next
Are your apps prepared for this? Maybe they need some service to consult? Will
Shibboleth help here?
Vendors have proprietary solutions.
54
Stitching disparate directories
How to relate to distinct directories and their entries.
Kjk@colorado & kjk@ViDe -- are they the same?
Locate someone in a large directory (DoDHE) and then switch to their video abilities
Suggestion: define new object of a “data source directory”.
Associate it with a Cert. Send signature of all data elements for an object, store in same. This allows for digital trust/verification. Still working this out. Not much work in this space? (the affiliated dirs problem)
X.520 AttributeIntegrityInfo Attribute – will it suffice?
55
A Campus Directory Architecture
Enterprise applications dir metadirectory enterprise directory departmental directories
OS directories
(MS, Novell, etc) directory database registries source systems border directory
56
Michael R. Gettes
Principal Technologist
Georgetown University
Gettes@Georgetown.EDU
How Deep?
Background
Site Profile - configuration
Applications
General Operational Controls
Schema
Access Lists
Replication
Related Directories
LDAP-Recipe – http://middleware.internet2.edu
58
Site Profile dc=georgetown,dc=edu
Netscape/iPlanet DS version 4.16
• 2 Sun E250 dual cpu, 512MB RAM
105,000 DNs (25K campus, others = alums + etc)
Directory + apps implemented in 7 months
Distinguished names: uid=x,ou=people
• DC rap, “Boom shacka lacka”
• Does UUID in DN really work?
NSDS pre-op plugin (by gettes@Princeton.EDU)
• Authentication over SSL; Required
• Can do Kerberos – perf problems to resolve
1 supplier, 4 consumers
59
Authentication:
Overall Plan @ Georgetown
Currently, Server-Side PKI self-signed
Best of all 3 worlds
• LDAP + Kerberos + PKI
– LDAP Authentication performs Kerberos Authentication out the backend. Jan. 2001 to finish iPlanet plug-in.
• Credential Caching handled by Directory.
• Cooperative effort – Georgetown, GATech, Michigan
– All directory authentications SSL protected. Enforced with necessary exceptions
• Use Kerberos for Win2K Services and to derive X.509 Client
Certificates
• One Userid/Password (single-signon vs. FSO)
60
Applications
Mail routing with Sendmail 8.12 (lists also)
Netscape messaging server v 4.15 (IMAP)
• WebMail profile stored in LDAP
Apache server for Netscape roaming (no SSL)
Apache & Netscape enterprise web servers
Blackboard CourseInfo Enterprise 5.5.1
Whitepages: Directory Server GateWay
DSGW for priv’d access and maintenance
61
Applications (Continued)
Remote access with RADIUS (funk).
• No SSL (3/2000); proper LDAP binds (fix 8/2000)
• Authenticates and authorizes for dial-up, DSL and VPN services using RADIUS called-id.
• We want to use this for other access control such as Oracle
62
User calls
202-555-1110
RADIUS + LDAP
RADIUS server
CalledId from
NAS is mapped to guRadProf
NAS
(terminal server)
Dialup
Users
Directory
Server
Netid = gettes guRadProf = 2025550001 guRadProf = 2025551110 guRadProf = OracleFin
LDAP Filter is: guRadProf =
2025551110
+ NetID = gettes
63
Applications (Continued)
Alumni services (HoyasOnline).
• External vendor in Dallas, TX (PCI).
• They authenticate back to home directories. Apache used to authenticate and proxy to backend
IIS server.
• Email Forwarding for Life
64
TMS
OS/390
LDAP Master
LDAP
Replica
HRIS
NET ID
Other local hosts
GU provided selfservice applications
PCI (Dallas)
Vendor-provided services
SIS
Alumni
Gratuitous
Architectural
Graphic (GAG)
WWW hoyasonline
Content
Client
Browser
Way
Down
In Texas
65
Applications (Continued)
Access+
• Georgetown developed
• Web interface to legacy systems using Unix frontend to custom made mainframe tasks. Many institutions have re-invented this wheel.
• LDAP authentication, mainframe doesn’t yet do
SSL. Always exceptions to rules.
• Student, Faculty, Staff, Directory/Telephone
Access+ Services. This technique keeps mainframe alive. (good or bad?)
66
Applications (Continued)
Specialized support apps
• Self service mail routing
• Help Desk: mail routing, password resets, quota management via DSGW
• Change password web page
Person registry populates LDAP people data, currently MVS (mainframe) based.
PerLDAP used quite a bit – very powerful!
(make sure version >= 1.4)
Now moving to Net::LDAP
67
Applications (Continued)
Georgetown Netscape Communicator Client
Customization Kit ( CCK ).
• Configured for central IMAP/SSL and directory services.
• Handles versions of profiles. Poor man’s
MCD
Future: more apps! Host DB, Kerberos integration, win2k/ad integration?, Oracle
RADIUS integration, Automatic lists,
Dynamic/static Groups, Top-Secret, Bb – further integration.
68
General Operational Controls
Size limit trolling (300 or 20 entries?)
Lookthru limit (set very low)
Limit 3 processors for now, MP issues still! (v4)
100MB footprint, about 8000 DNs in cache
• Your mileage will vary – follow cache guidelines documented by iPlanet.
24x7 operations
What can users change?? (Very little)
No write intensive applications
69
General Ops Controls (cont…)
Needed for email clients
Anonymous access is good if you resolve FERPA and other data access issues.
70
Schema: Design & Maint
Unified namespace: there can be only one!
Schema design and maintenance
• Space/time tradeoffs on indexing
• Eduperson 1.0 vs. guPerson
• guRestrict, guEmailBox, guAffil, guPrimAfil
• guPWTimebomb, guRadProf, guType, guSSN
• Relationships (guref)
Maintained by ldif file using ldapmodify
71
Access Lists
Design & Maintenance
Access lists: design & maintenance
• Buckley(FERPA) protection & services
• Priv’d users and services
• userPassword & SSN
Maintained by file using ldapmodify
Working on large group controls at GU
• Groups vs. Roles
• Likely easy to populate, hard to design & implement
72
Replication
Application/user performance
Failover, user and app service
Impact of DC= naming (replica init)
• Fixed in 4.13 and iDS 5.0
Monitoring: web page and notification
Dumper replica – periodic LDIF dumps
Backups? We don’t need no stinkin’ backups!
• Vendor Specific
• No good solution for backups (iPlanet)
• IBM uses DB2 under the covers
• Novell?
73
Replication (Continued)
Application/users config for mult servers
Deterministic operations vs random
Failover works for online repairs
Config servers are replicated also
10 to 1 SRA/CRA ratio recommended
Cannot cascade with DC= (iPlanet)
• Cascading is scary to me
74
Replica Structure
WHITEPAGES
MAILHOST
Users
Users
MASTER POSTOFFICE
Web Servers
Normal Ops
DUMPER
NetID Registry
Failure Ops
75
Netscape Console
• Java program (FAT client).
• Used to create, configure and monitor Netscape servers.
• Preferred the web page paradigm of the version
3 products.
• Has enough bugs that it is only used by server admins, not for mere mortals.
• Demo??? (nope)
76
Other Directories
Novell – GU abandoning GroupWise.
Active directory??? Ugh!!!
• Static Groups Only
• Strict Tree Structure for Group Policy
• No plans for MS to change this…
77
Buyer Beware
• LDAP is LDAP is LDAP – yeah, right!
• “Sure! We support LDAP!” What does that mean?
• Contract for functionality and performance
• Include your Directory/Security Champion!!!
• Verify with other schools – so easy, rarely done.
• Beware of products that specify Dir Servers
• Get vendor to document product requirements and behavior. You paid for it!
78
Microsoft Win2K Integration
Project Pismere http://web.mit.edu/pismere
MIT, CMU, Michigan, Stanford, Colorado, etc…
One way trust from MIT KDC to Win2K KDC
The devil we know
Metamerge can play an important role
Handle DHCP/DNS as your site wishes
79
Win2K & Enterprise Integration
W2K Kerb
AuthN
3
2
One-way X-realm Trust
Identity mgmt
1
W2K Active
Directory
Meta-Dir Function
MetaMerge?
Ent Kerb
AuthN
Enterprise
Directory
80
Current Research (examples)
GROUPER
A special LDAP server (OpenLDAP) engineered to handle group math operations against the enterprise directory for applications that are not group savvy.
Application -> get group BLAH -> GROUPER -> combine 15 groups and remove those in the exclusion group -> give back combined static object as group BLAH
82
Certificate Parsing Server
Peter Gietz - a draft to describe X.509 certificates as plain old directory objects. Finding certificates becomes easy for directory aware applications. Use PKI operations on the cert you select to verify it.
David Chadwick - a Certificate Parsing Server (CPS). Like
GROUPER but only works on add/delete/modify operations and stores cert objects as child objects as well as userCertificate attributes where they are now.
This should have a dramatic impact on Bridge CA model operations.
83
0
7
4
3
8
11
2
3
0
0
4
1
1
6
• eduOrg, eduPerson, edu(other …)
• Shibboleth
• Roles (RBAC)
• GIG (Group Implementer’s Guide)
• GROUPER, RI-Bot, GASP
• Blue Pages
• LDAP-Recipe (next?)
• Affiliated Directories
• HEBCA, Bridge PKI, etc…
• Video Middleware (commObject)
• GRID AuthN campus integration
• GRID AuthZ campus integration
• Medical Middleware (MedMid)
• Operational Issues (perf/mon)
0
2
5
4
5
1
2
1
1
4
11
4
1
1
5
• Directory Policy
• PKI Policy
• Identity Mgmt Practices
• Metadirectories
• Dir of Dirs Higher Ed (DoDHE)
• LDAP Analyzer
• The Art of Directories/Databases
• PKI-Lite and S/MIME
• Early Harvest for App Developers
• Digital Rights Management (DRM)
• Outreach and Dissemination
• N-Tier Systems (portals)
• Filesystems
• Selling it
• Project Mgmt
84