1 / 17

Credentialing, Levels of Assurance and Risk: What’s Good Enough

Credentialing, Levels of Assurance and Risk: What’s Good Enough. Dr. Michael Conlon Director of Data Infrastructure University of Florida. Goals. A single set of managed credentials Better for the users Better for security Lower cost Enables reasonable cross boundary operations

josef
Download Presentation

Credentialing, Levels of Assurance and Risk: What’s Good Enough

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 2

  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) 3

  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 4

  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 5

  6. 6

  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. 7

  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 8

  9. UF has 5 password policies Attribute P1 P2 P3 P4 P5 1. Minimum length of password 8 8 8 9 9 2. Password is character checked Yes Yes Yes Yes Yes 3. Max age of password (in days) 365 365 180 90 90 14. 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 http://www.it.ufl.edu/policies/passwords.html 9

  10. UF has 427 Roles (and growing) • PeopleSoft Roles 235 • Legacy Roles 126 • Non-PeopleSoft Roles 86 • UF has PeopleSoft HR, Finance, EPM and Portal. Expect to add 100+ roles when student is implemented 10

  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 11

  12. Password Policy Tally as of 2/1/2006 Count PCT Policy 1 0 0.0 Policy 2 175,028 92.3 Policy 3 13,630 7.2 Policy 4 862 0.4 Policy 5 197 0.1 Total 189,717 100.0 12

  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. 13

  14. PasswordPolicy Role Person-UFID-LOA Credential-Username-Password Affiliation Object Relationships 14

  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 15

  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 16

  17. More Information • Eduperson www.educause.com/eduperson • Directory project and structure www.bridges.ufl.edu/directory • Password Policywww.it.ufl.edu/policies/passwords.html • Or writemconlon@ufl.edu 17

More Related