NMI-EDIT Identity Management Tutorial NMI Tutorial February, 2004

NMI-EDIT Identity NMI-EDIT Identity Management TutorialManagement Tutorial

NMI TutorialFebruary, 2004

NMI TutorialFebruary, 2004

Michael Berman, VP, CSU-Pomona

Keith Hazelton, Dir. Arch., Wisconsin

Jack Suess, CIO, UMBC

Ann West, NMI-EDIT Coordinator

CAMP Directory Workshop Feb 3-6, 2004

CSU Identity Management CSU Identity Management DefinitionDefinition

– CSU definition - An identity management infrastructure is a collection of technology and policy that enables networked computer systems to determine who has access to them, what resources the person is authorized to access, while protecting individual privacy and access to confidential information.


““Identity Management System”Identity Management System”

Suite of campus-wide security, access, and information services– Integrates data sources and manages information

about people and their contact locations– Establishes electronic identity of users– Issues identity credentials– Uses administrative data and management tools to

assign affiliation attributes – …and gives permission to use services based on

those attributes


Key terms: Key terms: Enterprise Directory ServicesEnterprise Directory Services

Enterprise Directory Services - where electronic identifiers are reconciled and institutional identity is established and maintained for all people of interest

– Very quick lookup function

– Machine address, voice mail box, email box location, address, campus identifiers


More key termsMore key terms

Authentication (AuthN)– Process of proving your identity by “presenting” an identity

credential – In IT systems, often done by a login process

Authorization (AuthZ)– Process of determining if policy permits a requested action to

proceed using attribute & group information– Often associated with an authenticated identity, but not

always and not necessarily



Infrastructure for Identity Infrastructure for Identity ManagementManagement

Common elements–Core Business System - system for identifying university

membership (e.g. SIS, HR, Alumni)–Registry - aggregation point , usually a DBMS, where key

data elements from SOR are integrated–Metadirectory - LDAP service that organizes registry

information and responds to service requests–Authenticator - service that authenticates (e.g. Kerberos,

LDAP, or other)–Groups - university roles built into directory–Services - application services that utilize IdM–Policy - definitions and structure, usually defines criteria

for group membership and service restrictions


Simplified UMBC ArchitectureSimplified UMBC Architecture

Public LDAP(Whitepages)

(SunOne DS5)

Oracle DB

LDAPDirectory

(iPlanet 4.1x)

AuthenticationService

(MIT K5)

MetadirectoryProcesses

(perl)SIS

(HP MPE)

HRSystem

User Input DirectoryManagmentApplications

Replica Replica

SISMirror

OutgoingConnectors

(perl)

To Consumers

Radius,WebAuth,PeopleSoft,etc.

UNIX Systems,Win2K Labs,AFS

Email Clients

Email Routing


Policy IssuesPolicy Issues

Policy issues that must be defined–Rules for membership in your community. Who is an

active student, who is a faculty member, who is an alumni?

–Who is eligible for an account? Under what circumstances?

–What groups do you need to track?–What services is each group allowed to access?–Who can sponsor affiliate members?–How long do you remain a member of the community?–What about guests or the public?


How do you define who is How do you define who is eligible for different services?eligible for different services?– Obvious: staff, faculty, students– Less obvious:

Alumni, supporters? Parents Sponsored or affiliate ID’s Transient e.g. meetings and conferences Former employees Research partners Affiliates: auxiliaries, credit union, teachers


Eligibility -- Thorny Issues Eligibility -- Thorny Issues

– Intermittent roles – persistent ID’s? Lecturers, seasonal employees students

– Multiple roles – change roles, keep ID’s? Student workers Staff students

– Multi-campus issues- common id across system?

– Does everyone need to be in your IdM?– How long does someone remain in your IdM?


Eligibility -- Create Policy FirstEligibility -- Create Policy First

Indiana Policy defines who can have and sponsor

accounts. Accounts Management System will

implement policy in software. UMBC Software was written without formalizing

the policy on paper. This is something we have to finalize.


Authentication and Authentication and AuthorizationAuthorization

Authentication - Who am I?– Shared secret -- password?– Secret key - PKI– Biometrics/other?

Authorization - What am I allowed to do or access? – Affinity groups are defined and populated. Roles

may be based on a combination of affinities. Identity Management system must answer both

questions.


Creating a single namespaceCreating a single namespace

Once you define who is eligible to be in your IdM you must create a person registry from multipe SORs.

For each person in the registry you must define an account name. Dealing with conflicts is a political challenge.

Get agreement on ground rules prior to starting the project. Provide flexibility. People care more about their email

address than they do their username! When creating new authentication service, require strong

passwords!


Indiana University Name Space Indiana University Name Space

Had to work across 8 campuses plus 4 major data centers

Ground work in 1988 with "username format summit"*Namespace consolidation project began "in earnest" in 1997

Required high-level leverage (University CIO) Consisted of iterative generation and review of

name lists of various naming organizations Person who had name first got to keep it Took 3 years to complete


Provisioning Credentials Provisioning Credentials

Identity Management usually necessitates automated distribution of credentials -- referred to as provisioning

Credentials are managed through an account management system

Faculty/staff/students initiate account process online. Account holders (faculty/staff) may be authorized to

sponsor affiliates. Affiliate accounts are linked to the sponsor.

UMBC is looking at having students sponsor parent accounts with delegated access to the students information


Variable Authentication Variable Authentication StrengthStrength

Consider providing alternative authentication methods and allow services to specify level of authentication and timeout period

We use two levels and we are looking at a third level { id : pin ; username:password }

We would like a third level that we use in addition to username:password

WebISO defines password level, timeout duration, attributes released, etc.


How do you handle How do you handle authorization to services?authorization to services?

Problem: our legacy services assumed that authentication implies authorization.

Remedy: Use IdM to define affiliations and control access by group membership

Strategy: Create 15-20 automatically maintained major affiliation types (example: faculty, staff, student, affiliate and several gradations of each) to define roles

Challenge: It isn’t easy to keep this maintained and not all services can use groups


Security and AvailabilitySecurity and Availability

An Identity Management (IdM) system is a the heart of defining access to the services you offerThe IdM is exposed to the Internet and must be hardened and protected as a critical IT resourceKey Issues:

–Failover–Capacity to meet peak loads–Capacity to meet critical service needs

Replication and distribution are key


Protecting Privacy and Protecting Privacy and ConfidentialityConfidentiality

Rapidly evolving area -- GLB,HIPAA, CA SB-1386, etc. Directory services allows services to be delegated more broadly

-- make sure staff that get access are trained in privacy regulations

Review logging procedures and log retention Limit who has direct access to the directory and who can update

the directory IdM can serve role as translator and lessen use of private data

such as SSN One consequence of directories is that it can facilitate spamming,

limit trolling


Revocation of Credentials?Revocation of Credentials?

Developed state diagram, accounts transition through these states. Time in each state is determined by UMBCperson affiliation

Requires ability to delegate authority on accounts to sponsoring entity. They can sponsor anyone but take responsibility for those they sponsor.

Runs nightly based on last effective date Highly political - everyone wants free access. Audit

requirements to promptly remove access is driver Worked with IT Steering Committee and faculty senate 18

months on account deletion plans.


Vendor StrategiesVendor Strategies

IBM, Sun, Microsoft, and Novell all have Identity Management systems in place. The following is a brief summary of what they have or our planning in the IdM space.

These were all taken from different web sites and are listed simply to give an idea of how each vendor looks at the issue.

The challenge is making this work in a heterogeneous system environment


Microsoft Microsoft




Sun One Identity ManagementSun One Identity Management


IBM Tivoli Identity ManagementIBM Tivoli Identity Management


Case StudiesCase Studies

What follows are two brief case studies of UMBC and Indiana University

UMBC is a single campus, 12000 students, with a centralized support structure

Indiana University is a 8-campus system, 100,000 students, with a more decentralized structure


Beginning an Identity Beginning an Identity Management ProjectManagement Project

Executive sponsorship is critical. Develop a business case for the project and treat it like any other development projectThe project will have tremendous implications inside IT on how you provide services, make certain you get everyone on board.The project requires access to data. Get agreements in place from data stewards before beginning project.Don’t scrimp on hardware, focus on 99.999 uptime


UMBCUMBC

Business driver was online account provisioning and delegated administration of password issues. WebISO was a spin-off benefit.Directory chosen for integration of services because of changing administrative systemsCIO was executive sponsorNamespace consolidations was not an issueStarted directory services project in January 2000. Delivered online account system in August 2000


UMBC Directory ArchitectureUMBC Directory Architecture

Public LDAP(Whitepages)

(SunOne DS5)

Oracle DB

LDAPDirectory

(iPlanet 4.1x)

AuthenticationService

(MIT K5)

MetadirectoryProcesses

(perl)SIS

(HP MPE)

HRSystem

User Input DirectoryManagmentApplications

Replica Replica

SISMirror

OutgoingConnectors

(perl)

To Consumers

Radius,WebAuth,PeopleSoft,etc.

UNIX Systems,Win2K Labs,AFS

Email Clients

Email Routing


LDAP-Based User FunctionsLDAP-Based User Functions


LDAP Administrative FunctionsLDAP Administrative Functions


Future PlansFuture Plans

Expanding person affinities and defining the group membership criteria

Implement Shibboleth with our Web-ISO Implement user-selectable privacy filters

for user controlled release of information Expand the API for using our WebISO


Indiana UniversityIndiana University

VP McRobbie was the executive sponsor Started in earnest in 1997 with namespace

consolidation project -- took 3 years to complete Directory project started in 2000, completed in

late 2001. Portal project launched in fall 2002. WebISO is

CAS from Yale PeopleSoft becoming SOR, now layering

services over the IdM


Authentication API University Addressbook

OnCourseActive

DirectorySteel Web PgsPplSft Insite

Shakes/Jewels

----------------- Applications and Services ------------------

Modems

Foundation

Other University AffiliationsContinuing

StudiesOthers

University People Information

Eclipse

Alumni

MY IU UIS Appl

Virtual Private Network (VPN)

ERAFIS

DemographicData

HR Data Others

Library Others

Personal A

ccount C

reation &

Ad

ministration (Self S

ervice)

Authorization APIInformation Extract

(LDAP)

Extract/Load Process Extract/Load Process GDS

EnterpriseDirectory/

InformationStore

PIN

TokenPassword

Authentication

SIDEMPID

ISN

MATHMajor

C201

UITS

IUK

IU.EDUE-mailNameSpace

GradesClerk

AcctManager

HRRep

Advisor

KerberosSafeword

AS Server

Core Services

Authorization& Roles DB

Other DirectoriesADS, Departmental

Accounts Staff

Local/ C

ampus Support

Providers

Accou

nt/In

formation

Mgt &

Main

t


CSU’s IdM Project: SIMICSU’s IdM Project: SIMI

California State University is 23 campuses, 400,000 students, 500,000+ people

SIMI: Secure Identity Management Infrastructure– Concept developed by campus CIO’s group with support from

Chancellor’s Office– After long consultation has now received support from

technology subcommittee of campus presidents– Goals:

Assure IdM developed appropriately for all 23 campuses Enable secure exchange of ID info across the system


QuestionsQuestions

Resources: http://wwws.sun.com/software/products/identity_srvr/wp-

idsrvr-overview.pdf http://www.novell.com/collateral/4621314/4621314.html http://www306.ibm.com/software/tivoli/solutions/security/id/ http://middleware.internet2.edu/ http://www.nmi-edit.org/

http://www.novell.com/collateral/4621314/4621314.html

http://www.nmi-edit.org/

http://www.nmi-edit.org/

Documents

NMI-EDIT Identity Management Tutorial NMI Tutorial February, 2004