Some IDM Lessons Learned

1
Some IDM Lessons Learned
Chris Phillips chris.phillips_at_queensu.ca, Fall
Internet2 - Dec 5th , 2006
2
About Queens University

• Full-time enrolment 20,720 (2005)
• Academic Staff 2,355 (tenure and tenure track
  included)
• Other Staff 2,498 (including medical support
  staff)
• ITS 100ppl, of which 25 work on software and
  integration projects.

3
The (R)evolution of our IDM

• Spending more time on maintenance rather than
  delivering new services
• Not able to keep up with policy changes to meet
  client needs
• Difficult to staff for support and development
• Evolution of NetID functionality is crucial to
  other projects so it was evaluated at the same
  time as they were (portal/cms).
• RFI for ID mgmt itself was put together and a
  number of vendors were reviewed and Sun was
  selected. (https//qshare.queensu.ca/xythoswfs/we
  bui/_xy-137034_1-t_1XxMZ7lZ )

4
Why Change IDM Strategy?
No self serve interface for end users!
Cant distribute admin tools easily
Cant do delegated administration
Data accuracy issues.(People sometimes have
duplicates).
Cant do externally created sponsored accounts
Sync is nightly, need realtime or near realtime
Accounts are deleted and removals not always
replicated out. Audit trail is incomplete
Enabling new data is custom work which is
tedious and time consuming. Many opportunities
to break in many places
Bussiness logic and workflow are sprinkled
over many places and need to be refactored to
simplify and to centralize tasks/objects.
No challenge questions for passwd reset
Certain changes dont take effect automatically
(uid changes)
5
New and Improved IDM Model
6
Why Sun IDM?

• The model is remarkably comfortably familiar
• Flexibility throughout -- system is xml driven.
• Many out of the box capabilities. (password
  reset, challenge questions, web interface for
  delegated administration, )
• Workflow engine and supporting GUI editing tools
  built in
• Robust identity reconciliation engine (rules,
  pre/post events)
• Connects to various resources out of the
  box.(LDAP,AD, SQL, plus custom connectors)
• Architecture and implementation design patterns
  make sense. (e.g. self sign up processes can be
  implemented within the system without too many
  contortions)

7
Why Sun IDM?

• Bundled in with Java Enterprise System
  (portal/mail/calendar/SSO) that we are licensed
  for.
• We have a vendor to call upon and a support
  contract already with JES.
• We are a big Solaris shop and have a good
  relationship with the vendor.
• Training was available and proved invaluable (go
  to it first, THEN (re)architect plan the
  deployment!)

8
Things that could be better.

• The product is very broad AND deep. The
  documentation covers the breadth, but not so much
  the depth.
• There are many buttons and dials to push, but
  what is the best and most scalable/effective way
  to do it? Hard to tell without help.
• Needs more solution guides and recommended
  patterns/blueprints for implementation.
• We are trying to address this ourselves (more
  later).
• Change control on the product could be better.
• A single change on a workflow could impact things
  dramatically.
• Flying without a net if you dont provide your
  own.
• Dealing with non person objects are not as neat
  and clean as dealing with people objects.
• Course enrollments, are they groups? Are they
  attributes to a person record? Are they both?
  What do you do if they are?
• do you get it or not? question easy to answer
  for (de)provisioning. However, things that
  twiddle attributes of a person not so easy. (e.g.
  LDAP and edupersonEntitlement changes for
  instance)

9
Some Intriguing Thoughts

• Boy, doesnt Sun IDM look like Nexus or
  vice-versa?(https//meta.memphis.edu/display/Nexu
  s/Main)
• Hey, doesnt Signet do all this
  stuff?(https//wiki.internet2.edu/confluence/disp
  lay/SignetWG/SignetProduct )
• Chris, why not use Grouper to deal with self
  managed groups and all those course enrollment
  based groups?(http//middleware.internet2.edu/dir
  /groups/grouper/ )

10
Identity Stack Comparison
Internet2
Sun
Nexussignetgroupera useful workflow
toolgluework betwixt the aboveyour business
logicglue work to your endpoints
Sun IDM your business logic customizations to
aboveglue work to your endpoints
Identity Management Tier
Identity Consumption Tier
Sun Fed. Manager AccessMgr./OpenSSOORSun
AccessMgr Shib 1.3
MAMS Shib 2.0 orShib 1.3 your SSO
How do you choose? This is a whole topic unto
itself best answered by you.A popular approach
is to engage prof. services once a winning
technology is chosen. Parting thoughts to
consider pre-existing tech. base, team caliber,
technology strengths, size, funding, mgmt buy in,
long/short term goals, andand...
11
The Collaboration Pitch

• This is the same pitch as Shib for Fed. Id. Or
  JSR-168 for portal content. Build in a standard
  way so you can interoperate (but leave the door
  open for extending the work)
• Why do the IDM work twice?
• If our institutions are gravitating to common
  platform(s) then it is plausible that we can
  share/trade/co-develop components for certain
  workflows or provisioning processes.
• Examples
• Provision/deprovision a WebCT/blackboard user.
• Provision/deprovision a portal user.
• Provision/deprovision a TSM (backup system) user.
• Provision/deprovision a library only user.
• Custom workflow for granting and revoking roles
  automatically based on attributes
• What else?
• In particular, if you are running JES or Sun IDM,
  find me and lets talk

12
Thank you for your time!

• chris.phillips_at_queensu.ca
• Questions, comments, and inquiries welcome!

Project Website http//wiki.its.queensu.ca/displa
y/IDM/Home Useful references NMI-EDIT IDM
readiness checklist http//www.nmi-edit.org/pdf/m
w-idm-readiness-v.3.pdf Our RFI for an IDM
solution https//qshare.queensu.ca/xythoswfs/webu
i/_xy-137034_1-t_1XxMZ7lZ Nexus
https//meta.memphis.edu/display/Nexus/MainSignet
https//wiki.internet2.edu/confluence/display/Sig
netWG/SignetProduct Grouper http//middleware.i
nternet2.edu/dir/groups/grouper/