Upload
albert-henry
View
220
Download
1
Tags:
Embed Size (px)
Citation preview
Federated Security and the Federal Government
Ken KlingensteinDirector, Internet2 Middleware and Security
Topics
What and why federated AAI• Federate what?
The basic ingredients• Shibboleth and SAML• GridShib and WS-Fed • Federations, international deployments and InCommon, a US R&E federation…• Federated identity and the network control plane: security, allocation, etc.• Federated identity and virtual organizations
Work with the US government• The Federal e-Authentication Initiative• Phase 1/2 – Certifying Shib, Shaping Policy Issues, etc• Phase 3/4 – SAML 2.0 Profile, USperson deliverables, interfederation peering
What is easy / What is hard What does it mean to Magic
Authentication and Authorization Infrastructure
Authentication – provides positive proof, at several possible strengths, of identity
Authorization – assign permissions to use resources, from web sites to supercomputer access, digital content to parking spaces
Infrastructure means:• A reliable, robust, ubiquitous, service• Initially to the R&E community but with applicability to other vertical
sectors• National in character, but of service to multi-national virtual
organizations• Built on either central, hierarchical or federated, enterprise models
Key Issues for AAI
In authentication, the key issues are strength of authentication (identity proofing, delivery of credential, repeated use of credential) and privacy/secrecy
In authorization, the key issues are permissions to use resources, delegation, audit and privacy
In infrastructure, the issues are making it real, ubiquity, robustness, ability to support a wide range of needs and uses, and funding
Federated model
Enterprises and organizations provide local LOA, namespace, credentials, etc.
Uses a variety of end-entity local authentication – PKI, username/password, Kerberos, two-factor, etc.
Enterprises within a vertical sector federate to coordinate LOA’s, namespaces, metadata, etc.
Internal federations within large complex corporations have been “discovered”.
Privacy/security defined in the context of an enterprise or identity service provider
A federation of what?
A key issue for MAGIC
The NMI-I2 work is a federation of enterprises• Within a market sector (R&E, Federal agencies, etc.)• With a national context (security regulations, privacy laws, pride, etc.)
Others talk of other entities federating• Virtual organizations or Grid PMA’s• Applications running at multiple sites
– A federation of courses, data sets, etc…
• A federation of individuals
Why does it matter
Regulation• Strength of identity proofing and LOA• Audit and compliance capabilities
Ease of use
Where the users live and travel
Use cases that are enterprise centric
Scale
Industry trends
Federating Software
Shibboleth – an open source privacy preserving standards-based system
Liberty Alliance – large commercial standards group in federated identity management
Liberty and Shib have essentially converged around SAML 2.0, with Liberty Alliance moving into services and Shib being refactored and expanded
WS-* - MS (with IBM) “standards” that is slowly emerging, with some interoperability with SAML and Shib
Shibboleth
An architecture, consisting of both a payload definition (using SAML) of attributes and a set of privacy-preserving methods of exchanging such payloads.
A project that has managed the development of the architecture and code
A code package, running on a variety of systems, that implements the architecture.
(Note that other code sets are under development)
Shibboleth v1.3
Planned Availability -- July, 2005• Currently in beta
Major New Functionality• Full SAML v1.1 support -- BrowserArtifact Profile and AttributePush• Support for SAML-2 metadata schema• Improved Multi-Federation Support• Support for the Federal Gov’t’s E-authn Profile• Native Java SP Implementation• Improved build process
WS* Interop -- Status
Agreements to build WS-Fed interoperability into Shib• Contracts signed; work to begin AFTER Shib v1.3• WS-Federation + Passive Requestor Profile + Passive Requestor Interoperability
Profile
Discussions broached, by Microsoft, in building Shib interoperabilty into WS-Fed; no further discussions
Devils in the details• Can WS-Fed-based SPs work in InCommon without having to muck up federation
metadata with WS-Fed-specifics?• All the stuff besides WS-Fed in the WS-* stack
What is GridShib?
NSF Middleware Initiative (NMI) Grant:“Policy Controlled Attribute Framework”
Allow the use of Shibboleth-transported attributes for authorization in NMI Grids built on the Globus Toolkit v4
2 year project started December 1, 2004 Participants
• Von Welch, UIUC/NCSA (PI)• Kate Keahey, UChicago/Argonne (PI)• Frank Siebenlist, Argonne• Tom Barton, UChicago
Why?
Attribute-based authorization has shown itself to be useful in large grids with far-flung participants in several types of roles
• Identity-based approach scales poorly
Shibboleth is well supported and becoming widely deployed
SAML is used by larger identity federation world, not just Shibboleth. Integrating SAML support into Grids opens the door to leveraging this large technology space
GridShib Integration Principles
No modification to typical grid client applications• Modifications only to Grid Services and security clients (e.g. grid-
proxy-init)
Leverage shibboleth’s attribute marshaling capability and release policies
Leverage strategic investment that campuses make in Identity Management operations
GridShib Progress
Developers hired February 2005 Substantial resolution of GridShib’s Shibboleth usage profile Shibboleth IdP plugin nearing completion
• Maps externally-issued X.509 identity certificates to local identifiers
SAML attribute marshaling in GT4 runtime nearing completion Common attribute format internal to GT4 runtime to support
access policies spanning SAML and X.509 PMI attribute sources
• Uses XACML Request Context
Initial GridShib release for closed alpha deployment• Readiness by end of June• Overlays GT 4.0 and Shib 1.3
Potential Early Adopters
Focused efforts to understand and evaluate potential use of GridShib in:
• caBIG, Cancer Bioinformatics Grid• UK eScience Grid • LOOKING, Laboratory for the Ocean Observatory Knowledge
Integration Grid• University of Southern California• University of Alabama at Birmingham• SURAgrid
Distributed Authorities
Grid Service
Session authentication
credential
Attribute Authority
Home Org
Virtual Org
Affiliated Org
Authorities
Grid user
Signet, Grouper
Project objectives
Priority 1: Pull mode operation• Globus services contact Shibboleth to obtain attributes about identified
user• Support both GT4.x Web Services and pre-WS code
Priority 2: Push mode operation• User obtains Shib attributes and push to service• Allows role selection
Priority 3: Online CAs• Pseudonymous operation• Integration with local authentication services
Timeline
December 1, 2004: formal start February 1, 2005: Developers on board and coding Mid-Summer 2005: closed alpha release
• pull model with user identified
Fall 2005: public releases• Production pull model with user identified• Beta push model with user identified• Implementation of simple policy description language• Targeting GT 4.1.x and Shibboleth 1.3
2006: Integration with online CAs
LDAP
Getting Attributes into a Site’s Attribute Authority
uid: jdoeeduPersonAffiliation: …isMemberOf: …eduPersonEntitlement: …
SIS
HR
On-site Authorities
Loaders PersonRegistry
GroupRegistry
GrouperUI
PrivilegeRegistry
Off-site Authorities
SignetUI
Attribute Authority
Core Business Systems
Shib/GridShib
using Shibboleth
Federations
Persistent enterprise-centric trust facilitators
Sector-based, nationally-oriented
Federated operator handles enterprise I/A, management of centralized metadata operations
Members of federation exchange SAML assertions bi-laterally using a federated set of attributes
Members of federation determine what to trust and for what purposes on an application level basis
Steering group of members sets policy and operational direction for federation
Federations redux
created to support community• interesting ones are multi-IdP, multi-SP• embodies agreements on many levels
– membership, technology, assurance, key mgt, legal, attributes, privacy, appropriate use, etc
facilitates member federated interactions• many potential sub-communities and their apps• operational support
– key/config distribution, IdP discovery, etc
• doesn't preclude non-fed arrangements
Federations happening
i.e., SAML-based (or similar) federations• in Europe, natural extension of HE NREN services
– Switzerland, Finland, Netherlands, UK, Spain, France, etc
• in US– InCommon Federation in higher ed
– also state-level planning, vertical apps such as student loan management
– US government E-Authentication Program
– also much non-fed or pre-fed deployment among fed members
InCommon federation
Federation operations – Internet2Federating software – Shibboleth 1.2 and above Federation data schema - eduPerson200210 or later and
eduOrg200210 or later Federated approach to security and privacy, with policies posted
by members in common formatsBecame fully operational 9/04; currently around 15 membersPrecursor federation, InQueue, has been in operation for about
two years and will feed into InCommon; approximately 250 members
http://www.incommonfederation.org
InCommon Members 7/1/05
Cornell University Dartmouth Georgetown University Ohio University Penn State University of California, Irvine University of California, San Diego The University of Chicago University of Rochester University of Southern California University of Washington University of California, Office of the President The Ohio State University University of California, Los Angeles Internet2 SUNY Buffalo Elsevier ScienceDirect OCLC WebAssign OhioLink - The Ohio Library & Information Network
InCommon Uses
Institutional users acquiring content from popular providers (Napster, etc.) and academic providers (Elsevier, JSTOR, EBSCO, Pro-Quest, etc.)
Institutions working with outsourced service providers, e.g. grading services, scheduling systems, software sales
Inter-institutional collaborations, including shared courses and students, research computing sharing, etc.
(Shared network security monitoring, federal research trust peering, interactions between students and federal applications, wireless network access, peering with international activities, etc.)
InCommon pricing
Goals• Cost recovery• Manage federation “stress points”
Prices• Application Fee: $700 (largely enterprise I/A, db)• Yearly Fee
– Higher Ed participant: $1000 per identity management system
– Sponsored participant: $1000
– All participants: 20 Resourceproviderids included; additional resourceproviderids available at $50 each per year, available in bundles of 20
InCommon Management
Operational services by I2• Member services • Backroom (CA, WAYF service, etc.)
Governance • Steering Committee – drawn from CIO level leadership in the
community - sets policies, priorities, etc.• Project manager – Internet2
Contractual and policy issues were not easy and will evolve
Initially a LLC; likely to take 501(c)3 status in the long term
Trust in InCommon - initial
Members trust the federated operators to perform its activities well • The operator (Internet2) posts its procedures• Enterprises read the procedures and decide if they want to become members• Contracts address operational and legal issues
Origins and targets establish trust bilaterally in out-of-band or no-band arrangements (using shared posting of practices)
• Origins must trust targets dispose of attributes properly• Targets must trust origins to provide attributes accurately• Risks and liabilities managed by end enterprises, in separate ways
– Collaborative apps are generally approved within the federation
– Higher risk apps address issues through contractual and legal means
Members Trusting Each Other:Participant Operational Practice Statement
Basic Campus identity management practices in a short, structured presentation
• Identity proofing, credential delivery and repeated authn• Provisioning of enterprise-wide attributes, including entitlements
and privileges
Basic privacy management policies• Standard privacy plus• Received attribute management and disposal
No audit, unclear visibility of policies
InCommon Progress
Relatively straightforward• Syntax and semantics of exchanged attributes (Eduperson)• Set up and operation of federation• Selling the concept and value
More challenging• Having applications make intelligent use of federated identity• Handling indemnification• Finding scalable paths for LOA components
Interfederation
an immediate consequence of federation• brand-new federations don't have well-defined boundaries or
service scopes• it's the Internet, we're all connected• many interesting SPs are global, e.g. Elsevier
Interfederation workshop, Oct 2004• Upper Slaughter, UK (a nicer walled garden?)• many countries, including CERN• many agreements on direction, future work
... but it's a nice garden
Interfederation models
parallel universes• members simply participate in many if needed• consistent with fundamental pairwise nature of app-level relationships• scaling, diversity not addressed
peering• transitive assurance, legal, policy, maybe ops• too tight a coupling?
league of federations?• some historical examples ...
Federal eAuthentication
Key driver for e-government, operating under the auspices of GSA
Leveraging key NIST guidelinesSetting the standard for a variety of federated identity
requirements• Identity proofing• SAML bindings• Credential assessment• Risk assessment
Technical components driven through the InterOp Labhttp://www.cio.gov/eAuthentication/
eAuthentication Key Concepts
Approved technologies
The Federal “e-Authentication Federation”
Credential assessment framework
Trusted Credential Service providers
Agency Applications (outward facing, agency to agency and agency to citizen…)
InCommon E-Auth alignment
promote interop for widespread higher-ed access to USG applications
• grants process, research support, student loans ...
process• project started Oct 2004, thru Sept 2005• compare federation models• propose alignment steps• validate with federation members, via concrete application trials• implement via next e-auth, InCommon phases
Validation steps
universities undergo trial by CAF• assess whether compliance is likely across HE• U Washington, Penn State, Cornell• pretty darned close: 50% all-OK, others do-able
deploy access to a real USG app• summer 2005• requires E-Auth acceptance of univs as CSPs• app will modify existing provisioning process• practical feedback to alignment recommendations
US person
motivated by InCommon desire for attribute-based authorization
modeled on Internet2 eduPerson spec
framework on which agency/app definitions can be built
not just SAML• generic information model, mapped to LDAP, SAML, XML
provisioning
ambitious? yes ...
Federations and PKI
The rough differences are payload format (SAML vs X.509) and typical length of validity of assertion (real-time vs long-term)
Federations use enterprise-oriented PKI heavily and make end-user PKI both more attractive and more tractable – adding privacy (secrecy), ease of verification, addition of role, etc.
The analytic framework (evaluation methodologies for risk in applications and strength of credentials) and infrastructure developed for PKI is useful for federations.
The same entity can offer both federation and PKI services
A Few Other Items
Signet
Diagnostics
Integration
Virtual organizations
What’s It Mean For Magic
Federated identity• Get agencies to participate in “Fed-fed”• Assess the applications• Agree on LOA approaches• Build agencyPerson as a subordinate class to USPerson
Understand the tools and services becoming available to virtual organizations
• Virtual organization service centers• Registries
Trust-mediated transparency and other security issues