Federated Administration: The Cutting Edge

1
Federated Administration The Cutting Edge
2
Topics

• Federations The Basics
• Business drivers and the basic model
• Technical Considerations and the marketplace
• Policy Considerations
• A Leading Edge Corporate Experience Bob Chmura
• Liberty Alliance
• General Motors
• A Leading Edge Public Experience
• Shibboleth and InCommon
• International federations and inter-federation
  issues
• Where this may leadopen discussion

3
Unified field theory of Trust

• Bridged, global hierarchies of identification-orie
  nted, often government based trust laws,
  identity tokens, etc.
• Passports, drivers licenses
• Future is typically PKI oriented
• Federated enterprise-based leverages ones
  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.
• Distinguishing P2P apps arch from P2P trust
• Virtual organizations cross-stitch across one of
  the above

4
Federations

• Associations of enterprises that come together to
  exchange information about their users and
  resources in order to enable collaborations and
  transactions
• Enroll and authenticate and attribute locally,
  act federally.
• Uses federating software (e.g. Liberty Alliance,
  Shibboleth, WS-) common attributes (e.g.
  eduPerson), and a security and privacy set of
  understandings
• 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.
• Several federations now in construction or
  deployment

5
Business drivers - corporate

• Need to link consumer identities among disparate
  service providers
• Link corporate employees through a company portal
  to outsourced employee services transparently
• Allow supply chain partners to access each others
  internal web sites with role based controls

6
Business drivers RE

• 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 (multilateral) 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.

7
Requirements for federations

• Federation operations
• Federating software
• Exchange assertions
• Link and unlink identities
• Federation data schema
• Federation privacy and security requirements
• Non web services can also leverage federations

8
Federating Software Comparison

• Liberty Alliance
• V 1.1 of their functional specs released 2.0
  under discussion
• Federation itself is out of scope
• Open source implementations not emphasized
• Current work is linked identities
• Shibboleth
• V1.2 released 1.3 and 2.0 under development
• Most standards-based pure open source in
  widening use
• Current work is attribute release focused
  linking identities in 2.0.
• Can Shibboleth and Liberty converge? SAML 2.0 is
  key
• WS-
• 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
• Will need considerable convention and detail to
  resolve into a working instantiation
• Can Shibboleth/InCommon interoperate with WS-?
  Under active discussion with Microsoft

9
Policy Basics for federations

• Enterprises that participate need to establish a
  trusted relationship with the operator of the
  federation in small or bilateral federations,
  often one of the participants operates the
  federation
• Participants need to establish trust with each
  other on a per use or per application basis,
  balancing risk with the level of trust
• Participants need to agree on the syntax and
  semantics of the information to be shared
• Privacy issues must be addressed at several
  layers
• All this needs to be done on a scalable basis, as
  the number of participants grow and the number of
  federations grow

10
Federal guidelines of relevance

• NIST Guideline on Risk Assessment Methodologies
• NIST Guideline on Authentication Technologies and
  their strengths
• Federal e-Authentication

11
A Leading Edge Corporate Experience
12
Public SectorShibboleth and its federations

• Shibboleth status
• InCommon
• Uses
• Management
• Policies
• Shared schema
• Other Shibboleth-based federations
• Interfederation issues

13
Shibboleth Status

• Open source, privacy preserving federating
  software
• Being very widely deployed in US and
  international universities
• Target - works with Apache(1.3 and 2.0) and IIS
  targets Java origins for a variety of Unix
  platforms.
• V1.3 likely to include portal support, identity
  linking, non web services (plumbing to
  GSSAPI,P2P, IM, video) etc.
• Work underway on intuitive graphical interfaces
  for the powerful underlying Attribute Authority
  and resource protection
• Likely to coexist well with Liberty Alliance and
  may work within the WS framework from Microsoft.
• Growing development activities in several
  countries, providing resource manager tools,
  digital rights management, listprocs, etc.
• http//shibboleth.internet2.edu/

14
The Point of Privacy

• Kudos for Shibboleth!
• Liberty Alliance Has Missed the Point eWeek
  November 24, 2003 By  Jim Rapoza 
  http//www.eweek.com/article2/0,4149,1396027,00.a
  sp
• What I'd like to see the group do is add more
  mechanisms to make it easy for third-party
  developers to create tools that give users total
  control over how their data is shared. A good
  model for this is the Internet2 group's
  Shibboleth ID management specification, which was
  designed mainly for academic institutions. In
  Shibboleth, users have built-in controls that
  give them final say over how their data is
  controlled.

15
Federated administration
VO
VO
O T
A CM
O T
CM A
Campus 1
Campus 2
T
T
T
Federation
16
Shibboleth-based federations

• InQueue
• InCommon
• Club Shib
• SWITCH
• NSDL
• ------------------------------------
• State networks
• Medical networks
• Financial aid networks
• Life-long learning communities

17
InCommon federation

• Federation operations Internet2
• Federating software Shibboleth 1.1 and above
• Federation data schema - eduPerson200210 or later
  and eduOrg200210 or later
• Became operational April 5, with several early
  entrants to help shape the policy issues.
• Precursor federation, InQueue, has been in
  operation for about six months and will feed into
  InCommon
• http//incommon.internet2.edu

18
InQueue Origins2.12.04

• National Research Council of Canada
• Columbia University
• University of Virginia
• University of California, San Diego
• Brown University
• University of Minnesota
• Penn State University
• Cal Poly Pomona
• London School of Economics
• University of North Carolina at Chapel Hill
• University of Colorado at Boulder
• UT Arlington
• UTHSC-Houston
• University of Michigan
• University of Rochester
• University of Southern California

• Rutgers University
• University of Wisconsin
• New York University
• Georgia State University
• University of Washington
• University of California Shibboleth Pilot
• University at Buffalo
• Dartmouth College
• Michigan State University
• Georgetown
• Duke
• The Ohio State University
• UCLA
• Internet2
• Carnegie Mellon University

19
InCommon Uses

• Institutional users acquiring content from
  popular providers (Napster) and academic
  providers (Elsevier, JSTOR, EBSCO, Pro-Quest,
  etc.)
• Institutions working with outsourced service
  providers, e.g. grading services, scheduling
  systems
• Inter-institutional collaborations, including
  shared courses and students, research computing
  sharing, etc.

20
InCommon Management

• Operational services by I2
• Member services
• Backroom (CA, WAYF service, etc.)
• Governance
• Executive Committee - Carrie Regenstein - chair
  (Wisconsin), Jerry Campbell, (USC), Lev Gonick
  (CWRU), Clair Goldsmith (Texas System), Mark
  Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan
  Perry (Mellon), Mike Teetz, (OCLC), David
  Yakimischak (JSTOR).
• Project manager Renee Frost (Internet2)
• Membership open to .edu and affiliated business
  partners (Elsevier, OCLC, Napster, Diebold, etc)
• Contractual and policy issues being defined now
• Likely to take 501(c)3 status in the long term

21
Trust pivot points in federations

• In response to real business drivers and feasible
  technologies
• increase the strengths of
• Campus/enterprise identification, authentication
  practices
• Federation operations, auditing thereof
• Campus middleware infrastructure in support of
  Shib (including directories, attribute
  authorities and other Shib components) and
  auditing thereof
• Relying party middleware infrastructure in
  support of Shib
• Moving in general from self-certification to
  external certification

22
Trust in InCommon - initial

• Members trust the federated operators to perform
  its activities well
• The operator (Internet2) posts its procedures,
  attempts to execute them faithfully, and makes no
  warranties
• Enterprises read the procedures and decide if
  they want to become members
• Origins and targets trust each other bilaterally
  in out-of-band or no-band arrangements
• Origins trust targets dispose of attributes
  properly
• Targets trust origins to provide attributes
  accurately
• Risks and liabilities managed by end enterprises,
  in separate ways

23
InCommon Trust - ongoing

• Use trust ?? Build trust cycle
• Clearly need consensus levels of I/A
• Multiple levels of I/A for different needs
• Two factor for high-risk
• Distinctive requirements (campus in Bejing or
  France, distance ed, mobility)
• Standardized data definitions unclear
• Audits unclear
• International issues

24
Balancing the operators trust load

• InCommon CA
• Identity proofing the enterprise
• Issuing the enterprise signing keys (primary and
  spare)
• Signing the metadata
• Could be outsourced
• InCommon Federation
• Aggregating the metadata
• Supporting campuses in posting their policies
• Less easy to outsource, especially the organic
  aspects

25
InCommon Federation Operations

• InCommon_Federation_Disaster_Recovery_Procedures
• An outline of the procedures to be used if there
  is a disaster with the InCommon Federation.
• Internet2_InCommon_Federation_Infrastructure_Techn
  ical_Reference
• Document describing the federation
  infrastructure.
• Internet2_InCommon_secure_physical_storage
• List of the physical objects and logs that will
  be securely stored.
• Internet2_InCommon_Technical_Operations_steps
• This document lists the steps taken from the
  point of submitting CSR, Metadata, and CRL to
  issuing a signed cert, generation of signed
  metadata, and publishing the CRL.
• Internet2_InCommon_Technical_Operation_Hours
• Documentation of the proposed hours of
  operations.

26
InCommon CA Ops

• CA_Disaster_Recovery_Procedure_ver_0.14
• An outline of the procedures to be used if there
  is a disaster with the CA.
• cspguide
• Manual of the CA software planning to use.
• InCommon_CA_Audit_Log_ver_0.31
• Proposed details for logging related to the CA.
• Internet2_InCommon_CA_Disaster_Recovery_from_root_
  key_compromise_ver_0.2
• An outline of the procedures to be used if there
  is a root key compromise with the CA.
• Internet2_InCommon_CA_PKI-Lite_CPS_ver_0.61
• Draft of the PKI-Lite CPS.
• Internet2_InCommon_CA_PKI-Lite_CP_ver_0.21
• Draft of the PKI-Lite CP.
• Internet2_InCommon_Certificate_Authority_for_the_I
  nCommon_Federation_System_Technical_Reference_ver_
  0.41
• Document describing the CA.

27
InCommon Key Signing Process

• 2. Hardware descriptions         a. Hardware
  will be laptop and spare laptop with no network
  capabilities, thumb drive, CDRW drive, media for
  necessary software 3. Software descriptions
          a. OS, OpenSSL, CSP, Java tools for meta
  data 4. Log into computer 5. Generation of the
  CA Private Root key and self-signing 6.
  Generation of the Metadata signing key 7.
  Generate CSR for Internet2 origin 8. Signing of
  new metadata sites and trusts files 9. Backup
  copies of all private keys and other operational
  backup data are generated. 10. Verify CD's and
  MD5 checksum 11. Write down passphrase and put
  in envelopes and sign envelopes 12. Securely
  store CA hardware and contents of local safe in
  safe 13. Log that these actions occurred on the
  log in safe and then close and lock the safe 14.
  Put thumb drive into secure db and copy data onto
  secure db 15. Take private key password archive
  and other contents to Private Key Password safe
  deposit box and record in log that this was done.
  16. Take operational data archive to Operation
  Data safe deposit box and record in log that this
  was done.

28
InCommon Process Tech Review

• As a technical review group, we, the undersigned,
  reviewed the processes and the following
  components documenting the operations of
  InCommon, and discussed them with the Internet2
  Technical and Member Activities staff. To the
  best of our knowledge and experience, with no
  warranty implied, we believe the operational
  processes and procedures Internet2 provided are
  acceptable to begin the operations of InCommon.
• Scott Cantor, OSU
• Jim Jokl, UVa
• RL Bob Morgan, UW
• Jeff Schiller, MIT

29
The Research and EducationFederation Space
Indiana
Slippery slope - Med Centers, etc
30
International Activities

• International eduPerson and object class registry
• Swiss Shibboleth-based Federation (SWITCH-AAI)
• UK scaffolding
• JISC issued solicitation extending our NMI-EDIT
  work see (http//www.jisc.ac.uk/c01_04.html)
• Working on virtual organizations, digital rights
  management, etc
• Federation in the works
• Australian interest
• Planning a solicitation based on our work
• Widespread use of Shibboleth and development of
  GUIs

31
Upper Slaughter, England
32
International federation peering

• Shibboleth-based federations being established in
  the UK, Netherlands, Finland, Switzerland,
  Australia, Spain, and others
• International peering meeting slated for October
  14-15 in Upper Slaughter, England
• Issues include agreeing on policy framework,
  comparing policies, correlating app usage to
  trust level, aligning privacy needs, working with
  multinational service providers, scaling the WAYF
  function
• Leading trust to Slaughter

33
Next Steps

• Federated software alignment and interoperability
• Fully establishing persistent federations
• End-user ARP management tools (Autograph)
• Coordination of federation policy underpinnings
• Escalating levels of trust