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

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 Ander’s 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 R&E 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 doesn’t seem to be about the technology or model anymore SAML 2.0 in most IdM vendor’s blueprints (except MS); some will ship with Shib profiles embedded It is about whether the core IdM systems are open or proprietary with open API’s. 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 US… InCommon –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 IdP’s 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” otp’s 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 trustand 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 Grouper Signet 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

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 group’s 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 Define domains of ownership and responsibility Reflect real world boundaries Can be large or small Financial system Student Administration HR system Network access management Research administration Clinical resources XYZGrid Signet (Privilege Registry) Grouper (Group Registry) Subsystems

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 Resources/Permissions Student Admin Functional View Course Support Add/Drop students Schedule Classes Process Applicants Award Scholarships Manage Accounts Financial Aid reserve_time view_schedules student_records applicant_data view_fund_data update_fund_data update_course_data reserve_room Calendar Course Facilities Financial Student categoriesfunctions

35. Provisioning Permissions into Applications (connectors) or API reserve_time view_schedules student_records applicant_data view_fund_data update_fund_data update_course_data reserve_room Calendar Course Facilities Financial Student Calendar CourseWare Financials Reporting Space Mgmt Student

36. Provisioning Permissions into Infrastructure (LDAP) reserve_time view_schedules student_records applicant_data view_fund_data update_fund_data update_course_data reserve_room Calendar Course Facilities Financial Student Directory eduPersonEntitlement Calendar CourseWare Financials Reporting Space Mgmt Student

37. Privileges Lifecycle Conditions Provides automatic revocation of privileges Date controls -- from date, until date Based on person’s 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 Privilege Lifecycle

39. The duck test… Grouper Binary info – you’re 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. Ander’s Rant 1 It’s 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.