Presentation on theme: "Credentialing, Levels of Assurance and Risk: What’s Good Enough Dr. Michael Conlon Director of Data Infrastructure University of Florida."— Presentation transcript:
Credentialing, Levels of Assurance and Risk: What’s Good Enough Dr. Michael Conlon Director of Data Infrastructure University of Florida
2 Goals A single set of managed credentials –Better for the users –Better for security –Lower cost –Enables reasonable cross boundary operations Level of Assurance appropriate for business need Strength of credential appropriate for business need
3 Authentication Usernames and passwords -- stronger passwords for stronger credentials Two factor authentication is even stronger – PKI, Biometrics, SecureID Strength of credential (password policy) determined by business requirements (affiliations and authorizations)
4 Affiliations Each person has one or more affiliations with the institution. Student, Alum, Parent, Staff, Emeritus Faculty, Contractor, … (UF has 57 affiliations) These roll up to 7 Eduperson affiliations – faculty, staff, student, alum, member, affiliate, employee Affiliations drive authorization by policy
5 Authorization The unit of authorization is a role. A role grants access to a service. Examples: –UF_PORTAL_USER – grants access to my.ufl.edu, the UF Portal. All Faculty, Staff and Students have this role –UF_GRADER – grants access to assign grades –UF_GM_BUDGET_APP – grants access to approve grant budgets –Roles are often scoped with parameters
7 The basic idea Control the strength of the user’s credential by the roles assigned to the user –Each role has an associated “password policy” – roles that provide limited access are assigned low password policy. Roles that provide broad access are assigned high password policy –A user’s password policy is the maximum of the password policies assigned to the roles belonging to the user. –As roles are granted or rescinded, the users password policy automatically goes up or down.
8 What’s a Password Policy? A password policy is a collection of attributes that define how the password must be managed: –How often must it be changed? –Can it be changed on line or only in person? –Can a password hint be used? –How long must the password be? –How complex must the password be? –And so on
9 UF has 5 password policies Attribute P1 P2 P3 P4 P5 1. Minimum length of password Password is character checked Yes Yes Yes Yes Yes 3. Max age of password (in days) Security class before pwd is issued No No No Yes Yes 15. Must use 2-factor authentication No No No No Yes 16. Account is expired if pwd is cracked No No No Yes Yes Each policy has 16 attributes – see
10 UF has 427 Roles (and growing) PeopleSoft Roles235 Legacy Roles126 Non-PeopleSoft Roles 86 UF has PeopleSoft HR, Finance, EPM and Portal. Expect to add 100+ roles when student is implemented
11 The Rationale for various password policies P1– used for applicants, guests, visitors – limited interaction with university information systems P2 – information about oneself. Students. Some staff P3 – provide and access information about others. Faculty and most admin staff P4 – Significant authorization to allocate university resources. Core, Dean and VP admin staff P5 – Direct access at system level to university systems
12 Password Policy Tally as of 2/1/2006 CountPCT Policy Policy 2175, Policy 313, Policy Policy Total189,
13 Password Policy is not Level of Assurance Level of Assurance answers the question “How sure are we that this person object represents that person?” UF has two levels of assurance – “Strong” (picture ID and physical presence) and “Weak” (web or mail process). LOA is an attribute of the person object in the directory. Password Policy answers the question “How strong is this credential?” Password policy is an attribute of a role.
15 Some Technical Details 1.5 M Person Objects in Registry in mainframe in DB2 Roles are stored and managed in PeopleSoft Password Policies are stored and managed in PeopleSoft Passwords are managed in PeopleSoft Credentials are managed in legacy apps – will be managed in PeopleSoft Affiliations are managed in Registry Active Directory has all user objects with credentials LDAP has all user objects
16 Some Policy Details and Consequences Identity is established by 800 directory coordinators Identity resolution is manual, 50 cases per year Identity theft is rare, 1-2 cases per year All users are required to change passwords at least each year All passwords are strong Password hints have reduced help desk calls
17 More Information Eduperson Directory project and structure Password Policy Or write