Federated Security and the Federal Government - PowerPoint PPT Presentation

Loading...

PPT – Federated Security and the Federal Government PowerPoint presentation | free to download - id: 17eafe-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Federated Security and the Federal Government

Description:

Federated identity and the network control plane: security, ... pretty darned close: 50% all-OK, others do-able. deploy access to a real USG app. summer 2005 ... – PowerPoint PPT presentation

Number of Views:27
Avg rating:3.0/5.0
Slides: 43
Provided by: ter2
Learn more at: http://www.terena.org
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Federated Security and the Federal Government


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 RE 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 RE 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 LOAs, 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 (RE, Federal agencies,
    etc.)
  • With a national context (security regulations,
    privacy laws, pride, etc.)
  • Others talk of other entities federating
  • Virtual organizations or Grid PMAs
  • 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 Govts 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 shibboleths 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 GridShibs 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
Grid Service
Virtual Org
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 Sites 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
Whats 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
About PowerShow.com