Succeeding at Building a Federated ID system in Canada

1
Succeeding at Building a Federated ID system in
Canada

• Chris Phillips Chris.phillips_at_queensu.ca
  Canheit 2006

2
Agenda

• Overview
• Anatomy of inCommon
• Why we need our own
• An idea of how to do our own

3
The Concept

• Facilitate the ability for a person to log
  into their home institution and be able to use
  that same identity at various other places, some
  of which may not be at their home institution.
• All done without
• Revealing information inappropriately, yet
  providing different data to different sites
• Being challenged for their userid/password
  again

4
Looks Like This
AAI Authentication and Authorization
Infrastructure
5
End User Benefits

• Users no longer have to manage an array of
  accounts and passwords.
• Users identify themselves locally, then only
  relevant and necessary attributes are passed to
  the resource, maintaining privacy as necessary.
• Single sign-on reduces proliferation of accounts
  and therefore reduces possibility of accounts to
  be compromised.
• Its a better experienceno need to re-enter
  credentials repeatedly.

6
Admin Benefits

• Fewer user accounts (and credential systems) for
  resources to manage reduced cost for
  organizations.
• Fine-grained control over the release of
  identities and other user information.
• Uniform infrastructure allows new users and new
  resource providers to be quickly integrated, both
  on and off campus.
• Economies of scale are realized by federating to
  extend the capabilities of existing
  identity-management and resource services.
• Standards-based and open source, with an
  extensible vocabulary.
• Federation managed trust infrastructure.
• Easier inter-domain integration.
• Enable personalization, without releasing
  identity.

7
Economies of scale

• Internally, an SSO solution helps to
• Organize and centralize the authentication points
  to some degree
• Keep proliferation of other credentialing systems
  to a minimum (maybe! Depends on who you give
  accounts to)
• Sets a standard for others to follow
• Externally a Federation approach helps to
• Do all the above, but in a broader sense
• Deals with attribute release as well as authN
• Apply more leverage on vendors as a group and not
  just a lone entity.
• How many of us are (re)building the same thing?
  (SSO, portal, learning management system,
  identity mgmt system, etc)
• All of these things need authN and authZwhy
  should they all be different between products and
  between institutions?

8
Anatomy of inCommon
Acknowledgement Thanks to Renee Woodten Frost of
Internet2 for the following slides
9
Management

• Operational services by Internet2
• Member services (Application, etc)
• Backroom (Certificate Authority, WAYF service,
  etc.)
• Governance
• Steering Committee Tracy Mitrano Chair
  (Cornell), Carrie Regenstein, (Wisconsin), Jerry
  Campbell (USC), Clair Goldsmith (Texas System),
  Ken Klingenstein (Internet2), Mark Luker
  (EDUCAUSE), , Mike Teets (OCLC),
• Technical Advisory Group Scott Cantor (OSU),
  Steven Carmody (Brown), Bob Morgan (Washington),
  Renee Shuey (PSU)
• Initially an LLC and likely to take 501(c)3
  status (non profit)

10
Documents

• Membership criteria
• Pricing/packaging cost recovery model
• Federation Operating Practices and Procedures and
  Technical Operations Docs
• Participant Agreement
• Participant Operational Practice (POP)

11
Participants

• Two types of participants
• Higher ed institutions - .edu-ish requirements
• Resource providers commercial partners
  sponsored by higher ed institutions, e.g. content
  providers, outsourced service providers, etc
• Participants can function in roles of identity
  providers and/or resource providers
• Higher ed institutions are primarily identity
  (credential) providers, with the potential for
  multiple service providers on campus
• Resource (service) providers are primarily
  offering a limited number of services, but can
  serve as credential providers for their employees
  as well
• 30 Active Members in the production environment

12
Pricing

• Goals
• Cost recovery
• Manage federation stress points
• Prices
• Application Fee 700
• 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

13
Operations

• Operational services by Internet2
• Storefront (process maps, application process)
• Backroom (CA, WAYF service, etc.)
• Federation Operating Practices and Procedures
  (FOPP)
• InCommon Process Technical Advisory
• Scott Cantor, OSU
• Jim Jokl, University of Virginia
• RL Bob Morgan, University of Washington
• Jeff Schiller, MIT
• Key Signing Party
• March 30, 2004 in Ann Arbor
• Videotaped and witnessed

14
Relationships

• Shib is now e-auth compliant.
• An ongoing project with E-auth initiative is
  investigating a peering relationship between
  InCommon and e-auth. 
• Composed of 2 working groups, reps from both
  higher ed (InCommon), the federal govt e-auth,
  and Dept of Ed are meeting weekly  one on
  technology issues and on business and policy
  issues
• Targeting Oct 1 for specs and agreements. 

15
Funding Staffing Dynamics

• Note that only a few people are Internet2
  specific
• People engaged who have firm commitments are
  funded by I2 securing a portion of their time
  from their institution.
• Critical to have strong leaders in various areas
  to carry the initiative through
• Difficult to find and retain (sound familiar?)
• Compensate by having longer delivery times for
  features and work.
• Leverage the knowledge out there
• I2 MACE-DIR group is 180 strong of technical
  peers out there, this is a large brain trust that
  can be tapped, and other groups exist too.
• Peer support also plays a big role so tech sup is
  community driven to a large degree. Mailing list
  turn around time is sometimes spooky how fast it
  is.

16
Its all about

• Trust at different levels
• Data exchange and the confidence in partner data
  to be as good as yours
• Policy and Procedures are as good as yours
• Integrity of everyones systems meet a certain
  standard(see NIST Special Publication 800-63 for
  yardstick which we should all be measured)
• Adopting a standard
• Makes things easier and repeatable.
• Eventually influencing the market in our favour
• Some institutions require vendors be shib
  compliant in their purchasing of software (LMS,
  library software etc).
• Good for vendors, they only need to implement one
  API, everyone can buy from them and integrate
  with them.

17
Ok, Where Do We Sign Up?

• We probably Cant
• due to the eligibility requirements
• Currently any 2- or 4-year degree-granting
  institution of higher education that is
  regionally accredited by an agency on the U.S.
  Department of Educations list of Regional
  Institutional Accrediting Agencies may apply for
  Participation as a Higher Education Institution.
  Fed. Operations Practices and Procedures
• Peering with eAuth and Shib needs to be beyond
  just AuthN, but deal with Levels of Assurance at
  each Id Provider. (NIST doc 800-63)
• We probably dont want to
• Due to legal issues and governance across our
  borders
• Patriot Act being one (it only takes one reason
  doesnt it?)

18
OK, Now What?

• We are not starting without examples to follow
• inCommon in the US
• JISC in the uk (England, Scotland and Wales) have
  a shib federation deploying in Sept. 2006
• They have a Middleware Assisted Take Up Service
  (http//www.matu.ac.uk/) to assist in the
  process.
• SWITCH Swiss Education and Research Network are
  also shib based and have almost ALL higher ed
  using it in the country.
• FEIDE - Federated Electronic Identity for
  Education - Norway
• MAMS Australian Meta Access Management System

19
General Business Model

• Establish A Limited Liability Company to give
  arms length for our institutions, yet under our
  control via a board that we select.
• Establish a governance structure dealing with
  privacy, security and contractual arrangements
  between ourselves and vendors.
• Build out policies and procedures to reflect
  governance decisions and operational needs
• Choose a vendor neutral and open standard which
  has broad adoption so that interop with other
  countries is easy SAML seems to have won this
  one

20
Operations

• Identify how we want to structure technical
  pieces
• Co-lo physical equip _at_ member institutions?
• Central HQ somewhere?
• PKI is needed for the CA, dont need to own it
  however.
• Do we have a central technical SWAT team for
  implementations and operations OR do we work in a
  more supportive role and expect members to be
  self supportive?
• Probably a bit of bothdepends on and
  volunteer effort and quality.
• What about disaster recovery and outage
  issuesneed response plan for this
• Leverage peer support like inCommon does.
  Documentation documentation documentation!

21
Funding

• Membership fees
• Depending on strategy, could be just lights on
  or even FTE(s) for certain things.
• Joint application to government by members for
  funding
• Funds of local FTE talent for local time and
  attention and/or export the knowledge to other
  members (sharing the person out)
• Sources NSERC, Canarie, Provincial government,??
• Vendor support via sponsorship

22
What Next?

• Existing pilot underway in Ontario with Ontario
  Council of University Libraries (OCUL) for
  Scholars Portal
• key benefits
• gain real-world experience with managing a trust
  federation and integrating Shibboleth with local
  authentication systems.
• Content provider CSA will gain a clearer
  understanding of how Shibboleth can be used as an
  alternative to IP-based authentication and how
  the passing of user attributes, as allowed for in
  the Shibboleth design, might be used to design
  customized services for researchers.

23
Thank you!

• Looking to collaborate on this and other topics?
• Canadian Higher Ed. Identity Management
  Collaboration http//wiki.its.queensu.ca/displ
  ay/heidm

24
Useful sites

• http//shibboleth.internet2.edu/
• http//www.nmi-edit.org
• http//www.incommonfederation.org/
• http//www.cio.gov/eauthentication/
• http//csrc.nist.gov/publications/nistpubs/800-63/
  SP800-63V1_0_2.pdf (identity proofing and LoA)
• Canadian Govt PKI
• http//www.solutions.gc.ca/pki-icp/index_e.asp

25
Acknowledgements

• Help from Internet2 folks
• Renee Woodten Frost
• Anne West
• Steve Carmody (Shib dev lead)
• Others
• Marc Huffstickler marc.huffstickler_at_mcgill.ca
• OCUL shib pilot team

26
Extra Slides
27
What is Internet2

• The Research and Education Network for the United
  States
• Led by 207 research universities
• Close collaborations with government NIH, NSF,
  NLM, NASA, to name only a few
• An organization that serves academic and
  technology needs at all levels of education
• A venue that brings together academics and
  scientists from all over the world

28
K20 Initiative Status and Growth
29
Internet2 Today
Applications
End-to-end Performance
Security
Motivate
Enable
Middleware
Services
Networks
30
Body of Documentation

• InCommon_Federation_Disaster_Recovery_Procedures_v
  er_0.1
• An outline of the procedures to be used if there
  is a disaster with the InCommon Federation.
• Internet2_InCommon_Federation_Infrastructure_Techn
  ical_Reference_ver_0.2
• Document describing the federation
  infrastructure.
• Internet2_InCommon_secure_physical_storage_ver_0.2
  
• List of the physical objects and logs that will
  be securely stored.
• Internet2_InCommon_Technical_Operations_steps_ver_
  0.35
• 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_ver_0
  .12
• Documentation of the proposed hours of
  operations.
• CA_Disaster_Recovery_Procedure_ver_0.14
• An outline of the procedures to be used if there
  is a disaster with 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.
• Plus other docs