Middleware and Network Security Update:Progress, Problems, and Opportunities for Interaction
Agenda
•Middleware• Shibboleth and Federations• Video middleware• PKI• P2P• Opportunities for interactions
•Network Security• Security at Line Speed Workshop• SALSA• REN-ISAC interactions• Effective Practices• Opportunities for interactions
•Middleware and Network Security interactions• Network authn/z and its uses
Middleware Background
•Core Concepts•Maps•The Approach•The Results•The Upcoming Work
• Authority Systems• Virtual Organizations• Middleware Diagnostics
•Opportunities for Interactions
The Plan:Federated all the way down
•Given the strong collaborations within the academic community, there is an urgent need to create inter-realm tools, so •Build consistent campus middleware infrastructure deployments, with outward facing objectclasses, service points, etc. and then•Federate (mulitlateral) those enterprise deployments with interrealm attribute transports, trust services, etc. and then•Leverage that federation to enable a variety of applications from network authentication to instant messaging, from video to web services, from p2p to virtual organizations, etc. while we•Be cautious about the limits of federations and look for alternative fabrics where appropriate.
Internet2 Middleware:Key Concepts
•Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc.) in inter-realm interactions•Develop a consistent directory infrastructure within R&E•Provide security while not degrading privacy.•Foster interrealm trust fabrics: federations and virtual organizations •Leverage campus expertise and build rough consensus•Influence the marketplace; develop where necessary•Support for heterogenity and open standards
Interrealm and intrarealm
•Intrarealm describes the services within an enterprise, such as a university or corporation. The services, such as authentication, authorization and directories, assume commonalities and trust.•Interrealm describes the relationships between autonomous systems or enterprises. No assumptions are made.•But of course, for most large universities, there are many pockets of semi-autonomy (colleges, medical schools and hospitals, athletic departments) and it may best be viewed as interrealm•And, of course, in large companies with many wholly-owned but acquired subsidiaries, the lack of a common infrastructure makes their architectures interrealm.
Upper and Core Middleware Land
Core Middleware Scope
•Identity and Identifiers – namespaces, identifier crosswalks, real world levels of assurance, etc.•Authentication – campus technologies and policies, interrealm interoperability via PKI, Kerberos, etc.•Directories – enterprise directory services architectures and tools, standard objectclasses, interrealm and registry services•Authorization – permissions and access controls, delegation, privacy management, etc.•Integration Activities – open management tools, use of virtual, federated and hierarchical organizations, enabling common applications with core middleware
Campus Core Middleware Architecture:(Origin perspective)
Federated administration
O
TO
T
T T
Apps CM CM Apps
VOVO
T
Campus 1Campus 2
Federation
Otherfeds
Landmark Work
•Convincing ourselves that we could do this and that it would make a difference…•Consensus standards – eduPerson, eduOrg, commObject•Best Practices and Deployment Strategies – LDAP Recipe, Group Management, Metadirectories•Tools – KX.509, LDAP Analyzer, LOOK•Software systems – OpenSAML, Shibboleth
The upcoming work
•Authorization• A group-oriented role based approach• Presumes enterprise has done some structuring of authorizations
and roles• Permits delegation, audit controls, etc.
– Implemented as attributes housed in directories– Anchored with registries for roles, policies, authorites, etc.
•Middleware Diagnostics
•Virtual Organization Support
The directory work
•Incent campuses to deploy directories, and to do so in a roughly consistent fashion: The LDAP Recipe and Middleware Business Plans•Create standards (syntax and semantics) for key inter-institutional attributes
• eduPerson• eduOrg• H.350 (nee commObj)
•Develop tools in support of those standards• LDAP Analyzer• Performance tools• Grouper
Shibboleth Milestones
•Project formation - Feb 2000 Stone Soup•Process - began late summer 2000 with bi-weekly calls to develop scenario, requirements and architecture.•Linkages to SAML established Dec 2000 •Architecture and protocol completion - Aug 2001 •Design - Oct 2001•Coding began - Nov 2001•Alpha-1 release – April 24, 2002•OpenSAML release – July 15, 2002•v1.0 April 2003•v1.1 July 2003•(V2.0 early 2004)
Personal Resource Manager
Privacy Management Systems
Unified field theory of Trust
•Bridged, global hierarchies of identification-oriented, often government based trust – laws, identity tokens, etc.
• Passports, drivers licenses • Future is typically PKI oriented
•Federated enterprise-based; leverages one’s security domain; often role-based
• Enterprise does authentication and attributes• Federations of enterprises exchange assertions (identity and
attributes•Peer to peer trust; ad hoc, small locus personal trust
• A large part of our non-networked lives• New technology approaches to bring this into the electronic world.
•Virtual organizations could leverage any of these fabrics
Federations and Classic PKI
•They are very similar• Both imply trust models• Federations are a enterprise-enterprise PKI• Local authentication may well be end-entity certs• Name-space control is a critical issue
•And they are very different• End user authentication a local decision• Flat set of relationships; little hierarchy• Focus as much on privacy as security• Web Services only right now: no other apps, no encryption• We get to define…
What are federations?
•Associations of enterprises that come together to exchange information about their users and resources in order to enable collaborations and transactions•Built on the premise of
• Initially “Authenticate locally, act globally”• Now, “Enroll and authenticate and attribute locally, act federally.”
•Federation provides only modest operational support and consistency in how members communicate with each other•Enterprises (and users) retain control over what attributes are released to a resource; the resources retain control (though they may delegate) over the authorization decision.•Over time, this will all change…
The good and bad of federations
•Very flexible – easy to establish and operate; can work for 2 or 2000 members•Very customizable – tailored to fit the precise membership•Address the whole problem space – security, data schema, privacy, transport, trust – of inter-realm collaborations•Are relatively simple to install and operate, both for enterprises and for end-users•-----------------------------------------------•Don’t address some trust needs – e.g. signing and encryption•Right now only web services•Interfederation issues•Convergence of federating software
Three Types of federation
•Internal federations are occurring among the many subsidiaries of large companies, especially for those companies with more dynamic aggregations. •Private federations occur among enterprises, typically within a market sector, that want to facilitate a specific set of transactions and interactions. Many will be bi-lateral, short-term or otherwise constrained.•Public federations address more free-standing, long-term, general-purpose requirements, and need to be more open about rules of engagement. Public federations face significant scaling issues and may not be able to leverage contractual relationships that private federations can.
Requirements for federations
•Federation operations•Federating software
• Exchange assertions• Link and unlink identities
•Federation data schema•Federation privacy and security requirements
Federating Software
•Liberty Alliance • V 1.1 of their functional specs released; 2.0 under discussion• Federation itself is out of scope (see PingID et al)• Semi-open source under development• Current work is linked identities
•Shibboleth• V1.1 released; 2.0 under discussion• Most standards-based (though Liberty has said that they will turn
their enhancements into standards organizations)• Pure open source• Current work is attribute release focused.
•WS-*
WS-*
•Work by Microsoft, with participation from IBM and BEA et al•Complex framework, consisting of 9 areas, which can form a whole cloth solution to the problem space, but which need to closely interact with each other to do so.•Standards process and IPR issues uncertain•A lofty set of abstractions that will need considerable convention and detail to resolve into a working instantiation•Can Shibboleth/InCommon be a working instantiation within WS-*? Under active discussion with Microsoft
Interoperability among federations
Or, more precisely, interoperability between two members of distinct federations
•Ability to pass each other assertions• Protocols and architectures
•Ability to understand each other’s assertions• Syntax and semantics of objectclasses and schema
•Ability to trust each other’s assertions• Er……
Shibboleth-based federations
•InQueue•InCommon•Club Shib•SWITCH•NSDL------------------------------------•State networks•Medical networks•Financial aid networks•Life-long learning communities
The Research and EducationFederation Space
REFCluster
InQueue(a starting point)
InCommon
SWITCH
The ShibResearch Club
Other national nets
Other clustersOther
potential USR+E feds
State of Penn Fin Aid Assoc
NSDL
Slippery slope- Med Centers, etc
Indiana
InQueue
•The “holding pond”•Is a persistent federation with “passing-through” membership…•Operational today. Can apply for membership via http://shibboleth.internet2.edu/ InQueue Federation guidelines•Requires eduPerson attributes•Operated by Internet2; open to almost anyone using Shibboleth in an R&E setting or not…•Fees and service profile to be established shortly: cost-recovery basis
InCommon basics
• Permanent federation for the R&E US sector• Operated by Internet2, open to .edu-qualified sites and
business partners• Attributes passed: eduPerson• Privacy requirements:
• Initially, destroy received attributes immediatley upon use
• Security requirements:• Initially, enterprises post local I/A and basic business rules for
assignment of eduPersonAffiliation values• Likely to progress towards standardized levels of authn • Logout issues
InCommon
• Management – exec group of CIO’s and CTO’s• Operations
• Strong institutional I/A• High confidence WAYF operation• Low exposure if enterprise signing keys compromised• Indemnified project of Internet2 initially; coop or 501(c)3…
• Cost-recovery • Costs will depend on the level of InCommon work• Low risk level operations ~$1K/yr• Certifying operations potentially much higher
Trust pivot points in federations
•In response to real business drivers and feasible technologiesincrease the strengths of
Campus/enterprise identification, authentication practicesFederation operations, auditing thereofCampus middleware infrastructure in support of Shib (including
directories, attribute authorities and other Shib components) and auditing thereof
Relying party middleware infrastructure in support of ShibMoving in general from self-certification to external certification
Federated Applications
•Personal Privacy and Resource Managers•Digital rights management•Role-based access controls•Desktop videoconferencing•Interrealm calendaring•Authenticated instant messaging•P2P •Shibbed *
The Upcoming Work
•Generalizing the Stanford authority system•Middleware diagnostics•Virtual organizations
Stanford Authz Model
Stanford Authz Goals
•Simplification of authority policy, management and interpretation. We should be able to summarize the full rights and privileges of an individual "at a glance" or let departmental administrators view and manage together all authority in their department or division. •Consistent application of authority rules via infrastructure services and synchronization of administrative authority data across systems. •Integration of authority data with enterprise reference data to provide extended services such as delegation and automatic revocation of authority based on status and affiliation changes. •Role-based authority, that is, management of privileges based on job function and assignments rather than attached to individuals.
Deliverables
•The deliverables consist of •a Web interface and program APIs to provide distributed management (to the departments, to external programs) of access rights and privileges, and •delivery of authority information through the infrastructure as directory data and authority events.
Middleware DiagnosticsProblem Statement
• The number and complexity of distributed application initiatives and products has exploded within the last 5 years
• Each must create its own framework for providing diagnostic tools and performance metrics
• Distributed applications have become increasingly dependent not only on the system and network infrastructure that they are built upon, but also each other
Goals
• Create an event collection and dissemination infrastructure that uses existing system, network and application data (Unix/WIN logs, SNMP, Netflow©, etc.)
• Establish a standardized event record that normalizes all system, network and application events into a common data format
• Build a rich tool platform to collect, distribute, access, filter, aggregate, tag, trace, probe, anonymize, query, archive, report, notify, perform forensic and performance analysis
Cisco NetFlow Events
RMON Events
Event Record Standard
• Normalization of each diagnostic data feed type (SHIB, HTTP, Syslog, RMON, etc.) into a common event record
• The tagging of specific events to help downstream correlation processes
DB Access Log
SHIB log
HTTP Access log
GRID Application Log
NormalizationAnd EventTagging
NETFLOW:TIME:SRC:DST:…RMON:HOST:TIME:DSTPORT..DB:TIME:HOST:REQ:ASTRONSHIB:TIME:HOST:UID…HTTP:TIME:HOST:URL…GRIDAPP:TIME:HOST:UID:…
Variable Star Catalog DBApplication
Enterprise Federation
Alerting apps, filteringdata to federationand API to NMS
Reporting,Performance, and Forensic apps
Application Host Diagnostic Host
Federation specific reporting, performanceand Forensic apps
Massive collection,normalization,filtering or tagging
Archive, querying
Topological Architecture
Collection
Management
TLS
App (Shibboleth) Log Unix/WIN Log
Http Log
FilterAnonymizerAggregationNormalization
Data to diagnostic host
Instructions fromDiagnostic host
• Lightweight module that exists on application host or diagnostic host• Four data operators, each optional for a given stream• Normalization operator is specific to each input stream
Network (SNMP,NetFlow)
Operators
Input Stream Examples
DB
ArchiveQuery
TLS
• Dedicated to data collection, management, manipulation and installed on diagnostic host
• Hosts can be pipelined to disseminate processing load and enforce privacy policies
• Same data operators as Application Module, plus query and archive
Event collectionfrom application
hosts
Control andDiagnostic Application
Platform
Data Management andInternal Housekeeping
SHIBHTTPS
Shell
TLS Diagnostic hostcommunication
Diagnostic Toolsand NMS
Diagnostic Module
NMS API
Diagnostic Applications
• Rich tool platform and API that enables rapid development of diagnostic applications
Control andDiagnostic Application
PlatformSecurity Risk Analysis
Alerting and Notification
Historical Analysis
Reporting
Tracing
Forensic
SHIB
HTTPS
Shell
.
.
.
Diagnostic Host Remote or Local Applications
Involved Groups And Organizations
• Internet2• End-to-End Performance Initiative• Specific Middleware and GRIDS working groups
• SHIB, P2P, I2IM, etc.
• IETF working groups• SYSLOG• RMOMMIB
• Efforts in academic and research
Issues and Vision
• Privacy• Rich and diverse sets of event data can be used to infer
user behavior• Limiting access to this data and using data
anonymization methods is essential to insure the privacy of the end user, or an enterprise as a whole
• Intenet2 Diagnostic Infrastructure Initiative• Create a secure highly distributed set of services and
tools to aid in end-to-end problem, security, and performance analysis
• Establish an standard event record to be used as the basis for describing all network, system and application level anomalies and behavior
Virtual Organizations
•Geographically distributed, enterprise distributed community that shares real resources as an organization.•Examples include team science (NEESGrid, HEP, BIRN, NEON), digital content managers (library cataloguers, curators, etc), life-long learning consortia, etc.•On a continuum from interrealm groups (no real resource management, few defined roles) to real organizations (primary identity/authentication providers)•A required cross-stitch on the enterprise trust fabric
Leveraging V.O.s
VO
Target Resource
User
Enterprise
Leveraging V.O.s Today
VO
Target Resource
User
Enterprise
Federation
Leveraging V.O.s Today
VO
Target Resource
User
Enterprise
Federation
AuthoritySystem
Some Raging Successes
•Neutral, clueful ground in the federated identity management storm•Significant effect on the technical approaches of directory, XML, PKI and other standards•ITU and vendor adoption of H.350•Vendor-specific implementations of community standards•Interactions around Shibboleth with content and service vendors•Nth generation problems (deep linking, diagnostics)
Continuing Conundrums
•Need to work with corporate partners who are not members• Elsevier, Jabber
•Companies that take the clue and then split•Scalable ways to involve more companies•Consultants who take the clue
Opportunities and Issues
•Corporations joining InQueue and InCommon•Technology transfer
• If we’re to be believed, products can be built• Marketplaces need to be created
•Scalable ways of interaction• FOO• Telebriefings?
– To whom– About what– Packaging
Top Related