Fall 2009 Day 1 - IdM Overview

Are there more Identity Management Issues we should be discussing in future sessions
IdM includes Access

Having a common identifier that everyone in the institution can use to identify a person
Establish identity, correlating identity and accessing identity for auditing purposes
Big problem in uPortal implementation is getting enough information into LDAP, supplement with Grouper
Do we or don't we want to duplicate data? Sometimes you have to, like with an ERP system.
Systems of Record are not necessarily authoritative over people, they are actually authoritative about attributes of people
Making sure data is replicated and managed is important

Access Management is a continuum:
- from an application that does all it's own access management, by asking for attributes and making the call
- to an application that doesn't make any of it's own decisions, goes out to an Access Management system and asks what this person can do
- there is plenty of room for all places within the continuum
challenge is squeezing the information out of the sources
strategies for getting the information out of the systems of record, easier if there is a central business process, like for Banner

the problematic pieces of information have no single system of record, the business decisions are made throughout the institution
problems occur when we don't know how to find out if someone can do something, or when we should take that permission away
by providing a common place to register this information, we can excite people to add to it
getting the right people to the right place in the processing flow
complexity comes from different groups making the same decisions in different ways, by capturing these access management needs in a common location
UBC is re-launching their AM solution from a business process perspective and asking what are the institutional use cases and learning about specific user life cycles and documenting it
Using the business practices to design the models
Sometimes there is no appropriate System of Record for things like Address information
What kinds of information are there to match users?

OpenRegistry is designed to plug in a black box called "Reconciliation Point"
Figure out key pieces of data like personal phone number, personal email address, DOB
Technology is beholden to the business process
Offload the work of matching to the user because most of the time it only matters to the user, not the system
But having the same person occupy multiple accounts can cause problems, like adding costs for duplicate licenses for the same person, and for tracking fundable positions
People want to make access decisions based on a person and that might not be the account the person uses
Fragmented identity can result in unforseen effects of changes
There is a problem of trying to remove access to people when their identity is fragmented
De-provisioning is a challenge that may have a solution in centralized access
Would like the ability to make decisions locally while enjoying the power of centralized access control
There are issues around an unknown commodity with regards to the client being able to handle privileges, and by definition, the application must handle privileging (Bedework is an example of an application that has had to handle privileges in a central way)
Loosely couple authZ solutions with the central application so that consumers with the ability to plug in their own solution can do so without alienating smaller consumers (Bedework already does this with authN)

Historically authentication = authorization but today we need business units to understand the difference and query for additional attributes
Libraries understand the need for authZ because of their license agreements with journal vendors
Universal Address books that is a generalized service accessible from Portal, email, calendar, etc.
There is a need to be able to grant authZ at various points in the workflow, across systems, like email, calendaring, etc.
Potential solution is for the various systems that own identity attributes to store them in a common back end