Current stuff (or things no one else has talked about yet) (at least while I was in the meeting)

1
Current stuff(or things no one else has talked
about yet)(at least while I was in the meeting)
Ken Klingenstein Director, Internet2 Middleware
and Security
2
Topics

• Federating software update
• Federations update
• International
• InCommon
• US Gov Eauth federation InCommon B/S
• Peering of federations
• USHER and PKI
• FFIEC
• User-centric identity, CardSpace, SXIP, etc. and
  the Holy Grail of Identity Management
• But its really about authorization SOX,
  Privilege Management, Signet and Grouper
• The wisdom and folly of Anders rant

3
Federating Software Update

• Shib 1.3 in production for a long time
• MS WS-Fed capable
• E-Auth certified
• GridShib basic capable
• Shib 2.0 out at the end of the year
• Shib-a-likes
• Sun Federation Manager and Shib 1.3/2.0
• Others

4
Application integration

• Access to online content, from scholarly to
  popular
• Access to digital repositories and federated
  search
• Submissions of materials, from grant proposals to
  tests and exams
• Non web applications p2p file sharing, Grids,
  etc. are beginning to leverage federated
  identity

5
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

6
Shib Add-ons

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

7
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 a hundred in production about 30
  in InCommon

8
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 SAML on the
  outside
• Several million users and growing
• First goals are content access additional goals
  include bandwidth allocation, network monitoring,
  security, etc.

9
US Federations

• InCommon
• (InQueue)
• State-based
• Texas, UCOP, Maryland, etc.
• For library use, for roaming access, for payroll
  and benefits, etc.
• US Gov Federal eAuthentication Initiative

10
InCommon

• US RE Federation
• www.incommonfederation.org
• Members join a 501(c)3
• Addresses legal, LOA, shared attributes, business
  proposition, etc issues
• Approximately 35 members and growing
• A low percentage of national Shib use

11
Key questions in federations

• It doesnt seem to be about the technology or
  model anymore
• SAML 2.0 in most IdM vendors blueprints (except
  MS) some will ship with Shib profiles embedded
• It is about whether the core IdM systems are open
  or proprietary with open APIs.
• What is the integration with other trust fabrics
  (e.g. eduRoam.us, PKI hierarchy, state and local
  federations)
• Can federations happen in the US, or will we be
  bi-lateral hell?

12
Inter-federation key issues

• Peering, peering, peering
• At what size of the globe?
• Confederation
• Tightly coupled autonomous federations
• How do vertical sectors relate? How to relate to
  a government federation?
• On what policy issues to peer and how?
• Legal framework
• Treaties? Indemnification? Adjudication
• How to technically implement
• Wide variety of scale issues
• WAYF functionality
• Virtual organization support

13
In the USInCommon US Gov Fed alignment

• Promote interop for widespread higher-ed access
  to USG applications
• grants process, research support, student loans
  ...
• Static peering
• Of InCommon Bronze/Silver and EAuth
• InCommon Bronze is a subset of InCommon, with a
  defined set of Identity procedures and federation
  operations
• Definition of peering attribute mappings, LOA,
  legal alignment, etc.
• Draft SAML 2.0 eAuthentication Profile
• Draft USPerson

14
InCommon Bronze/Silver

• InCommon B/S is a higher assurance sub-federation
• Federation operations up a notch over InCommon
• Members do better Identity Management
• Bronze members likely a small subset of InCommon
  members common management infrastructure
• Differences may include
• Password management and identity proofing for
  some users most users may still be lower level
• Liability and indemnification
• Explicit operational responsibilities for members
  and federated operator (signing key revocation,
  etc)
• Internal audits once a year of IdM practices

15
Coordinating with big players

• Content providers heavily federation oriented
• Almost all major academic content providers now
  support Shibboleth and federated identity
• Important issues include
• Presenting selection of federations and IdPs to
  users
• Simple approach to common attributes and release
  policies
• Business model implications
• MS using federations to distribute student
  software

16
Virtual organizations and federations

• One major driver for federations is their ability
  to support effective and scalable AAI for virtual
  organizations.
• Numerous GridShib projects exist, perhaps too
  many
• Can a set of peering federations be in place to
  support federated Grid implementations and what
  are the transition strategies?
• Support the metadata exchange and consistency

17
GridShib

• A set of approaches seeking to leverage the
  strengths of federated identity and privilege
  management with science Grids
• Projects in 6-8 different countries, addressing
  different stress points in grids today.
• Some are kludge layered on kludge some are steps
  in a long-term set of strategies

18
Overall strategy

• Provide a coherent experience to the user,
  integrating their primary employer IdM with their
  research science needs for authentication and
  privilege management
• Build an operational trust/attribute layer of
  federations of enterprises to support clusters of
  virtual organizations.
• Based on Shibboleth and Signet/Grouper and
  Globus, etc.

19
Usher Update

• It is operational
• Operations at I2 and Dartmouth
• PA chaired by Jim Jokl
• Cert profiles, CP/CPS baked
• LOA-free
• A fee schedule is being finalized
• A few use cases, but applications, sigh

20
FFIEC

• Insufficiency of single factor authn for most
  on-line banking transactions
• Lots of alternatives
• many banks preferring OTP (paper/electronic)
• digital sig otps
• smartcards
• Passive secondary authentication technologies
  being marketed
• Dynamic risk assessment approaches tied into a
  web-management system
• Phishing is equally important as authn due to
  e-commerce multifactor does not address well

21
Peer to peer trust and identity

• A large part of our real lives
• Has taken lots of on-line forms
• PGP for email
• SXIP, Higgins, etc for identity
• Names versus locations as the permanence
• In Vista as Cardspace (formerly InfoCard)
• Self-signed X.509 deep under the covers
• A great GUI and tight coupling to MS applications
  (videoconferencing, signed email, firewall, file
  sharing, etc.)

22
User-centric identity

• The integration of the two main streams of trust
  
• The enterprise, and federated, IdM
• The peer-to-peer and group trust of social
  networking
• Many layers of issues
• The ones that matters most are the ones closest
  to the user (the eyeballs and the brainmap)
• OSIS as an open source effort in this space

23
Its authorization, stupid

• The real issues (once authn is done) are
  authorization.
• SOX, HIPAA, etc really are authz policies
• Authorization can be thought of as two phases
• The compile time assignment of permissions,
  rights, etc to things
• The run time decision on whether to grant access
  by the resource provider
• The interesting stuff is the compile time pieces

24
Connecting SoAs, Integrating with Existing
Infrastructure
25
Signet and Grouper

• Tools to manage privileges and groups
• Taken together, they can provide tools for the
  static part of the authorization problem
  management of roles and privileges assigned to
  individuals (and other things)
• Newly released 1.0 versions of both, with a
  combined interface
• International development community beginning to
  happen

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

28
Grouper Architecture
29
Five Ways to Delegate Group Management

1. Create a group and assign someone to manage its
   membership (UPDATE)
2. Create a group and assign someone to manage who
   manages the groups membership and who can see
   what about the group (ADMIN)
3. Create a namespace and assign someone to create
   groups within it (CREATE)
4. Create a namespace and assign someone to manage
   who can create groups within it (STEM)
5. Allow Self to OPTIN or OPTOUT of membership

30
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

31
Privileges Building Blocks

• Functional view
• Subsystems
• Categories
• Functions
• Scope, Limits
• Prerequisites Conditions

• System view
• Permissions
• Subject
• Action
• Resource

32
Signet Components
Financial system Student Administration HR
system Network access management Research
administration Clinical resources XYZGrid Signet
(Privilege Registry) Grouper (Group Registry)
Subsystems

• Define domains of ownership and responsibility
• Reflect real world boundaries
• Can be large or small

33
Functional View
Subsystems contain

• Limits
• Qualifiers, constraints for a privilege.
• Scope
• Organizational hierarchy governing distributed
  delegation,

• Functions
• The things a person can do what they are
  getting privileges for.
• Categories
• Provide useful arrangement of functions within a
  subsystem for reporting, ease of use.

34
Functional View ? Permissions
Calendar
Student Admin
reserve_time
view_schedules
Add/Drop students
Course Support
Course
Schedule Classes
update_course_data
Facilities
reserve_room
Process Applicants
Financial Aid
Financial
Award Scholarships
view_fund_data
Manage Accounts
update_fund_data
Student
student_records
categories
functions
applicant_data
Resources/Permissions
Functional View
35
Provisioning Permissions into Applications
(connectors)
Calendar
CourseWare
Financials
Reporting
or
API
Space Mgmt
Student
36
Provisioning Permissions into Infrastructure
(LDAP)
Calendar
eduPersonEntitlement
CourseWare
Directory
Financials
Reporting
Space Mgmt
Student
37
Privileges Lifecycle

• Conditions
• Provides automatic revocation of privileges
• Date controls -- from date, until date
• Based on persons status, affiliation, etc.
• e.g., as long as person is at Stanford
• Prerequisites
• Pre-conditions that must be met to activate
  privileges
• e.g., training

38
Privilege Elements by Example
By authority of the UPCI IRB grantor
UPCI Researchers grantee (group/role)
who have an approved UPCI IRB protocol prerequisite
can access de-identified data and order tissue function
from the network of caTIES participants scope
for Study HD7687 resource
up to 100 patients limit
until January 1, 2006 as long as approved for material transfer conditions
Lifecycle
Privilege
39
The duck test

• Grouper
• Binary info youre either in some list or not
• Identity- or affiliation-based access control or
  distribution
• Identification layer of an encompassing access
  management scheme
• Locally tweak or combine other groups

• Signet
• Structured, qualified info limits, conditions,
  scope,
• Oriented to individuals rather than roles
• Human judgment and chain of authority essential
  for access decisions
• Enable functional, not just technical, people to
  manage privileges
• Supports policy control closer to source of
  authority
• Audit requirements

40
Anders Rant 1

• Its enterprise to enterprise that matters
• That implies that roles are useful and important
• That provides some degrees of enterprise freedom
• Reasonable non-repudiation is reasonably easy

41
Anders Rant 2
42
InCommon B/S

• We have used a combination of feedback from this
  credential assessment, the entropy tool, and NIST
  guidelines to determine what was needed to reach
  LOA1.  We have applied a password policy for all
  passwords that are changed that include the
  following
• 1. It must be at least eight characters in
  length (Longer is
•    generally better.)
• 2. It must contain at least one alphabetic and
  one numeric character.
• 3. It must be significantly different from
  previous passwords.
• 4. It cannot be the same as the userid.
• 5. It cannot start or end with the initials of
  the person issued the
•    userid.
• 6. It cannot include the first, middle, or last
  name of the person
•    issued the userid.
• 7. It cannot contain three or more occurrences of
  the same character.
• 8. It cannot contain any special characters
  (blanks, single quotes,
•    double quotes and so on).
• 9. It should not be information easily obtainable
  about you. This
•    includes license plate, social security,
  telephone numbers, or
•    street address.
• We are also in the process of determining the
  best approach and starting communications for
  enforcing annual password changes.  We believe
  with these changes we are very close to meeting
  requirements for LOA2 as well.