Middleware Initiatives

1
Middleware Initiatives
Ken Klingenstein Director, Internet2 Middleware
and Security
2
Topics

• How plumbers see the world
• Some middleware components
• Some middleware activities
• Trust fabrics
• Federations, nationally and internationally
• Bilaterals
• E-Authentication peering, Fastlane, USperson,etc.
• GridShib
• Some gaps workflow, connective middleware, rich
  access control, VO collab services

3
A Map of Middleware Land
4
A Richer Map
5
Components of Core Middleware
6
Federations Concept
7
The Art of Federating
8
Some components

• eduPerson and USPerson
• Disability class
• SAML and Shibboleth
• ShARPE and Autograph
• Status and adoption
• Signet and Grouper
• USHER
• WS-Fed

9
SAML

• Security Access Markup Language an OASIS
  standard
• SAML 1.0 current federal eAuth standard SAML 1.1
  widely embedded
• SAML 2.0 ratified by OASIS last year
• Combines much of the intellectual contributions
  of the Liberty Alliance with materials from the
  Shibboleth community
• Scott Cantor of Ohio State was the technical
  editor
• Key new functions
• Authn Request -- extended functionality
• Single Logout
• NameID Mapping and Management
• Enhanced Client or Proxy (ECP) Profile
• Encryption
• Possibly a plateau product

10
SAML 2.0 -- new features

• Authn Request -- extended functionality
• Single Logout
• NameID Mapping and Management
• Enhanced Client or Proxy (ECP) Profile
• Encryption

11
Shibboleth v1.3b

• Certified for use with the US Federaal Government
  e-Authentication Initiative
• WS-Fed compatible, funded by Microsoft
• Installs relatively easily
• Plugins for non-web services GridShib,
  Lionshare, etc.
• Plumbing can take one day to four years,
  depending on local middleware infrastructure
• Over-the-top hype is unfortunately starting

12
Shibboleth 2.0 Features

• What is the definition of Shibboleth 2.0? Is a
  new profile needed?
• Convergence with commercial Liberty and SAML
  products
• Support for the published Shibboleth profile
  (would not interoperate with Shibb v1.2?)
• Support for SAML 2.0 AuthN, Logout, Attribute
  Artifact, and NameID management requests
• everything but AuthnQuery and AuthzDecisionQuery)
• how applications would influence the AuthnRequest
  process

13
Shibboleth 2.0 Features

• Flexible account linking tools
• SP 2.0 ( implemented in C and Java)
• Authn Request
• some of the extended SAML functionality
• Shib will include some Authentication processing
  "in the box
• interface to SSO systems to support new
  functionality in Authn Request
• IdP be easily clusterable and should be stateless
  to the greatest extent possible
• SP - clusterable
• Production ready WAYF providing both standalone
  and application-integrated functionality in at
  least Java

14
Shibboleth 2.0 -- Status, timeline

• coding currently underway on OpenSAML 2.0
• will support both saml v1.1 and 2.0
• about 50 done beta in March timeframe
• initial beta version of Shib 2.0 available
  May/June 2006 product shortly after
• Shib 2.1
• Delegated Authentication
• SAML NameID management requests (account linking)

15
Shib Add-ons

• Institutional Privacy Managers (e.g. ShARPE from
  Australia)
• Personal Privacy Managers
• Lionshare (peer-to-peer file sharing coupled to
  enterprise)
• GridShibs

16
Shib adoption

• As noted below, widespread adoption overseas
• Several million students and teachers in UK,
  replacing Athens as the bulk content mechanism
• Production at every university in Switzerland,
  Finland national deployments underway in
  Australia, Germany, Denmark, France, etc
• Elsevier, EBSCO, Thomson, OCLC, JSTOR, Napster,
  Ruckus, etc all have Shib in production or in an
  upcoming release
• Several hundred US universities registered in
  InQueue about seventy-five in production about
  25 in InCommon

17
Grid uses of these tools (GridShib)

• Integration of local and virtual organization
  approaches
• Scalable authentication most developed
• Privilege management
• Compile time authorization
• Audit and compliance
• A large variety of general collaborative tools
  targeted for Grid users

18
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 sets policy and operational
  direction
• Note the discovery of widespread internal
  federations
• Note the bloom of local and ad-hoc federations

19
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.
• Privacy/security defined in the context of an
  enterprise or identity service provider

20
Research and Education Federations

• Growing national federations
• UK, France, Germany, Switzerland, Australia,
  Netherlands, Norway, Spain, Denmark, etc.
• Stages range from fully established to in
  development scope ranges from higher ed to
  further education
• Many are Shib-based all speak Shib on the
  outside
• Working in concert with almost all major
  publishers at this point (Elsevier, EBSCO, Ovid,
  JSTOR, OCLC, etc.)
• Extending into Grids and other international
  collaborations
• EU WG29 may do a year-long study of privacy
  around Shibboleth

21
InCommon E-Auth alignment

• Federal e-Authentication Initiative for general
  citizen controlled access to agency information -
  http//www.cio.gov/eAuthentication/
• promote interop for widespread higher-ed access
  to USG applications
• grants process, research support, student loans
  ...
• process
• project started Oct 2004, thru July 2006
• compare federation models propose alignment
  steps MOU in progress
• validate with federation members, via concrete
  application trials
• good exchanges among GSA, NIST, and InCommon,
  with progress and improvements for all

22
US person

• motivated by InCommon desire for attribute-based
  authorization
• modeled on Internet2 eduPerson spec
• framework on which agency/app definitions can be
  built
• Draft initial attributes and a proposed ongoing
  process
• Parsimonious at the start perhaps higher classes
  plus citizenship, DOB
• Proof of process US information presentation
  subclass
• ambitious? yes ...

23
Federation issues

• Peering, peering, peering
• At what size of the globe? (Confederation?) How
  do sectors relate? How to relate to a government
  federation?
• On what policy issues to peer and how?
• How to technically implement
• Wide variety of scale issues

24
Other inter-federation issues

• WAYF
• Attribute coordination
• Legal framework
• Treaties? Indemnification? Adjudication
• Authorized national backing for federations
• Virtual organization support

25
Key questions in federations

• It doesnt seem to be about the technology or
  model anymore
• SAML 2.0 in most vendors blueprints (except MS)
• Many will ship with a Shib profile
• It is about whether the core IdM systems are open
  or proprietary with open APIs.
• Can federations happen in the US, or will we be
  bi-lateral hell?
• Can they be multi-application or should we have
  library feds (and Elsevier feds) and science feds?

26
USHER

• US Higher Ed Root (aka CREN CA)
• USHER Foundational CA
• Enterprise Root usable for Authn, Encryption,
  Signing, SSL, etc
• Strong enterprise I/A
• Lightweight campus requirements
• No policy requirements
• If you have a policy, post it and follow it (no
  audit)
• Currently at Dartmouth moving to InCommon
• Cheap (you get what you pay for)

27
Identity Access Management Reality

• Each persons online activities are shaped by
  many Sources of Authority (SoAs)
• Institutional policy making bodies
• Resource managers
• Program/activity/project heads
• Self
• Management of the information it conveys should
  be distributed
• Hook up all of those SoAs to the middleware
• Common IAM infrastructure should be operated
  centrally
• To not oblige departments/programs/activities/proj
  ects to build operate their own IAM
  infrastructure

28
Connecting SoAs, Integrating with Existing
Infrastructure
29
Relative Roles of Signet Grouper

• RBAC model
• Users are placed into groups (aka roles)
• Privileges are assigned to groups
• Groups can be arranged into hierarchies to
  effectively bestow privileges
• Grouper manages, well, groups
• Signet manages privileges
• Separates responsibilities for groups privileges

Grouper
Signet
30
Grouper Overview

• Mix of manual and automation processes manage a
  common Group Registry
• Stored in an RDBMS
• Automation processes provision info from the
  Group Registry to wherever the value of the info
  warrants spending the resources to place it there
• Two types of managed objects groups and
  namespaces (or naming stems)
• Groups are created named within namespaces
• Group management authority is delegatable
• By group or by namespace

31
Signet Overview

• Analysts define privileges in Signet in
  functional terms and specify associated
  permissions
• Signet presents this view in a Web UI where users
  assign privileges and delegate authority across
  all areas in which they have authority
• Signet internally maps assigned privileges into
  system-specific terms needed by applications
• Stored in an RDBMS, the Privilege Registry
• Privileges are published as XML docs,
  transformed, provisioned into applications and
  infrastructure services

32
Signet Grouper Roadmaps

• Now available
• Grouper v0.9. Basic group management, full GUI
• Signet v1.0 released earlier this month
• Signet Roadmap
• GUI from Univ of Bristol, England
• v1.1 Toolkit / API release
• Grouper Roadmap
• v1.0, mid-March 2006 compound groups
• v1.1, mid-May 2006 group membership aging

33
Attribute Management DeliveryAffiliation,
Privilege, Privacy
uid jdoe eduPersonAffiliation isMemberOf
eduCourseMember eduPersonEntitlement
SIS
Person Registry
Loaders
HR
Core Business Systems
Group Registry
Grouper
LDAP
Subject API
Privilege Registry
Signet
Distributed Authorities
Shibboleth/ GridShib
Attribute Release Policies
Attribute Authority
ShARPe
Library ERMs/ Self
34
From the plumbers to the fixtures
35
From the fixture designer view

• What to externalize to the enterprise
  infrastructure and when?
• Pressure to have the functionality now
• Pressure to have control over dependencies
• Recognition of the inconsistencies among the apps
• And, specifically

36
The meanings of integration

• Integration is in the eye of the beholder
• End-user GUI integration
• from menus to concepts
• Functionality integration
• When the LMS needs a repository
• Management integration
• Managing users, their permissions, the audit and
  compliance, etc.
• Diagnostics
• Tied into enterprise infrastructure
  directories, authentication, databases, etc.