Friends of Penn State (FPS) Jimmy Vuccolo, jvuccolo@psu.edu Technical Manager IdenCty and Access Management Agenda •  FPS Overview •  Problems •  So What’s Next? FPS OVERVIEW What is FPS? •  An authenCcaCon system that allows users outside of Penn State to access Web-­‐based applica5ons inside of Penn State. –  Currently FPS has 1.6+ million idenCCes. –  Features include: •  Web-­‐based account management system (
hSps://fps.psu.edu/). •  Developer APIs. FPS Architecture API Request Web App User App Server & Person Registry Kerberos KDCs Tivoli Directory Servers FPS Components •  CGI Programs (hSps://fps.psu.edu/) –  Create idenCty, change password, reset password, remove idenCty, update informaCon and check idenCty •  HTTPS POST APIs (XML output) –  Create idenCty, change password, reset password, authenCcate idenCty, set data, get data, cerCfy idenCty, un-­‐cerCfy idenCty, lock idenCty, unlock idenCty, remove idenCty, get all data, set all data, and remove role •  Help Desk Consultants Interface Why did we do FPS? •  In 2004, stakeholders were moving more and more of their applicaCons to the Web: –  Undergraduate Admissions –  Office of Human Resources –  Penn State World Campus –  And many more! •  We needed a soluCon to provide authenCcaCon for these applicaCons. How did we do FPS? •  Infrastructure at the Cme (IBM’s DCE) used for Penn States’ Access Account could not support the projected number of idenCCes. –  Because of that, we created a separate authenCcaCon realm, person registry and directory server. FPS Benefits •  MiCgates risk in that FPS users cannot use wireless and computer labs. •  Provides an idenCty instantly as opposed to the standard University process which can take up to 1-­‐3 days. PROBLEMS Data CollecCon •  When we started FPS, we standardized on the amount of data necessary to create an account. •  However without an established policy, stakeholders forced us to lij those requirements. –  Today a person can obtain an FPS Account by specifying only their last name and a E-­‐mail address. Matching •  Each stakeholder area had their own requirements for matching users. –  Undergraduate Admissions: first name, last name, gender, and date of birth. –  Office of Human Resources: first name, last name, email address, postal code, dayCme telephone and evening telephone number. •  We have a match appliance, but its useless because of inconsistent data collecCon. MigraCon •  MigraCon is the moving between FPS and our Penn State Access Account and vice versa. •  From FPS to Access Accounts: –  Only Undergraduate Admissions could idenCty which idenCCes to migrate about 80% of the Cme. •  From Access Accounts to FPS: –  AutomaCcally migrated graduates to FPS. –  About 10% per semester actually set up the FPS account. Another Person Registry •  We already had a person registry for our Access Account holders, which we did not use for FPS, because of that we ran into the following problems: –  Different/incompaCble database technologies (FPS – DB2 and Access Accounts – Oracle). –  A large number of stakeholders chose not to update their person data in FPS, so it became out of date and useless for matching. IAM to the rescue! SO WHAT’S NEXT? How are we fixing things? •  Penn State is currently developing a new Central Person Registry (CPR) that will consolidate idenCty informaCon that is currently stored in separate non-­‐integrated sources throughout the University. CPR Architecture Service Service Providers Provisioners Systems o
Systems of f Record Record Database Database RegistraCon RegistraCon AuthoriCes AuthoriCes Web Web Services Services Central Person Registry Data Data Views Views HOW DOES THE NEW CPR ADDRESS FPS’S PROBLEMS? Data CollecCon/Matching •  We are requiring a consistent minimum amount of data to be collected to idenCty a person in our registry (backed by policy). •  If the data requirements are not saCsfied, the user can sCll exist in the registry, however they will not be used as part of our matching process. MigraCon •  By extending the digital lifecycle of students and/or employees, we will no longer have a need for migraCon between realms. Another Person Registry •  Yes, the CPR is another registry except it will be the only one. WHAT ABOUT AUTHENTICATION? OpCon #1 •  Do another guest system, except this Cme: –  Use the CPR for the registry (a single registry). –  Use a common name space. –  Develop a new RegistraCon and Provisioning Process –  Only migrate data to “prime” the CPR from FPS that we know is good, throw everything else away. OpCon #2 •  Convince stakeholders to embrace social media and/or other idenCCes (OpenID). –  CPR will store which idenCty the user is using. –  This soluCon is a tough sell. OpCon #3 •  Use a combinaCon of OpCon’s 1 and 2 for the short-­‐term and once a comprehensive Access Management soluCon is in place, provision Access Accounts for everyone. –  Currently at Penn State AuthN == AuthZ, in the future that will change with things like IAP, affiliaCons and so on. In Summary •  FPS solved a need for a guest system and helped to miCgate risk. •  With FPS comes a number of problems, like matching and data collecCon. •  The new Central Person Registry will solve all of FPS’s problems and loads more! Contact and Community InformaCon • E-­‐Mail: iam@psu.edu • Web Site: hSps://iam.psu.edu/ • Follow “PennStateIAM” on: –  Delicious –  TwiSer –  YouTube –  Facebook When the Guests Take Over the House
InCommon CAMP June 2011
Columbus, Ohio
RL "Bob" Morgan
University of Washington
Co-Chair, InCommon TAC
Topics
• Guest systems at UW
• Social<->SAML
• Why systems must grow
• NSTIC / Identity ecosystem
• Registries
• It's all about attributes
2
Guest-NetID Systems at UW
• "temp netid"
– explicitly for "temporary" access, so non-personal, no linked
services; mostly for UW-wireless-to-Internet access
• new "manual" sponsored UW NetID processes
– "Bronze" process == "deferred" identity proofing
– "Silver" process == equivalent-to-hiring ID proofing, but can be
done by any staff member ...
– new Person Registry Web Service for reduced-latency
programmatic person-entry creation
Some UW Use Cases
• UW Educational Outreach Testing Service
– 40K users/year for statewide online testing
– use social IDs? SP site would have had to integrate, so a socialSAML gateway might have helped
– but UW has interest in getting these people UW NetIDs ...
• School of Social Work new online mentoring service
– starting with 5K email addresses, want to create accounts; how
to do "verified email address" ?
– does UW NetID guest process help? not really ...
More UW use cases
• Clinical Informatics
– building prototype systems for clinical outreach
– UW participants, also local accounts, also those wanting to use
social accounts, so built multi-login, with account linking
InCommon "SocialID" collaboration
• many sites working on social-id integration for campus SPs
• taking a close look at gateway solutions
– OpenID or multi-protocol? how many providers?
– how is identity info mapped to SAML attributes?
– transparency of gateway
• should InCommon offer a gateway as a service?
– or are gateways less problematic when run at more local scale?
– some successful businesses in this area (Janrain, Gigya)
Facebook: an eco-tale
• value begins in a community, by definition exclusive
• a successful community grows: not every person of interest
goes to Harvard ...
• exclusivity is recreated in the larger system via other means
• every successful system aspires to global scale
– i.e., no built-in barriers to who can be assimilated, er, who can
participate
• so too with the systems we build to support our institutions
• but global domination tends not to last forever ...
NSTIC
• National Strategy for Trusted Identities in Cyberspace
– Obama administration initiative to promote "identity ecosystem"
– http://www.nist.gov/nstic/, run by NIST / Dept of Commerce
– gov encouragement of private-sector work
– "Individuals and organizations utilize secure, efficient, easy-touse, and interoperable identity solutions to access online services
in a manner that promotes confidence, privacy, choice, and
innovation." (also: passwords are bad)
– many stakeholders: social providers, HE, financial, retail, law
enforcement ... almost everyone
– sound familiar? InCommon/HE has been template for this vision
Social Provider Evolution
• not just throwaway email addresses any more
– stable, long-term, reality-linked personal/social identity is the core
of their business model (i.e., selling that identity info)
• having your account hacked is a bad user experience
– biggest problem is username/password reuse across sites
– Playstation (etc) breakin ripples across industry, creates great
understanding of password risks, promotes interest in federation
• making huge investments in login system protection
– global monitoring, pattern matching, "login resistance"
– meets assurance goals even without strong passwords?
Social Identity Provider Next Steps
• linking with mobile telephony providers
– every mobile phone is potential strong authentication device,
linked to real-world identity via credit cards
– reduce/eliminate passwords via OAuth, OpenID Connect
– create cross-industry business model
• recognition?
– face recognition, behavior patterns, ...
• building value for relying parties
– in support of that (inter)national strategy ...
– and how does the privacy part work?
Role of HE Identity?
• if "social" identity really becomes better ...
– then it won't just be for guest users, it will be for (potentially) any
user
• if authentication isn't our core value ...
– then it's about attributes, relationships: student, faculty, staff,
researcher, resource entitlements, group memberships, course
roles, etc: stuff we're doing anyway
– NSTIC envisions role of attribute providers distinct from
authentication providers;
HE can lead the way again ...
Future of "Guest" Systems
• We're all guests
– some just stay longer than others ...
• Identity linkage/agility is key
– federation will be "in the platform" of systems we deploy, whether
on-premise or in the cloud
– campus netid systems won't go away, but person registries must
support verified linkage with other identities
– role for multi-institution person registry services? privacy?
• User experience is key
– invitation-based workflow, profile access