IDM-BPractices
Identity Management Best Practices Discussion
Intros and why are you here:
- Jason Shao (facilitator) Rutgers - just finished assessment
- Susan Bramhall (facilitator and notes) Yale
- Chuck Pearson Mississippi State - Campus Pipeline wrote them a doc, tapered off and are back at the beginning
- Thomas Freestone Brigham Young University - SOA orientation
- Aaron Hamid Cornell - integrating authentication to many systems
- Richard Spencer - UBC for student SIS
- [name and school?] - Luminis site - synch between AD and portal - creating uber LDAP
- Lee Assam Heartland Community College - academus next fall - include IdM - looking at Sun and Oracle
- Jens Haeusser  UBC - use CAS - bouht Sun IdM created Id providers - working on IdM for ?? federaion - architecting kuali student idm
- Jeffrey Kahn MIT - formerly to consume identities - now part of kerberos development team
- Christian Charette from Quebec - CAS flushed out social and technical issues
- a Quebec school - looking at uPortal - info related to that
- Parviz Dousti CMU - workewd for middleware - designed and implemented IdM with personas - now kuali
- Dan Ellentuck Cornell University - authentication and authorization - issues raised by provisioning a deprovisioning across disparate systems
- Bill Thompson Rutgers - trying to get their heads around it and understand it as a disciplin - asked to chart a path forward so started with assessment of where they are now (presented by Jason at previous sesion)
A common complaint:Â Users are tired of entering un/pw into 5 different "single sign on" systems
Richard Spencer
disparate oieces - not viewed as IdM until recently
IdM reflects the organization
people exist before they get an id at your inst and remain people after id may be gone
here are people wher we don't really care who they are - attending a conference for example
stop asking the question "who is a student"
Need to give credentials to people before they are afiliated. How to match later
Jens - series of questions used to correlate you to pre-existing attributes
Don't have one central place for attributes - have a virtual directory for web sso
must have distributed and delegated authority otherwise people give out credentials
how do you reconcile with future identity
UBC allows users to change username at any time - real identity is a number
why do we have to do authentication - in a decade people will arrive with credentials
a student could go through the entire college xperience under a false name - so what? Doesn't matter.
anyone can create "an account" but it doesn't get associated with any permission until the time it is linked.
There is way too much implisit authorization - access granted to everyone who can authenticate
Rutgers top 3 or 4 is the entanglement of authorization with authentication
Richad says create a new id with no access. One time they must login to both and make association. After that the system uses the new credential by linking to the new to the old
invalidate all the old permissions and force individual to reassociate
the individual determines what data should be not the institution
are attributes centrally stored?
Yes, Miss State, use LDAP updated daily
authorization based on the attribute
all applications use it - maitrix is maintained of access
ALberta allows any citizen to create an identity
a student creates an identity
student can then cause a transcript to be sent to a college
level 1 - a student could have someone else's transcript to go but can't see it
can go to MVD and get boosted to level 3 - someone has seen you and verified that you exist
now they can see your transcript also
forget the unified view
there are silos that have ownership of data but they don't own the people
let each silo own the data for which they are authoritative
use virtual directory concept and user drive associationsÂ
Is ID card tied in?
UBC requires a photo id to get a photo id
associate name photo and username
They are working with 12 different vendors to build architecture that will work with lightweight user controlled attributes. User confirms they have hr id and student it and can associate the two.
usernames and passwords or not worth anything - only if they are associated with a role.
CMU
personas - your id does not do anything - must get a persona to get access
personas are for provisioning and deprovisioning and are global
roles are used for access and are sytem by system
Spencer thinks we should map permissions to organization to allow delegation
role by role delegation
Sun allows this
concept of virtual organization in Sun as well
org based on attributes
can grant access to role based on attributes of virtual organizations
Topics we didn't get to...
authenticating services in addition to people