1 / 42

Federated Security and the Federal Government

This presentation discusses federated security and its relevance to the federal government, including topics such as Shibboleth and SAML, international deployments, and the Federal e-Authentication Initiative.

rpennington
Download Presentation

Federated Security and the Federal Government

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Federated Security and the Federal Government Ken Klingenstein Director, Internet2 Middleware and Security

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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)

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. Distributed Authorities Session authentication credential Attribute Authority Authorities Home Org Affiliated Org Grid user Signet, Grouper Virtual Org Grid Service

  18. 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

  19. 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

  20. Getting Attributes into a Site’s Attribute Authority SIS Person Registry Loaders Attribute Authority HR Shib/ GridShib Core Business Systems Group Registry LDAP Grouper UI On-site Authorities uid: jdoe eduPersonAffiliation: … isMemberOf: … eduPersonEntitlement: … Privilege Registry Signet UI using Shibboleth Off-site Authorities

  21. 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

  22. 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

  23. 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

  24. InCommon federation • Federation operations – Internet2 • Federating 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 formats • Became fully operational 9/04; currently around 15 members • Precursor federation, InQueue, has been in operation for about two years and will feed into InCommon; approximately 250 members • http://www.incommonfederation.org

  25. 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

  26. 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.)

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. ... but it's a nice garden

  34. 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 ...

  35. Federal eAuthentication • Key driver for e-government, operating under the auspices of GSA • Leveraging key NIST guidelines • Setting the standard for a variety of federated identity requirements • Identity proofing • SAML bindings • Credential assessment • Risk assessment • Technical components driven through the InterOp Lab • http://www.cio.gov/eAuthentication/

  36. 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…)

  37. 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

  38. 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

  39. 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 ...

  40. 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

  41. A Few Other Items • Signet • Diagnostics • Integration • Virtual organizations

  42. 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

More Related