Embed Size (px)
Citation preview
Mware 101
Ken Klingenstein,
Project Director, Internet2 Middleware Initiative
Chief Technologist, University of Colorado at Boulder
Syllabus
Other courses, acks
The larger picture
The Basic Technologies• Identifiers
• Authentication
• Directories
PKI
Current Activities to watch
Other middleware sessions
Mware 101 - big picture,identifier basics, authn,
directory concepts,PKI overview
Mware 202 - identifiers+,directory deployments
PKI 101 - apps, certs, profiles, policies,
trust models
HEPKI- PAG -current policy activities
Middleware 301 -metadirectories, registries,
authorization
Early Adopters
technology --- policy
LDAP Recipe
HEPKI- TAG -current technical activities
Multicampus BoF
Academic MedicalMiddleware
International Issuesin Middleware
Labs:EdupersonShibbolethDoD, apps
Middleware and the Grid
MetadirectoriesBoF
Acknowledgements
Mace and the working groups
Early Harvest - NSF catalytic grant and meeting
Early Adopters
Higher Ed partners -campuses, EDUCAUSE, CREN, AACRAO, NACUA, etc
Corporate partners - IBM, ATT, the Burton Group, Avaya, et al...
Gov’t partners - including NSF and the fPKI TWG
Mace (Middleware Architecture Committee for Education)
Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher ed
Membership - Bob Morgan (UW) Chair, Steven Carmody (Brown), Michael Gettes (Georgetown), Keith Hazelton (Wisconsin), Paul Hill (MIT), Jim Jokl (Virginia), Mark Poepping (CMU), David Wasley (California)
Current working Groups• Mace-Dir Mace-med
• Shibboleth - inter-institutional resource sharing
Early Harvest
NSF funded workshop in Fall 99 and subsequent activities
Defined the territory and established a work plan
Best practices in identifiers, authentication, and directories (http://middleware.internet2.edu/best-practices.html)
http://middleware.internet2.edu/earlyharvest/
Early Adopters: The Campus Testbed Phase
A variety of roles and missions
Commitment to move implementation forward
Provided some training and facilitated support
Develop national models of deployment alternatives
Address policy standards
Profiles and plans are on I2 middleware site.
Early Adopter Participants
Dartmouth
U Hawaii
Johns Hopkins
Univ of Maryland, BC
Univ of Memphis
Univ of Michigan
Michigan Tech Univ
Univ of Pittsburgh
Univ of Southern Cal
Tufts Univ
Univ of Tennessee, Memphis
Remedial IT architecture
The proliferation of customizable applications requires a centralization of “customizations”
The increase in power and complexity of the network requires access to user profiles
Electronic personal security services is now an impediment to the next-generation computing grids
Inter-institutional applications require interoperational deployments of institutional directories and authentication
What is Middleware?
specialized networked services that are shared by applications and users
a set of core software components that permit scaling of applications and networks
tools that take the complexity out of application integration
sits above the network as the second layer of the IT infrastructure
the intersection of what networks designers and applications developers each do not want to do
Specifically,
Digital libraries need scalable, interoperable authentication and authorization.
The Grid as the new paradigm for a computational resource, with Globus the middleware, including security, location and allocation of resources, scheduling, etc.
Relies on campus-based services and inter-institutional standards
Instructional Management Systems (IMS) need authentication and directories
Next-generation portals want common authentication and storage
A Map of Middlewareland
Network-layer middleware
Core middleware
AcademicComputingUpperware
ResearchOriented
Upperware
BusinessUpperware
The Grid
a model for a distributed computing environment, addressing diverse computational resources, distributed databases, network bandwidth, object brokering, security, etc.
Globus (www.globus.org) is the software that implements most of these components
Needs to integrate with campus infrastructure
Gridforum (ww.gridforum.org) umbrella activity of agencies and academics
Look for grids to occur locally and nationally
Core Middleware
Identity - the first characteristics of who you (person, machine, service, group) are
Authentication - how you prove or establish that you are that identity each time you connect
Directories - where the rest of an identity’s characteristics are kept
Authorization - what an identity is permitted to do
PKI - emerging tools for security services
OIDs
numeric coding to uniquely define many middleware elements, such as directory attributes and certificate policies.
Numbering is only for identification (are two oids equal? If so, the associated objects are the same); no ordering, search, hierarchy, etc.
Distributed management; each campus typically obtains an “arc”, e.g. 1.3.4.1.16.602.1, and then creates oids by extending the arc, e.g 1.3.4.1.16.602.1.0, 1.3.4.1.16.602.1.1, 1.3.4.1.16.602.1.1.1)
Getting an OID
apply at IANA at http://www.iana.org/cgi-bin/enterprise.pl
apply at ANSI at http://web.ansi.org/public/services/reg_org.html
more info at http://middleware.internet2.edu/a-brief-guide-to-OIDs.doc
Cuttings: Identifiers
“Any problem in Computer Science can be solved with another level of indirection”
• Butler Lampson
“Except the problem of indirection complexity”• Bob Morgan
Major campus identifiers
UUID
Student and/or emplid
Person registry id
Account login id
Enterprise-lan id
Student ID card
Netid
Email address
Library/deptl id
Publicly visible id (and pseudossn)
Pseudonymous id
General Identifier Characteristics
Uniqueness (within a given context)
Dumb vs intelligent (i.e. whether subfields have meaning)
Readability (machine vs human vs device)
Affordance (centrally versus locally provided)
Resolver approach (how identifier is mapped to its associated object)
Metadata (both associated with the assignment and resolution of an identifier)
Persistence (permanence of relationship between identifier and specific object)
Granularity (degree to which an identifier denotes a collection or component)
Format (checkdigits)
Versions (can the defining characteristics of an identifier change over time)
Capacity (size limitations imposed on the domain or object range)
Extensibility (the capability to intelligently extend one identifier to be the basis for another identifier).
Important Characteristics
Revocation - can the subject ever be given a different value for the identifier
Reassignment - can the identifier ever be given to another subject
Privileges - what accesses does the authenticated identifier have
Opacity - is the real world subject easily deduced from the identifier - privacy and use issues
Identifier relationships
Person registry ID
Email address
Library ID
Acct login Pseudo ID
Student ID
PubVis ID
Enterprise-LAN ID
DepartmentalIDs
UUIDEmpl ID
ISO card ID
Identifier data flows
SIS Personnel Others Central IT
Email address
Acct login
Person reg
Pseudo ID
Student ID
Identifier Mapping
Map campus identifiers against a canonical set of functional needs
For each identifier, establish its key characteristics, including revocation, reassignment, privileges, and opacity
Shine a light on some of the shadowy underpinnings of middleware
Examples
Email related identifiers• Email outward rewrite address
• Published email address
• Aliases
• Actual in-box location
Authentication Options
Password based• Clear text
• LDAP
• Kerberos
Certificate based
Others - challenge-response, biometrics
Cuttings: Authentication
user side management - crack, change, compromise
central side password management - change management, OS security,
first password assignment - secure delivery
policies - restrictions or requirements on use
User side password management
Precrack new passwords
Precrack using foreign dictionaries as well as US
Confirm new passwords are different than old
Require password change if possibly compromised
Use shared secrets or positive photo-id to reset forgotten passwords
Password aging seems to do more harm than good
Central side password management
Lockout access after successive failed login attempts• insert a time delay before unlocking
• require a human contact before unlocking
No clear test storage or capture; use shadow password files
Maintain audit trails
Proper su and change management processes
First password assignment
USmail a one-time password (time-bomb)
In-person with a photo id (some require two)
For remote faculty or staff,, an authorized departmental rep in person coupled with a faxed photo-id.
Initial identification/authentication will emerge as a critical component of PKI
Policies
Some institutions restrict the use of an identifier/authentication pair to secure environment
Some require the use of certain identifier/authentication services for particular applications
Some suggest the use of distinct passwords for internal and external accounts
Some strongly suggest that users change their passwords after use from external, unsecured environments
Beyond Passwords
Shared secrets
Challenge-response (S/Key, Smart Card) - for certain secure accounts
X.509 - still has some distance to go; might want separate functionalities
Biometrics - no one using yet
Directory Issues
Applications
Overall architecture• Chaining and referrals
• Redundancy and Load Balancing
• Replication, synchronization
• Directory discovery
The Schema and the DIT• attributes, ou’s, naming, objectclasses, groups
Use - searching, indexing
Management• clients, delegation of access control, data feeds
Directory-enabled applications
Account management
Web access controls
Portal support
Calendaring
Grids
A Campus Directory Architecture
Metadirectory
Enterprisedirectory
DirDB
Departmentaldirectories
OS directories(MS, Novell, etc)
Borderdirectory
Registries Sourcesystems
Key Architectural Issues
Interfaces and relationships with legacy systems
Performance in searching
Access control
Load balancing and backups are emerging but proprietary
Discovery - New DNS hack to serve directory locations
Schema Best Practices
People, machines, services
Be very flat in people space
Keep accounts as attributes, not as an ou
Replication not a primary driver in schema
Group policies not a primary driver in schema
Naming Issues
RDN
Other keys to index
Creating and preserving unified name spaces
dc= as a name versus c=, ou=
the root name
RDN may well be UUID
Attribute Best Practices
Inetorgperson, Eduperson, localperson
Never repurpose an RFC defined field; add new attributes
Adding attributes is easier than thought
Keep schema checking on, unless it is done in the underlying database; watch performance
Most LDAP clients do not treat multi-valued attributes well, but doing multiple fields and separate dn’s no better.
Groups Best Practices
Limit size and use (e.g. no email) but allow user creation
Web access to group lists avoids multivalue problems
Supply key institutional groups (class lists, Y2K coords) centrally
Performance issues need to be watched
Groups Uncertainties
no consensus on where to store • as a schema attribute for individuals
• as a separate entry within overall hierarchy
some variations on naming• within user name space
• may augment with group or owner indicator
Management Issues
No trolling permitted; more search than read
LDAP client access versus web access
How and when to update
LDIF likely to be replaced by XML as exchange format
Delegation of control
“See also”, referrals, replication, synchronization in practice
Replication should not be done tree-based but should be filtered by rules and attributes
Further information
PKI Components
Identifiers and authentication
X.509 v3 certs
Certificate Revocation Lists and OCSP
Cert management - generating certs, using keys, archiving and escrow, etc.
Directories - to store certs, and public keys and maybe private keys
Trust models and I/A
Cert-enabled apps
PKI : A few observations
Think of it as wall jack connectivity, except it’s connectivity for individuals, not for machines, and there’s no wall or jack…But it is that ubiquitous and important
Does it need to be a single infrastructure? What are the costs of multiple solutions? Subnets and ITP’s...
Options breed complexity; managing complexity is essential
A few more...
IP connectivity was a field of dreams. We built it and then the applications came. . Unfortunately, here the applications have arrived before the infrastructure, making its development much harder.
Noone seems to be working on the solutions for the agora.
Uses for PKI and Certificates
authentication and pseudo-authentication
signing docs
encrypting docs and mail
non-repudiation
secure channels across a network
authorization and attributes
and more...
PKI Contexts for Usage
Intracampus
Within the Higher Ed community of interest
In the Broader World
Cert-enabled applications
Browsers
Authentication
S/MIME email
IPsec and VPN
Globus
X.509 certs
purpose - bind a public key to a subject
standard fields
extended fields
profiles
client and server cert distinctions
Standard fields in certs
cert serial number
the subject, as x.500 DN or …
the subject’s public key
the validity field
the issuer, as id and common name
signing algorithm
signature info for the cert, in the issuer’s private key
Extension fields
Examples - auth/subject subcodes, key usage, LDAP URL, CRL distribution points, etc
Key usage is very important - for digsig, non-rep, key or data encipherment, etc.
Certain extensions can be marked critical - if an app can’t understand it, then don’t use the cert
Requires profiles to document, and great care...
Cert Management
Certificate Management Protocol - for the creation and management of certs
OCSP - on-line CRL plus….
Storage - where (device, directory, private cache, etc.) and how - format
escrow and archive - when, how, and what else needs to be kept
Cert Authority Software or outsource options
Authority and policies
Directories
to store certs
to store CRL
to store private keys, for the time being
to store attributes
implement with border directories, or acls within the enterprise directory, or proprietary directories
Trust model components
Certificate Policy Statements - uses of particular certs, assurance levels for I/A, audit and archival requirements
Certificate Practices - the nitty gritty operational issues
Hierarchies vs Bridges• a philosopy and an implementation issue
• the concerns are transitivity and delegation
• hierarchies assert a common trust model
• bridges pairwise agree on trust models and policy mappings
Current Activities
Eduperson
the Directory of Directories
Shibboleth
PKI - HEPKI-TAG, PAG and research labs
Others - medical, international, authorization
Edu-person
An objectclass for higher education
Contain suggested attributes for instructional, research and administrative inter-institutional use
Presumes campuses to add local person objectclass.
A joint effort of EDUCAUSE and I2
edu-person 0.9a
parent objectclass=inetorgperson
intends to integrate with Grid, IMS, and other upper-middleware
includes:• primary affiliation (fac/stu/staff)
• enrolledcurrentterm (binary true/false)
• withdrawnpreviousterm (binary)
• schoolcollegename, (multivalued case ignore strings)
A Directory of Directories
an experiment, now encompassing 8 schools, to build a combined directory search service
to show the power of coordination
to show the existing barriers to cooperation• standard object classes
• standard display formats
• standard meta-data
to investigate load and scaling issues - on the clients and the servers
to suggest the service to follow
Shibboleth
interinstitutional web authentication and perhaps authorization
use local credentials for remote services; enable user@ logins; fosters best practices; encourage transition from simple ht controls to LDAP-based
uses SRV records in DNS and several forms of authn; authz via directories
IBM to analyze, several schools to participate in pilot
HEPKI
Joint efforts of Higher Ed - Internet2, EDUCAUSE, CREN
Bi-weekly conference calls (minutes at www.educause.edu/hepki)
Technical Activities Group (TAG)• profiles
• open source reference implementations
• mobility solutions
Policy Activities Group (PAG)• working with fPKI
• Certificate Policies
Internet2 PKI Research Labs
Dartmouth and the University of Wisconsin at Madison
Contributions by ATT, Baltimore, etc.
2-5 years Research agenda
Research agenda includes revocation, human interface, policy languages, authorization, trust path math, etc.
Mware 201 typical issues
Access control lists for directories - how to construct, how to manage
Integration of LAN and enterprise accounts and passwords
Enterprise and LAN directories - schema, replication and synchronization
Working with legacy and source systems
Where to watch
www.internet2.edu/middleware
net@edu
cren.org
fPKI work
NSF
