january 5, 2006common solutions group winter meeting @ duke csg - policy discussion identity...

January 5, 2006 Common Solutions GroupWinter Meeting @ Duke

CSG - Policy DiscussionIdentity Management Practice

Bruce Vincent, Stanford

Gary Chapman, NYU

Tom Barton, University of Chicago


The Question at Hand…

How do [we] verify a person is who they say they are…at first

and over time?


IdM Practice - Scope of Discussion

Reflecting on…• Institutional processes and tools to

assure that identity and identifiers are linked; initially and over time.

• How schools verify that a person is who they say they are…as long as it matters.

• What assurances are good enough.


"Getting to know you, getting to know all about you".

• How does our government identify the domestic population?

• How do universities manage identity about populations/individuals?

• Other major institutions?


Federal and State Government

• Birth certificates & other municipal credentials• Federated ID - State Driver’s License• REAL ID Act and State ID requirements

– Standardizes bootstrapping documentation– Establishes common practice for renewal– Federalizes authority and penalties

• …and the good old IRS

http://thomas.loc.gov/cgi-bin/query/F?c109:3:./temp/~c109abYQf5:e46432:


IdM Business Practice: U.S. Universities

• Varies between universities and their schools• Varies between populations i.e. types of

affiliation– Student (academic record)– Foreign student (…+ a U.S. Visa) – Staff (I-9 employment standards)– Faculty (varies by profession)


I-9Form


IdM Business Practice: Other Institutions

• FFIEC (Clearinghouse for U.S. Financial Audit Requirements)

• FDIC strongly recommending T-FA• Credit bureaus

http://www.ffiec.gov/default.htm

http://www.fdic.gov/consumers/consumer/idtheftstudy/technology.html#part5


Topic 2: How Well Does IT Practice Reflect Policy?

• Policy? Often IT has created business practice in the absence of policy.

• For employment, compliance to I-9 is consistent…

• Where required, more is done to bind identity to identifiers.

• Central IT is a partner in IdM processes


Examples of University IdM Practice

• Stanford University

• New York University

• University of Chicago


Stanford University IdM Processes

• Historically separate applications for Student and Faculty/Staff identity

• Merged populations in 1986 and created UnivID; stopped use of SSN broadly

• No reuse of identifiers…now 280,000• Recent audit response has password

expiry for some roles


Identifier Management at NYU

Identifier Management

At NYU

Gary ChapmanNew York University

January 5, 2006



14 schools, colleges and divisions (including professionalSchools -- Medicine, Dentistry, Business, Law)

16,000 employees (not including Medical Center)

Students:Total: 50,917Undergraduate: 19,401

Graduate and Professional: 18,990Non-credit Programs: 12,526

Programs abroad in Florence, Prague, London, France, etc.

Some NYU Background



Person Registry: 1 million records with NetID and University ID assignments; 4 million records in total with University ID assignments; fed by systems of record.

Now initiating formal Identity Management program: a series of projects to enhance Identity Management at the institution• proof-of-concept phase, with implementation of Sun-One Identity Management Suite, policy and architecture development, staff education, client buy-in• progressive phases of implementation: integration of centrally-managed systems with enterprise IdM system for provisioning, access management, privilege management

Some NYU Background, con’t



• we authenticate people, so that• we can authorize them for electronic capabilities based on our policies and their relationships to the institution.

Identifiers are the “handles” we use to link people with their electronic capabilities.

We keep track of these identifiers in any number of repositories (such as directories, password files, etc.)

NYU has two main identifiers• University ID (for tracking everybody) - e.g.

N12345678• NetID (for electronic use) - e.g. gwc1

Where do “identifiers” fit in?



• Many people have been assigned multiple identifiers; people continue to be assigned multiple identifiers (at a low rate)

• We haven’t tracked down all the cases

• We haven’t yet tightened procedures so as to largely eliminate the problem continuing

• We find out about such discrepancies typically as a consequence of service-level problems (unhappy people!)

• we are devoting approximately 1 FTE to record clean-up

• if identifier assignment is at the core of our service provision, and this process is suspect… what risks, if any, do we incur?

Our identifier “problem”



• Not bad… if intentional

• If unintentional, problems arise services are built on the assumption that a person has a single identifier within a domain

• aggregating systems will not present a unified view

• tracking or auditing utilization will not be accurate

• decisions based on the fact that a person is, e.g. both a student and an employee cannot be accurately made: our internal, electronic knowledge of our community will not be accurate (e.g. if you decide all students must opt-in to public directory)

• actions relating to the person may be misdirected (e.g. person has two e-mail addresses, but only uses one, and messages are sent to unused address)

So what’s wrong with multiple identifiers?



Identification is the initial step of creating new identity records and assigning identifiers to individuals.

This is not done, for historical reasons, in a consistent and systematic way across the several ways that people are initially recorded in systems. E.g. compare student applicants (not on campus) with prospective employee.

Checking to see if a person is already known to university systems is highly variable.

So, we have different processes for employees, students, affiliates… yet we assign identifiers and then consider them equally valid and equally “good to go”.

Source of our problem



What to do?

• Understand entry points and identification processes now in effect

• Figure out goal state, e.g.

• reduced number of entry points?

• more consistent collection of more identity attributes?

• minimal creation of new identifier problems

• Develop an identification policy? (Hey, who’s in charge?)

• Implement new procedures, improved record checking, e.g. matching on more than SSN…

• Proactively clean-up current record discrepancies as possible

• Use re-identification opportunities (e.g. password forgotten, ID Card expired, etc.) to vet current data, collect more identity attributes for people


Identity and Identifier Management at NYU

What’s next?

Identifiers Real-time identifier assignment; further integration with SoM

Person Registry Data-cleaning improvements; integration with PASS; on-line ID Card application

Directory Services Increased use by applications; augment with groups data; online public directory data available from UDW

Groups & Roles Registry groups improvements; track Grouper initiative

Account Provisioning Integration with Active Directory implementation

Authentication Required, regular password changing; strengthen complexity; two factor authentication

Authorization ID Card swipe authorization based on Registry groups/roles; track progress of Signet initiative

Federated Identity Track progress of E-Authentication initiative, involvement soon?

Planning Planning for an enterprise system: pilot Sun IdM Suite?


IdM “Assurance Classes”• Increasing level of assurance (LoA) required

for some services– Data classification, other local policies– Response to HIPAA, SOX, GLB, eAuth– other Jones’ to keep up with

• Minimal LoA required for others– Low bar for loosely affiliateds, but also limited

access• Typical services lie somewhere in between• Determines classes of people by high water

mark LoA requirement


Assuring Assurance

• A single one-size-fits-all authentication service won’t do

• Range of motion– Additional, stronger, authentication– Multiple authentication services– Multiple accounts or account instances– Accounts assorted into classes– Multiple identity providers

• Must avoid that last possibility!– Want ubiquitous adoption of netIDs


UFlorida Password Policy Classes

• P1 : Entry. Vendors, guests, student applicants, HR applicants

• P2 : Low. Access to information only about yourself.

• P3 : Medium. Access to information about others. Provide data at unit level.

• P4 : High. Access to information at the institutional level

• P5 : Rigorous. Control institution systems.


Password Policies

• Characteristics– Run-time: length, charset, lifetime, history– Password set/reset process

• Self-serve, phone, F2F– Account lockout??

• Implementation within IdM system– Arrange for assurance obligations of each account

to be inferred or tagged– Authentication service support for run-time

characteristics??– Notification processes


Topic 3: Context Changing for

Business Practice• Regulatory controls increasing (e.g.

CALEA, HIPAA, SOX)• Risk Management context changing…

more online of value• Identity theft is a growing problem• Individuals demanding more privacy• More focus on role-based privileges


cont. Context Changing for Business Practice

• Federations and digital trust relationships

• Support transient populations


Where are the gaps?

Three different concerns over IdM at our respective institutions:

- Gary at NYU [done]

- Tom at U of Chicago [done]

- Bruce at Stanford


Discussion and Questions

…and a parting goal for all of us…

“There’ll be no more talking to Who’s who are not!”

Dr. Seuss

january 5, 2006common solutions group winter meeting @ duke csg - policy discussion identity...

Documents

duke slide

common practice

duke idm business practice

duke federal

duke topic

profession slide

form slide

duke idm practice scope