cb8893d5d01c3e83e540c57a84c71e79.ppt
- Количество слайдов: 103
Directories and Certificates Renee Woodten Frost Project Manager, Internet 2 Middleware Initiative I 2 Middleware Liaison, University of Michigan ………………. And an ensemble of hundreds
Topics Acknowledgements What is Middleware? Core middleware: the basic technologies Directories • Issues, architecture, good practices • Current activities - LDAP Recipe, edu. Person, MACE-Dir, Directory of Directories, Metadirectories Certificates • PKI fundamentals • Current events in PKI • Shibboleth Where to watch ACUTA August 1, 2001
Internet 2 Mission: Develop and deploy advanced network applications and technologies, accelerating the creation of tomorrow’s Internet. Goals: • Enable new generation of applications • Re-create leading edge Research and Education network capability • Transfer technology and experience to the global production Internet ACUTA August 1, 2001
Middleware Initiatives Acknowledgements MACE and the working groups Early Harvest - NSF catalytic grant and meeting Early Adopters – testbed campuses Higher Education partners - campuses, EDUCAUSE, CREN, AACRAO, NACUA, etc. Corporate partners - IBM, ATT, Sun, et al. Government partners - including NSF and the f. PKI TWG ACUTA August 1, 2001
MACE (Middleware Architecture Committee for Education) Purpose - to provide advice, create experiments, foster standards, etc. on key technical issues for core middleware within higher education 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), Von Welch (Grid) Creates working groups in major areas, including directories, inter-realm authentication, PKI, medical issues, video, etc. Works via conference calls, emails, occasional serendipitous inperson meetings. . . ACUTA August 1, 2001
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. internet 2. edu/best-practices. html) http: //middleware. internet 2. edu/earlyharvest/ ACUTA August 1, 2001
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 Internet 2 middleware site ACUTA August 1, 2001
Early Adopter Participants Dartmouth Michigan Tech U. of Hawaii U. of Pittsburgh Johns Hopkins U. of Southern Cal U. of Maryland, BC U. of Tennessee, Memphis U. of Memphis Tufts U. of Michigan ACUTA August 1, 2001
Partnerships EDUCAUSE CREN Grids, JA-SIG, OKI Campuses Higher education professional associations - AACRAO, NACUA, CUMREC, etc. Increasing international interactions Corporate - IBM, Sun, ATT, etc. ACUTA August 1, 2001
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 ACUTA August 1, 2001
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 A second layer of the IT infrastructure, sitting above the network A land where technology meets policy The intersection of what networks designers and applications developers each do not want to do ACUTA August 1, 2001
Specifically… Digital libraries need scalable, interoperable authentication and authorization. The Grid is a new paradigm for a computational resource; Globus provides middleware, including security, location and allocation of resources, and scheduling. This relies on campus -based services and inter-institutional standards. Instructional Management Systems need authentication and directories. Next-generation portals want common authentication and storage. Academic collaboration requires restricted sharing of materials between institutions. What Internet 1 did with communication, Internet 2 may do with collaboration. ACUTA August 1, 2001
A Map of Middleware ACUTA August 1, 2001
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; Legion is another such software environment Needs to integrate with campus infrastructure Gridforum (www. gridforum. org) umbrella activity of agencies and academics Look for grids to occur locally and nationally, in physics, earthquake engineering, etc. ACUTA August 1, 2001
Core Middleware Identity - unique markers of who you (person, machine, service, group) are Authentication - how you prove or establish that you are that identity Directories - where an identity’s basic characteristics are kept Authorization - what an identity is permitted to do PKI, etc - emerging tools for security services ACUTA August 1, 2001
What is the nature of the work? Technological • • Establish campus-wide services: name space, authentication Build an enterprise directory service Populate the directory from source systems Enable applications to use the directory Policies and Politics • Clarify relationships between individuals and institution • Determine who manages, who can update and who can see common data • Structure information access and use rules between departments and central administrative units • Reconcile business rules and practices ACUTA August 1, 2001
What are the benefits to the institution? Economies for central IT - reduced account management, better web site access controls, tighter network security. . . Economies for distributed IT - reduced administration, access to better information feeds, easier integration of departmental applications into campus-wide use. . . Improved services for students and faculty - access to scholarly information, control of personal data, reduced legal exposures. . . Participation in future research environments - Grids, videoconferencing, etc. Participation in new collaborative initiatives – Directory of Directories, Shibboleth, etc. ACUTA August 1, 2001
What are the costs to the institution? Modest increases in capital equipment and staffing requirements for central IT Considerable time and effort to conduct campus wide planning and vetting processes One-time costs to retrofit some applications to new central infrastructure One-time costs to build feeds from legacy source systems to central directory services The political wounds from the reduction of duchies in data and policies ACUTA August 1, 2001
OIDs to reference identifiers 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 ACUTA August 1, 2001
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. internet 2. edu/a-brief-guide-to-OIDs. doc ACUTA August 1, 2001
Major campus identifiers UUID Net ID Student and/or emplid Email address Person registry ID Library/departmental ID Account login ID Enterprise-LAN ID Publicly visible ID (and pseudo -SSN) Student ID card Pseudonymous ID ACUTA August 1, 2001
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). ACUTA August 1, 2001
Important Characteristics Semantics and syntax- what it names and how does it name it Domain - who issues and over what space is identifier unique Revocation - can the subject ever be given a different value for the identifier Reassignment - can the identifier ever be given to another subject Opacity - is the real world subject easily deduced from the identifier - privacy and use issues ACUTA August 1, 2001
Identifier Mapping Process 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 A key first step towards the loftier middleware goals ACUTA August 1, 2001
Authentication Options Password based • Clear text • LDAP • Kerberos (Microsoft or K 5 flavors) Certificate based Others - challenge-response, biometrics Inter-realm is now the interesting frontier ACUTA August 1, 2001
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 ACUTA August 1, 2001
Some authentication good practices 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 US Mail a one-time password (time-bomb) In-person with a photo ID (some require two) For remote faculty or staff, an authorized departmental representative in person, coupled with a faxed photo ID Initial identification/authentication will emerge as a critical component of PKI ACUTA August 1, 2001
Directory Issues Applications Overall architecture • chaining and referrals, redundancy and load balancing, replication, synchronization, directory discovery The Schema and the DIT (Directory Tree) • attributes, organizational units (ou), naming, object classes, groups Attributes and indexing Management • clients, delegation of access control, data feeds ACUTA August 1, 2001
Directory-enabled applications Email Account management Web access controls Portal support Calendaring Grids ACUTA August 1, 2001
A Campus Directory Architecture border directory metadirectory enterprise directory departmental directories directory database registries OS directories (MS, Novell, etc) source systems ACUTA August 1, 2001
Key Architectural Issues Interfaces and relationships with legacy systems Performance in searching Binding to the directory Load balancing and backups are emerging but proprietary Who can read or update what fields How much to couple the enterprise directory with an operating system http: //www. georgetown. edu/giia/internet 2/ldap-recipe/ ACUTA August 1, 2001
Schema and DIT Good Practices People, machines, services Be very flat in people space Keep accounts as attributes, not as an organizational unit (ou) Replication and group policies should not drive schema RDN name choices rich and critical Other keys to index Creating and preserving unified name spaces ACUTA August 1, 2001
Attribute Good Practices inet. Org. Person, edu. Person, local. Person 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 domain names (dns) is no better. ACUTA August 1, 2001
Management Good Practices No trolling permitted; more search than read LDAP client access versus web access Give deep thought to who can update Give deep thought to when to update LDIF likely to be replaced by XML as exchange format Delegation of control - scalability “See also”, referrals, replication, synchronization in practice Replication should not be done tree-based but should be filtered by rules and attributes ACUTA August 1, 2001
Current Activities in Directories LDAP Recipe edu. Person MACE-DIR Directory of Directories for Higher Education Metadirectories ACUTA August 1, 2001
LDAP Recipe How to build and operate a directory in higher education 1 Tsp. DIT planning 1 Tbsp. schema design 3 oz. configuration 1000 lbs. of data Good details, such as tradeoffs/recommendations on indexing, how and when to replicate, etc. http: //www. georgetown. edu/giia/internet 2/ldap-recipe/ ACUTA August 1, 2001
LDAP Recipe Contents Directory Information Tree Schema Design Directory of Directories for Higher Education (Do. DHE) expectations Schema Design (continued) Schema: How to upgrade it? Password Management Bindings edu. Person attribute discussions Access Control Replication Name Population LDAP filter config file for white pages telephone. Number formatting CHANGELOG ACUTA August 1, 2001
edu. Person A directory object class intended to support inter-institutional applications Fills gaps in traditional directory schema For existing attributes, states good practices where known Specifies several new attributes and controlled vocabulary to use as values Provides suggestions on how to assign values, but leaves it to the institution to choose Version 1. 0 standard; v 1. 5 under discussion ACUTA August 1, 2001
Issues about Upper Class Attributes edu. Person inherits attributes from Person, inet. Org. Person Some of those attributes need conventions about controlled vocabulary (e. g. telephones) Some of those attributes need ambiguity resolved via a consistent interpretation (e. g. email address) Some of the attributes need standards around indexing and search (e. g. compound surnames) Many of those attributes need access control and privacy decisions (e. g. JPEG photo, email address, etc. ) ACUTA August 1, 2001
New edu. Person Attributes eduperson. Affiliation eduperson. Primary. Affiliation eduperson. Org. DN eduperson. Org. Unit. DN eduperson. Principal. Name eduperson. Nickname ACUTA August 1, 2001
edu. Person. Affiliation Multi-valued list of relationships an individual has with institution Controlled vocabulary includes: faculty, staff, student, alum, member, affiliate, employee Applications that use: Shibboleth digital libraries, Do. DHE ACUTA August 1, 2001
edu. Person. Primary. Affiliation Single-valued attribute that would be the status put on a name badge at a conference Controlled vocabulary includes: faculty, staff, student, alum, member, affiliate Applications that use: white pages, restricted access sites ACUTA August 1, 2001
edu. Person. Principal. Name userid@securitydomain EPPN may look like an email address, but it is used by different systems One must be able to authenticate against the EPPN Used in inter-realm authentication such as Shibboleth In some situations it can be used for access control lists; if used, a site should make sure what the reassignment policy is ACUTA August 1, 2001
Next Steps edu. Person 1. 0 done, along with FAQ and letter to implementers Ties closely to LDAP Recipe Version 1. 5+ may include attributes for videoconferencing, additional collaboration factors, links to Grids, portals, etc. Check with web site for additional changes Participate: mace-dir@internet 2. edu ACUTA August 1, 2001
Key Issues for Mace-Dir Revisions to edu. Person 1. 0 Internationalization of edu. Person, Grid. Person Affiliated Directories Groups within directories Groups between institutions ACUTA August 1, 2001
A Directory of Directories (DODHE) An experiment to build a combined directory search service To show the power of coordination Will highlight the inconsistencies between institutions Technical investigation of load and scaling issues, centralized and decentralized approaches Human-interface issues - searching large name spaces with limits by substring, location, affiliation, etc. . . Sun donated server and i. Planet license (6, 000 DN’s) Michael Gettes of Georgetown is project manager ACUTA August 1, 2001
Metadirectories: Architech www. architech. no is now Metamerge Higher Education Contact for USA • Keith Hazelton, University of Wisconsin – Madison hazelton@doit. wisc. edu This product is available free of charge to Higher Ed in USA Source code will be in escrow. See Keith for further details. ACUTA August 1, 2001
Metamerge Features GUI development environment NOT a metadirectory, but a tool to build same functionality Various Languages: Java. Script, Java, Perl, Rexx, etc… Various Parsers: XML, LDIF, CSV, Script Interface, etc … for input and output Various Connectors: COMport, Files, HTTPserver, FTP, LDAP, JDBC, Oracle and more … The product is ALL Java ACUTA August 1, 2001
Public Key Infrastructure (PKI) Agenda Fundamentals - Background and contexts; X. 509 v 3 profiles; Certificate Issuing and Revocation Systems; Policies, practices and trust Models The missing pieces - in the technology and in the community Current Activities - Feds, overseas, Health. Key PKI Forum, etc. Previous Efforts - ANX, PKIForum Higher Ed Activities (campuses, CREN, HEPKI-TAG, HEPKIPAG, Net@edu, PKI Labs) ACUTA August 1, 2001
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 ITPs. . . Options breed complexity; managing complexity is essential ACUTA August 1, 2001
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. A general purpose PKI seems like a difficult task, but instituting a PKI-lite as a first step may not have enough paybacks. ACUTA August 1, 2001
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. . . ACUTA August 1, 2001
Matrix of contexts/components ACUTA August 1, 2001
PKI implementation options In-source - with public domain or campus unique In-source - with commercial product Bring-in-source - with commercial services Out-source - a spectrum of services and issues What you do depends on when you do it. . . ACUTA August 1, 2001
PKI fundamentals Certificate-enabled apps X. 509 v 3 certificates - profiles and uses Validation - Certificate Revocation Lists, OCSP, path construction Certificate management - generating certificates, using keys, archiving and escrow, mobility, etc. Directories - to store certificates, and public keys and maybe private keys Trust models (hierarchies and bridges) and I/A ACUTA August 1, 2001
Some cert-enabled applications, kinda Browsers - SSL more than authorization Authentication S/MIME email IPsec and VPN Globus Note: few direct connection to ERP systems ACUTA August 1, 2001
X. 509 certs Purpose - bind a public key to a subject Standard fields Extended fields Profiles to capture prototypes Client and server issues v 2 for those who started too early, v 3 for current work, v 4 being finalized to address some additional cert formats (attributes, etc. ) ACUTA August 1, 2001
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 ACUTA August 1, 2001
Extension fields Examples - auth/subject subcodes, key usage, LDAP URL, CRL distribution points, altsubjid, etc. Key usage field is very important - for digsig, non-rep, key or data encipherment, etc. Constraint fields - basic, names, policies 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. . . ACUTA August 1, 2001
Constraint fields Oriented towards solving the problems of transitive trust Basic constraints - how much delegation to allow Name constraints - who can say what about whom Policy constraints - how my trust compares to other folks trust Unfortunately, in practice we don’t know how to use any of them, and if we did, and then set them as critical, applications by the score would fail. . . ACUTA August 1, 2001
Certificate profiles Per field description of certificate contents - both standard and extension fields, including criticality flags Syntax of values permitted per field Semantics specified Spreadsheet format by R. Moskowitz, XML and ASN. 1 alternatives for display Centralized repository for higher ed at http: //www. educause. edu/hepki ACUTA August 1, 2001
Certificate management Certificate Issuing/Revoking System or outsource options Certificate Management Protocol - for the creation, revocation and management of certificates Revocation Options - CRL, OCSP Storage of certs and keys - where (device, directory, private cache, etc. ) and how - format (BER, DER, PKCS#…) Escrow and archive - when, how, and what else needs to be kept (e. g. timestamps) ACUTA August 1, 2001
Certificate authority software Homebrews Open Source - Open. SSL, Open. CA, Oscar Third party - Baltimore, Entrust, etc. OS-integrated - W 2 K, Sun/Netscape, etc. Outsourced - Verisign, Digital Systems Trust, Entrust, etc. ACUTA August 1, 2001
Public domain alternatives Mozilla SSLEAY (Open SSL) (www. openssl. org) Open CA (http: //www. openca. org/docs/mission. shtml) vandyke and Cygnacom libraries in the public domain for path math ACUTA August 1, 2001
Directories To store certificates To store Certificate Revocation Lists (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 ACUTA August 1, 2001
Inter-organizational trust model components Certificate Policy- uses of particular certs, assurance levels for I/A, audit and archival requirements Certificate Practices Statement- the nitty gritty operational issues CA- CA Trust - Hierarchies vs Bridges • • a philosophy 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 ACUTA August 1, 2001
Certificate policies (CP) address Legal responsibilities and liabilities (indemnification issues) Obligations of issuing, user, and relying parties Operations of Certificate Management systems Assurance levels - varies according to I/A processes and other operational factors The goal is to limit the number of different policies; differences require bridges ACUTA August 1, 2001
Major Parts of a CP The community to whom the policy is applicable (campuses and members of the campus) Roles, responsibilities and liabilities for • • CAs, RAs, end-entities, relying parties Operational and technical requirements on CA Identification and authentication requirements for each level of certificate Certificate profile ACUTA August 1, 2001
Certificate practice statements (CPS) Site specific details of operational compliance with a Cert Policy A single practice statement can support several policies (CHIME) A Policy Management Authority (PMA) determines if a CPS is adequate for a given CP. The goal is to have a CPS that you can live with and be audited against. ACUTA August 1, 2001
Trust chains Verifying sender-receiver assurance by finding a common trusted entity Must traverse perhaps branching paths to establish trust paths Must then use CRLs etc. to validate assurance If policies are in certificate payloads, then validation can be quite complex Constraints makes things even harder Bridges makes things even harder ACUTA August 1, 2001
Trust chains Path construction • to determine a path from the issuing CA to a trusted CA • heuristics to handle branching that occurs at bridges Path validation • uses the path to determine if trust is appropriate • should address revocation, key usage, basic constraints, policy mappings, etc. ACUTA August 1, 2001
Trust chains When and where to construct and validate • off-line - on a server - at the discretion of the application • depth of chain Some revocations better than others - major (disaffiliation, key compromise, etc. ) and minor (name change, attribute change) Sometimes the CRL can’t be found or hasn’t been updated ACUTA August 1, 2001
Mobility options Smart cards USB dongles Passwords to download from a store or directory Proprietary roaming schemes abound - Netscape, Veri. Sign, etc. SACRED within IETF recently formed for standards Difficulty in integration of certificates from multiple stores (hard drive, directory, hardware token, etc. ) ACUTA August 1, 2001
Current events in PKI Moving along What’s proving hard What’s beyond hard Internet 2 PKI labs HEPKI-TAG, HEPKI-PAG Bridgework Other activities ACUTA August 1, 2001
Moving along CA software Medical requirements for certificates Simple path construction and validation A draft certificate policy for campuses, finally ACUTA August 1, 2001
Proving hard Revocation approaches Mobility Path construction in complex trusts Operating system and token security issues User interface ACUTA August 1, 2001
Beyond hard Alternatives to revocation Non X. 509 PKI Policy languages ACUTA August 1, 2001
Internet 2 PKI labs At Dartmouth and Wisconsin in computer science departments and IT organizations Doing the deep research - two to five years out Policy languages, path construction, attribute certificates, etc. National Advisory Board of leading academic and corporate PKI experts provides direction Catalyzed by startup funding from ATT Research conference with NIST this fall ACUTA August 1, 2001
HEPKI - Technical Activities Group (TAG) • universities actively working technical issues • topics include Kerberos-PKI integration, public domain CA, profiles • will sponsor regular conf calls, email archives HEPKI - Policy Activities Group (PAG) • universities actively deploying PKI • topics include certificate policies, RFP sharing, interactions with state governments • will sponsor regular conf calls, email archives ACUTA August 1, 2001
HEPKI-TAG Chaired by Jim Jokl, Virginia Certificate profiles • survey of existing uses • development of standard presentation • identity cert standard recommendation Mobility options - SACRED scenarios Public domain software alternatives Protection of the institutional private key Discussions of CA software ACUTA August 1, 2001
HEPKI-PAG David Wasley, prime mover draft certificate policy for a campus HEBCA certificate policy FERPA State Legislatures Gartner Decision Driver software ACUTA August 1, 2001
Bridgework Federal • Federal production Bridge • Intended to blend several existing agency PKI (Do. D, Energy) and new agency efforts (NIH, Energy, GAO) • Needs a killer app • Wants to peer with other bridges, e. g. HEBCA Higher Ed • • • In principle, to be operated by EDUCAUSE May be one-off software at first, and out-sourced as feasible Has a draft policy modeled after FBCA Needs software Needs CA’s to bridge among - commercial, CREN, Globus, etc. ACUTA August 1, 2001
Activities in other communities PKIX (http: //www. ietf. org/html. charters/pkix-charter. html) Federal PKI work (http: //csrc. nist. gov/pki/twg/) State Governments (http: //www. ec 3. org/) Medical community (Tunitas, CHIME, HIPAA) Automobile community (ANX) Overseas • Euro government - qualifying certs • Euro. PKI for Higher Ed (http: //www. europki. org/ca/root/cps/en_index. html) ACUTA August 1, 2001
Is there a PKI lite? Something that used client certs Something that met an unmet and important need Something where inter-institutional consistency is desirable Something that avoided the hard and beyond hard Something with a softer trust but not so soft as to not be stepping stone Signed email? Encrypted email? Interrealm authentication? Intrarealm authentication? Timestamps? ACUTA August 1, 2001
Where to watch http: //middleware. internet 2. edu/ http: //www. educause. edu/hepki/ http: // www. cren. org http: //csrc. nist. gov/pki/twg/ http: //www. tunitas. com/pages/PKI/pki. htm ACUTA August 1, 2001
Shibboleth A word which was made the criterion by which to distinguish the Ephraimites from the Gileadites. The Ephraimites, not being able to pronounce sh, called the word sibboleth. See --Judges xii. Hence, the criterion, test, or watchword of a party; a party cry or pet phrase. - Webster's Revised Unabridged Dictionary (1913): ACUTA August 1, 2001
Shibboleth An initiative to analyze & develop mechanisms (architectures, frameworks, protocols and implementations) for interinstitutional web access control “Authenticate locally, act globally” is the Shibboleth shibboleth Facilitated by MACE (a committee of leading higher-ed IT architects) & I 2 Designed by key campus and Tivoli IT architects, with other corporate involvement Coding an open source reference implementation based on Apache Oriented towards privacy and complements corporate standards efforts http: //middleware. internet 2. edu/shibboleth/ ACUTA August 1, 2001
Isn’t This What PKI Does? PKI does this and a whole lot more; as a consequence, PKI does very little right now End-to-end PKI fits the Shibboleth model, but other forms of authentication do as well Uses a lightweight certificate approach for inter-institutional communications - uses the parts of PKI that work today (server side certs) and avoids the parts of PKI that don’t work today (eg client certs). Allows campuses to use other forms of authentication locally May actually have benefits over the end-user-to-target-site direct interactions. . . ACUTA August 1, 2001
Relationship - Shibboleth to Portals Web Resource Res Apps Portal Dir Shibboleth PDP Web Dir Login Auth. N ACUTA August 1, 2001
Related Work Previous DLF work http: //www. clir. org/diglib/presentations/cnis 99/sld 001. htm OASIS Technical Committee (vendor activity, kicked off 1/2001) http: //www. oasis-open. org/committees/security/index. shtml http: //lists. oasis-open. org/archives/security-services/ UK - Athens and Sparta projects http: //www. jisc. ac. uk/pub 00/sparta_disc. html Spain - rediris project http: //www. rediris. es/app/papi/index. en. html ACUTA August 1, 2001
Assumptions Use federated administration as the model Leverage vendor and standards activity wherever possible Disturb as little of the existing campus infrastructure as possible Work with common, minimal authorization systems (e. g. htaccess) Encourage good campus behaviors Learn through doing Create a marketplace and reference implementations Avoid being another dead guppy Build in at the core protections for personal privacy ACUTA August 1, 2001
Development Process Scenarios leading to requirements Establish model architectures for common services and scenario-specific services Develop service and protocol requirements Identify service options, begin protocol development Produce open implementations of missing service components; provide external services as needed ACUTA August 1, 2001
Stage 1 - Addressing Three Scenarios Member of campus community accessing licensed resource • Anonymity required Member of a course accessing remotely controlled resource • Anonymity required Member of a workgroup accessing controlled resources • Controlled by unique identifiers (e. g. name) Taken individually, each of these situations can be solved in a variety of straightforward ways. Taken together, they present the challenge of meeting the user's reasonable expectations for protection of their personal privacy. ACUTA August 1, 2001
Model Local Authentication Local Entity Willing to Create and Sign Entitlement • set of assertions about the user (attribute/value pairs) • user has control over disclosure • attributes may be personally identifiable (e. g Name) or translucent (e. g. “active member of community”, “Associated with Course XYZ”) Target Responsible for Authorization • Rules engine • Matches contents of entitlements against rule set associated with target object Cross-Domain Trust • Previously created between origin and target • Perhaps there is a contract (information providers. . . ) ACUTA August 1, 2001
Shibboleth Architecture Concepts #1 (managing trust) Club Shib Server (holds certs and contracts) Attribute Server Shib htaccess plugin Target Web Server Browser Origin Site Target Site ACUTA August 1, 2001
OASIS/SAML Effort SAML is a standards effort functioning under the multi-corporate OASIS XML business group. SAML is slowly grappling with many of the issues in interrealm exchanges of information about authentication and authorization, but with a B 2 B perspective. SAML appears capable of standardizing some pieces: • an XML format for "assertions" of both names/identities and entitlements/privileges/attributes • a request/response protocol for obtaining assertions • transport bindings for this protocol to HTTP, S/MIME, RMI, etc. SAML and Shibboleth are interacting in development and should interoperate http: //www. oasis-open. org/committees/security/ ACUTA August 1, 2001
Personal Privacy Personal Information is released to site X based on: • Contract provisions • Current request from the target • User control! Getting the defaults right on privacy will be very important and very hard. (Or, 15 pop-up questions before getting to a web page may not be well-received…) ACUTA August 1, 2001
Campus and Resource Requirements To Participate in Shibboleth, a site must have: • • Campus-wide authentication service Campus-wide identifier space (EPPN) Implementation of Edu. Person objectclass Ability to generate attributes (eg “active member of the community”) • Apache web server • The ability to reach agreements with other campuses and information providers ACUTA August 1, 2001
Issues Personal Privacy (reasonable expectation, laws) Relation to local web login (Single Sign On) Portals Use of Shibboleth framework by services beyond the web Grid resources and users ACUTA August 1, 2001
Project Status/Next Steps Requirements and Scenarios document finished Internet 2 intends to have an Apache web module developed Internet 2 intends to develop supporting materials (documentation, installation, etc. ) and web tools (for htaccess construction, filter and access control, remote resource attribute discovery) Technical design completed - end of May 2001 - architecture and specifications Coding to begin soon Pilot site start-up - August 2001 Public demo- Fall 2001 Internet 2 Member Meeting ACUTA August 1, 2001
Vid. Mid - video working group Recently formed international working group Looking at a variety of tools - vic/vat, H. 323, MPEG-2, HDTV Point-to-point and MCU options H. 323 desktop video within reach at physical layer Lacks identifiers and authentication; e. PPN and Shibboleth-type flow could address within the framework of SIP. Http: //middleware. internet 2. edu/video ACUTA August 1, 2001
Activities MACE - RL “Bob” Morgan (Washington) Early Harvest / Early Adopters -Renee Frost (Michigan) LDAP Recipe - Michael Gettes (Georgetown) edu. Person - Keith Hazelton (Wisconsin) Directory of Directories - Michael Gettes (Georgetown) metadirectories - Keith Hazelton (Wisconsin) Shibboleth - Steven Carmody (Brown) PKI Labs - Dartmouth and Wisconsin HEPKI-TAG and -PAG - Jim Jokl (Virginia) and Ken Klingenstein (Colorado) HEBCA - Mark Luker (EDUCAUSE) Vidmid - International leadership Opportunities - the Grid, K-12 ACUTA August 1, 2001
More information Early Harvest / Early Adopters http: //middleware. internet 2. edu/earlyadopters/ MACE - middleware. internet 2. edu LDAP Recipe - http: //www. georgetown. edu/giia/internet 2/ldaprecipe/ edu. Person - www. educause. edu/eduperson Directory of Directories - middleware. internet 2. edu/dodhe Shibboleth - middleware. internet 2. edu/shibboleth HEPKI-TAG - www. educause. edu/hepki HEPKI-PAG - www. educause. edu/hepki Medical Middleware - web site to follow Opportunities - video, the Grid, K-12 ACUTA August 1, 2001


