1 Identity Management and Access Control Status UNITS Forum, June 2006 Tom Board, NUIT Info Systems Architecture

2 Agenda Current Project Status –Identity Management, Access Control, Directory Services Futures –Multi-factor Authentication, Federation, Trustworthiness, Roles Plans Short Q/A

3 Definition: Identity Management Processes and policies to manage: –The assertion and identification of principals –The assignment of credentials –The granting of entitlements –The lifecycle of credentials –The retirement of credentials NetIDs, driver’s licenses, credit cards, Marlok, WildCard

4 Definition: Access Control Access Control is the real-time, technical process of: –Examining and verifying credentials presented by a principal (authentication) –Examining entitlements assigned to those credentials, and deciding to allow or deny use of a resource (authorization) –Logging access attempts and their results The goal: make access accountable to an individual – not impossible for anyone else

5 Definition: Directory Services Directory services are database services which manage and expose the attributes of those entities requiring validation and authorization within the University network Services are multi-protocol –LDAP, Kerberos, Active Directory

6 IdM/AC Project Replace locally-developed IdM software with a standards-based commercial package Add Web SSO – deployed! Add multi-factor authentication Support security services for a future Service- Oriented Architecture deployment Use workflows and roles to grant and remove access Support trustworthy federated services

7 Replace Local IdM Replicate local IdM functions within a more readily maintained and rapidly extended environment Continue delegated administration Minimize visible changes for users Parallel operation and gradual migration Timeline: months –January 2007 or June 2007

8 Today

9 Tomorrow

10 Central AD Services New Windows 2003 R2 forest – June 2006 –Migrate NUIT applications – October 2006 –Migrate other applications – December 2006 Shut down current forest – June 2007 Migrate synchronization of subsidiary forests – June Delegated OU services –NUIT by December 2006 –Open to other units early 2007?

11 Futures Multi-Factor Authentication

12 Single Identity & Risk Aggregation Silos of identities and credentials give an illusion of security, but people won’t remember 10 passwords or carry five swipe cards –Supervisors must contact each silo to end access for a separating employee A single identity and few credentials make the user’s job easier and separations rapid and reliable –However, a single identity and credential, valid on many systems, increases risks if it is compromised

13 Multi-factor Authentication Confidence in authentication can be increased by multiple credentials (factors) –“… two forms of identification …” –Password plus fingerprint, etc. Multiple factor authentication is expensive and inconvenient –Deployment should be targeted to protect high-value information or transactions - not just ones where one might wish to be more confident Management of tokens is costly Deployment of biometrics is very costly

14 Strategy Deploy two-factor authentication to mitigate aggregated risk of single identity (NetID) and password. But, target deployments to control cost and support complexity Carefully coordinate between token- issuing offices (WildCard, FM) to combine tokens where possible.

15 Futures Federation

16 Federation A federation is a group of identity realms which agree to accept one-another’s assertions of authentication (e.g. inCommon) Federated authentication is a necessary future step to minimize the overhead of operating collaborative groups and vendor relationships –Other research universities and centers –Government agencies –Suppliers (pair-wise) Federation is built on trust in the validity of your partner’s authentication processes

17 Federation Can “B” trust “A”? What if “A” is wrong?

18 NU Federation Issues How will NU negotiate federations? Will federated authentication be transitive? What about authorization?

19 Futures Trustworthiness (or Level-of-Assurance)

20 Trustworthiness of a Credential For a given credential, trustworthiness quantifies the level of confidence an Access Control process can place in the assertion, “This credential is being presented by the exact principal to whom it was associated in the Identity Management process.” Trustworthiness comes from both confidence in the identity itself and properties of the credential –Process of identifying the principal and issuing the credential –Managing the credential over time –Inherent difficulty in abusing or forging the credential –Process for retiring the credential

21 Northwestern’s Identity Structure

22 Trustworthiness is Real Issue Some trustworthiness decisions are made for us by others: –Department of Education “Standards for Electronic Signatures in Electronic Student Loan Transactions” Federal Personal Identity Verification program: –Confidence: SOME, HIGH, and VERY HIGH Government e-authentication program will use federation – which relies upon our institutional trustworthiness

23 NU Trustworthiness Issues Will trustworthiness requirements drive less convenient identity procedures? NU must decide the level of trustworthiness required for its own functions: –Registering for a class –Changing direct-deposit information –Entering into a housing contract –Submitting an electronic timesheet –Viewing versus changing grades, salaries, etc.

24 Futures Roles

25 Roles – What’s the Buzz? A role is a usually descriptive name for a collection of permissions to view data or execute processes. If it were possible to determine a person’s “institutional role” from HR information, then services could be provisioned across all enterprise systems automatically – saving time and effort.

26 Application Roles An application role is an attribute of the user’s application profile, and is of no interest outside the application – it is security-oriented. The application role bundles, into one descriptive package, many individual permissions to view data items and initiate processes within the application. Virtually all enterprise applications use this model to manage security.

27 Enterprise Roles An enterprise role is an attribute in a central directory used for management of entitlements across multiple application systems Each application can choose to map an enterprise role into one or more application roles appropriate for that category of principal The specification of enterprise roles is a difficult problem

28 Roles

29 Roles Prognosis Some enterprise roles already exist (“student”, “employee”, “faculty”) and could be used today Administrative Data Council is working on general enterprise role definitions Definition, implementation, and mapping from enterprise roles to application roles could take several years

30 NUIT Plans in Motion

31 NUIT Plans The Northwestern situation and plans Trial two-factor authentication in summer 2006; initial deployments by year’s end Replace SNAP by end of January 2007 Drive all applications to use central identity through access management services by June 2007

32 NUIT Plans Implement federation technologies within 12 months –But joining federations could take longer to negotiate Start discussions about –Trustworthiness for business functions –Ultimate extent of two-factor authentication

33 Questions? Q A &