2. Today’s slides available at: www.duke.edu/~gettes/CAMP

4. Seminar 02 Introduction to Identity Management: The Big Picture Michael R. Gettes Duke University CAMP: Building a Distributed Access Management Infrastructure
Greetings
Panel focus is on the importance of creating policy and process in pursuit of an enterprise directory service. There’s information of interest for those already managing a directory service, as well as those just thinking about one.
Description of panel format:
Context – centralization focus in building an enterprise service
Headers on slides are broad areas that will require policy
Questions on slides are examples of likely issues, that will spur conversation, and are not all inclusive
Panelists will speak to some of these questions, audience is encouraged to ask other questions, add comments, challenge group

5. Observations on: Identity Management, Middleware & Security in U. S
Observations on: Identity Management, Middleware & Security in U.S. Higher Education
Michael R Gettes
Duke University

6. We recognize there exists a larger world...
A GLOBAL PROBLEM!
We recognize there exists a larger world...
9/18/2018

7. Identity Management?
#1 Issue in Higher Education /2006 EDUCAUSE IT Survey.
Less than 10 years old - some HE schools doing it much longer.
IdM is defined by many components as follows ...

9. IdM Components a.k.a. “middleware” (1)
Systems of Record (HR, SIS, Alumni, Telecom)
Information Switch (Vendor/build)
entity registry (Vendor/build)
identity business rule handling (Vendor/build)

10. IdM Components a.k.a. “middleware” (2)
Authentication (Password, PKI, Kerberos (ECAR Survey - K5 everywhere), ...)
Authority Mgmt (Signet, HR system, ...)
Group Mgmt (Vendor, Grouper, Build)
Directories - fast repositories (Vendor, Open Source)
EVERYONE should be implementing Kerberos!

11. IdM Components a.k.a. “middleware” (3)
Service Provisioning
Vendor, Built, Nexus
Message Mgmt - real-time and queuing
Vendor, Built or Jabber/XMPP

12. IdM Components a.k.a. “middleware” (4)
Attribute Delivery
PKI, SAML/Shibboleth, Directory, Vendor, (Various)
Authorization, Act of (by Application)
Policy Decision Point (PDP)
Policy Enforcement Point (PEP)

13. Age of this Technology Technology is young.
Lots of options - much more than just 5 years ago.
If you buy - you will still need to build your own Identity Business Rules. Buy *and* Build decision.
NSF/Internet2 Middleware - these “solutions” are simply options. If you believe in Open Source - they are good. If not, then use these solutions to drive vendors for what you want. Remain aware of trends.

14. Institutional Issues STAY OFF THE FRONT PAGE OF NATIONAL NEWS!!!
IdM is part of any “good” security program.
Each institution having IdM leads to better National Security - or at least the perception of it.
IdM leads to Access Control via Authority Management, Authorization and timeliness

15. Institutional Issues (2)
Nobody cares about implementing IdM. Need to define it in terms of Infrastructure to deliver a set of Services/Goals.
Duke - Goal is 1 hour to get ID Card and NetID services for new employee and 1 hour for status changes to take effect (job changes). Buy-in from VPs, EVP, Provost, etc...

16. Institutional Issues (3)
Consider rolling affiliates (non-student/fac- staff/alumni) into HR system - many contracts based on FTE (=paid person). You might get affiliate management for free.
How do ID Proofing processes (identity registration) need to change for students and staff to enhance Business services?

17. Institutional Issues (4)
How do we validate our processes? Is my institution doing a good job on IdM?
CAF - Credential Assessment Framework
How do we know if other institutions are doing a good job?
Federations! Like-minded organizations seeking like-minded services.

18. Institutional Identity
BRANDING of the institution via E-Identity
my.harvard, stanford.you, CNetID (chicago)
How easy is institutional initiation?
How easy to change function at institution?
Uniting the institution electronically - overcoming typical political boundaries

19. Levels of Assurance (LoA)?
Classify the requirements of an application
Assign confidence levels for the ID Proofing and Electronic Authentication Processes
Define mapping between Reqs and Confidence
As simple as a number (Levels 1,2,3,4).
Define confidence in terms of application requirements and you can use the same value for both.

20. Federation?
A collection of organizations, having implemented some form of Identity Management, where Credential Service Providers (CSP, Universities) and Service Providers (SP, Content Providers) agree to “rules of engagement” (policy and attributes) using federating software (SAML/Shibboleth, PKI, InfoCard ...)

21. Higher Ed Activity... InCommon - SAML based Federation
USHER - US Higher Education Root - PKI
HEBCA - Bridged PKI similar to USGov
Federal eAuth involvement (see Alterman)
Research community seeking Id Mgmt
NSF CyberInfrastructure
Shy away from Biometrics - What if you lose your E-thumb?
National ID vs. Federated ID - NOT RFID!

23. So, what is Identity Management, practically-speaking?

24. 9/18/2018

25. “IAM” is… “Hi! I’m Lisa.” (Identity)
“…and here’s my NetID / password to prove it.”
(Authentication)
“I want to do some E-Reserves reading.”
(Authorization : Allowing Lisa to use the services for which she’s authorized)
“And I want to change my grade in last semester’s Physics course.”
(Authorization : Preventing her from doing things she’s not supposed to do)
Jim
9/18/2018

26. What questions are common to these scenarios?
Are the people using these services who they claim to be?
Are they a member of our campus community?
Have they been given permission?
Is their privacy being protected?
Policy/process issues lurk nearby
Jim
9/18/2018

27. Vision of a better way to do IAM
IAM as a middleware layer at the service of any number of applications
Requires an expanded set of basic functions
Reflect
Join
Credential
Manage Affil/Groups
Manage Privileges
Provision
Relay
Authenticate
Authorize
Log
Jim
9/18/2018

28. Basic IAM functions Identity Mgmt System Reflect Join Credential
Systems of Record
Stdnt HR
Other
Identity Mgmt System
Registry
LDAP
Reflect
Join
Credential
Jim
9/18/2018

29. Role- and Privilege-based AuthZ
Privileges are what you can do
Roles are who you are, can be used for policy-based privileges
Both are viable, complementary for authorization
Jim
9/18/2018

30. Privilege Management Feature Summary
By authority of the Dean
grantor
principal investigators
role (group)
who have completed training
prerequisite
can approve purchases
function
in the School of Medicine
scope
for research projects
up to $100,000
limits
until January 1, 2006
condition
Jim
9/18/2018

31. Basic IAM functions mapped to the NMI / MACE components
Systems of Record
Identity Mgmt System
Reflect
Join
Credential
Mng.
Affil.
Priv.
AuthN
MACE contributions - this actually reflects the evolution time flow and data flow. Lifecycle issues. Jim
9/18/2018

32. The Environment AuthN Log Reflect Provision Join Credential AuthZ Pass
Systems of Record
Identity Mgmt System
Reflect
Join
Credential
Mng.
Affil.
AuthN
Provision
Apps / Resources
Log
AuthZ
Pass
Attributes
Priv.
Jim Always a dialog - policy and procedure
9/18/2018

33. How full IdM layer helps
Improves scalability: IdM process automation
Improves agility: Keeping up with demands
Reduces complexity of IT ecosystem
Complexity as friction (wasted resources)
Improved user experience
Functional specialization: App developer can concentrate on app-specific functionality
Jim
9/18/2018

34. The Environment AuthN AuthN Log Reflect Provision Join Credential
Apps / Resources
Identity Mgmt System
AuthN
Systems of Record
AuthN
Log
Reflect
Provision
Join
Credential
Michael
AuthZ
Pass
Attributes
Mng.
Affil.
Mng.
Priv.
Log
Grouper
Signet
Shibboleth
9/18/2018

35. Grouper Grouper project of Internet2 MACE
Infrastructure at University of Chicago
User interface at Bristol University in UK
$upport from NSF Middleware Initiative (NMI)
Michael
9/18/2018

36. Signet Project Signet of Internet2 MACE
Development based at Stanford
$upport from NSF Middleware Initiative
Michael
9/18/2018

37. IAM functions Reflect Data of interest Join Identity across SoR
Credential
NetID, other
Manage Affil/Groups
AuthZ info
Manage Privileges
More AuthZ info
Provision
Gen. AuthNZ info into app space
Relay
AuthZ info to app on request
Authenticate
Identity claim
Authorize
access decision (allow/deny)
Log
usage for audit, accounting,…
Jim
9/18/2018

38. Terminology
CSP - Credential Service Provider - A trusted entity issuing electronic credentials to subscribers (aka Identity Provider)
RA - Registration Authority - Vouches for the identity of a subscriber to a CSP
Identity Proofing - Process by which CSP and RA uniquely identify a person/entity
RP - Relying Party - an entity relying upon the credentials issued by a CSP (aka Service Provider)
LoA - Level of Assurance - Classification of ID proofing suitable for electronic use to control access to information M
9/18/2018

39. What is a Federation?
A collection of organizations, having implemented some form of Identity Management, where Credential Service Providers (CSP, Universities) and Service Providers (SP, Content Providers) agree to “rules of engagement” (policy and attributes) using federating software (Shibboleth, SAML, PKI) M
9/18/2018

40. What is a Federation? Continued
Sounds simple? It can be. It can be made really complex, really fast.
for more info
CSPs and SPs retain control over their environments (identity data and access ctrl)
Approx 37 participants (9/06), Launched 4/2005
Inqueue.internet2.edu
Testing/Playground for InCommon
>225 participants (9/06) and GOING AWAY! M
9/18/2018

41. Shibboleth and Federation
It’s real, uses SAML
Open source, freely available
Takes between 3 hours and 3 years to install -- depending on IdM infra
In production at various schools (Duke!)
For internal apps & external Univ vendors
shibboleth.internet2.edu M
9/18/2018

42. Inter-institutional integration
Virtual Organization (VOs)
GridShib development to enhance VOs working with Institutional Identity Mgmt Systems
Federations
Federal E-Authentication Initiative
League of Federations
The Interfederation Interoperability Working Group (IIWG). yes, it’s real M
9/18/2018

43. One key resource to help you start building the IdM infrastructure
Enterprise Directory Implementation Roadmap
directories.html
Parallel project planning paths:
Technology/Architecture
Policy/Management
Jim
9/18/2018

44. YOUR MILEAGE WILL VARY!
9/18/2018

45. The Environment AuthN AuthN Log Reflect Provision Join Credential
Apps / Resources
Identity Mgmt System
AuthN
Systems of Record
AuthN
Log
Reflect
Provision
Join
Credential
Jim
AuthZ
Pass
Attributes
Mng.
Affil.
Mng.
Priv.
Log
Grouper
Signet
Shibboleth
9/18/2018

46. 9/18/2018

47. JIm
9/18/2018

49. A Different View of IdM Biz Process?
Michael R Gettes
Duke University
Denver

50. Prioritization… @ Duke
Cough
ahem
Cough, Cough
Gag…
Next slide please …………
9/18/2018

51. The Problem (per Tom Barton @ U of Memphis)
Unclear process for lifecycle management of accounts & other IT resources
Seat of pants policy determination
Inconsistent operational practices
Done differently by different people at different times
Common business logic forced to reside in applications to determine eligibility
Eg. Is this user “currently a member of community”?
Inconsistent service levels for users results.
9/18/2018

52. Tom Barton’s Original U of Memphis States View of IdM …
Not shown: transitions to prospective state from grace, limbo, slide, IDonly.
9/18/2018

53. Adding to the Problem …
Gaining common understanding among Id Mgmt functional types
Communication between Id Mgmt Functional and Id Mgmt Technical types
How do Service Providers fit in?
Knitting together other Business Processes with IdM Biz Process (communication and understanding)
Hence, A Duke View…
9/18/2018

54. ACTIVE or EXISTS Identity & Service/Provisioning Condition
States (functional view)
Condition
ACTIVE or
EXISTS
Action
Creation
Result
Become
Student
Each flower is an identity state. An object can be in more than one state at any time. Each petal on the flower implies some form of provisioning -- adding/deleting attributes to inform services what to do -- send a message to a service to provision this object and so on. DISABLED allows for the disabling of services without modifying too much in the object. GRACE is for the de-provisioning of services as it may take some time to run through the GRACE period -- like removing an account may take 6 months of leaving the in place.
Become
Faculty
Remove
Student
Services
9/18/2018

55. Service/Provisioning States (functional view)
Condition
Identity &
Service/Provisioning
States (functional view)
Action
ACTIVE or
EXISTS
Creation
Result
Become
Student
Each flower is an identity state. An object can be in more than one state at any time. Each petal on the flower implies some form of provisioning -- adding/deleting attributes to inform services what to do -- send a message to a service to provision this object and so on. DISABLED allows for the disabling of services without modifying too much in the object. GRACE is for the de-provisioning of services as it may take some time to run through the GRACE period -- like removing an account may take 6 months of leaving the in place.
Become
Faculty
GRACE
DISABLED
Remove
Student
Services
Terminated
Staff
9/18/2018

56. For each ID Object … Condition Action Result Loop Over All Conditions
DENT TY OB J
ECT
Action
Result
Loop
Over All
Conditions
Until No
Actions
Stable State
The previous state diagram takes the Condition/Action/Results tuples and turns that into code -- the functional types can speak with the technical (implementers) speaking the same language. The Conditions operate on attributes in the identity object. If condition TRUE then perform ACTIONS and return RESULTS. Keep running thru all the conditions (loop) until no conditions are satisified and now the identity object is in a stable (and predictable) state.
For good biz logic
Order must not matter
9/18/2018

57. Testing and Validation Now Possible
ID Object #1
Old
ID Object #1
New
Identity
Management
Business
Logic
ID Object #2
Old
ID Object #2
New
ID Object #3
Old
ID Object #3
New
With all the previous -- you can now design testing/validation scenarios with input objects producing output objects expected. If you don’t get what you expect - there is a bug in the biz logic.
ID Object #4
Old
ID Object #4
New
9/18/2018

58. 9/18/2018

59. Borrowed from Mark S. Bruhn Indiana University
Policy Points…
Borrowed from
Mark S. Bruhn
Indiana University

60. Scope of “Identity Management”
Identification, authentication, authorization services
Directory services
Extract/load processes
Potential Out-feeds
Maintenance services (support and self-service)
Application interfaces
Logs
Inter-institution sharing
Other stuff…
9/18/2018

61. Business Goals of IdM Identity can be used to
Protect the interests and rights of the organization
Satisfy the obligations of the organization
Protect the interests of the individual
Security can exist without privacy; privacy cannot exist without security
9/18/2018

62. So, why are you doing IdM? Because you have to…
…implement a directory?
…identify users?
...authenticate users?
…authorize users?
…track users?
…track usage?
No…these are not reasons!
9/18/2018

63. IdM based on policies
Implementation of IdM must be as a reaction to organizational philosophies and attitudes (which should be represented by policies)
Or at least as a result of stated business and functional needs (which should be represented by requirements documents)
Nothing in IdM should be done without fully understanding the business requirements; it can get complicated, and sensitive information is involved – risks may not be worth exposing data and systems
9/18/2018

64. Why then?
Having said that…there are pressures that institutions SHOULD be feeling:
Obligations to revenue sources
Legal requirements
Ethical considerations
“Prudent stewardship”
Deter/prevent nefarious deeds
Support/security issues in maintaining disparate services
Systems interoperability
Depending on local decisions in response to these, and (hopefully) resulting policy statements, you will implement IdM and supporting infrastructure
9/18/2018

65. Security and Privacy: CIA
Essentially, these are basic security goals:
Confidentiality
Integrity
Availability
9/18/2018

66. Defining Confidentiality
Ensuring that data is not disclosed to unauthorized viewers
Protection against disclosure is required by
Law
Organizational policy
Prudent stewardship
9/18/2018

67. Confidentiality: Some Laws
4th Amendment
FERPA
HIPAA
GLBA
ECPA
Federal Wiretap Law
Open Records Laws
9/18/2018

68. 4th Amendment Applies to public/government entities
Prohibits unreasonable searches and seizures
Based on “reasonable expectation of privacy”
Organizational policy defines reasonable expectation of privacy
User accounts versus department folders; user accounts versus scratch space
Physical or logical IdM mechanisms may be deployed to facilitate 4th Amendment protections
9/18/2018

69. FERPA Limits disclosure of student educational records to
Individuals with “Legitimate Educational Interest”
Third parties with student’s prior written consent
Third parties in response to federal grand jury subpoena, and any other valid subpoena or judicial order
Appropriate persons where necessary to protect health and safety
Prior notice to student required except as otherwise expressly prohibited in law
Generally records of each request and disclosure of data must be kept
While there aren’t civil or criminal penalties for FERPA violations, they may result in loss of Federal monies
Clearly, IdM mechanisms are required to ensure compliance
9/18/2018

70. HIPAA
Governs use and disclosure of “protected health information” by “covered entities”
PHI is defined as “individually identifiable information regarding health care or payment (other than student health data) that is transmitted or maintained in electronic or other media”
Covered entities include: health plan/benefits, units who provide health care services and engage in electronic transactions involving PHI
9/18/2018

71. HIPAA (con’t) Privacy Rule: Effective April 1, 2003
Need to identify who within system handles PHI or may be “business associate” of third parties handling PHI
Need to draft accurate notice to patients about uses of PHI
Security Rule: Effective April 21, 2005
Requires rigorous access controls to limit internal and external access to health care data
Physical and electronic controls, oversight, education
Requires significant and ongoing communication and partnering among IT, legal, relevant personnel within affected units
As opposed to FERPA, there are civil and criminal penalties violations of HIPAA
Clearly, IdM mechanisms are required to ensure compliance
9/18/2018

72. Federal Wiretap Law
Generally prohibits intentional interception, use, or disclosure of wire and electronic communications
Allows senior DOJ officials to apply for court order authorizing capture of real-time wire, oral, or electronic communications relating to federal felonies
(There are some exceptions)
(Question: are we providing service “to the public”?)
Service providers can authorize law enforcement to intercept communications of trespassers on our “protected computers” (used in interstate commerce)
IdM will help us distinguish between authorized users and trespassers
9/18/2018

73. ECPA
Governs disclosure of stored voice and electronic communications and related user data
Need warrant for contents, need subpoenas for related user data: name, address, session logs, user ids, type/length of service, payment means
Service providers “to public” can disclose contents or user data:
with consent of one party
as necessary to render service
to protect rights/property
to law enforcement if inadvertently obtained and appears to pertain to crime
(Question: are we providing service “to the public”?)
If at some point the administration wants to pursue action against an individual related to protecting campus rights/property, individual users’ activities must be identifiable
9/18/2018

74. Open Records Laws
Generally requires disclosure upon request of records maintained by state agencies
There are often exemptions
mandatory (FERPA)
Security and other data that would jeopardize systems
Discretionary information (personnel files)
Applies to , other electronic records
In Indiana, the requestor does NOT have to indicate a reason, and there is no exception for information related to personal activities stored on University systems
Being able to distinguish between users will make it easier for an organization to respond to requests pertaining to only one individual’s activities
9/18/2018

75. Organizational Operations and Policies
Safety of individuals – bomb threats, harassment, expectation of privacy
Data classifications
Self-service applications
Course management
Fiscal policies
Academic code
Any institutional policy or procedure that assigned responsibility to an individual or group…
9/18/2018

76. Prudent Stewardship Gray area…
No real legal requirement for assigning and ensuring identity…but perhaps reasons related to
Business operation (Deans comparing funding notes…)
Ethical (accusing the wrong person…)
Personal privacy (fodder for stalkers…whois, finger)
Helping people do the right thing (customization based on category…limiting configuration capabilities)
9/18/2018

77. Prudent Stewardship (con’t)
We limit access to building plans.
We limit access to information that locates a person physically, in real-time.
We limit access to labor distribution information (non-salary compensation information)
We discourage people from making personal information publicly accessible
(We restricted access to normally-public information associated with the daughter of a highly-placed Indiana public official)
9/18/2018

78. Integrity
Ensuring that specific programs do what the programs are supposed to do
The old 10th-of-a-cent problem
Ensuring that data are accurate
E.g., medicines are developed based on research data: even if the data can be publicly DISCLOSED; even a suspicion of tampering must render the entire dataset useless and even dangerous
E.g., grades on transcripts have much to say about a student’s future
9/18/2018

79. Integrity (con’t)
Must ensure accountability is maintained for all change-level access (modify, insert, delete) to programs, systems and databases:
Functional office staff
System administrators
Database administrators
Applications developers
9/18/2018

80. Integrity (con’t)
Must implement separation of duties in order to reduce opportunities for fraud/complicity
Functional office staff (esp. money handlers)
System administrators
Database administrators
Applications developers
Maintaining accountability and separation of function isn’t possible without Identity Mgt.
9/18/2018