1. The UW-Madison IAM Experience Building our Dream Home Presented by Steve Devoti, Senior IT Architect © 2007 Board of Regents of the University of Wisconsin System

2. The UW-Madison needs to remodel and expand its IAM services © 2007 Board of Regents of the University of Wisconsin System

3. You probably look a lot like us © 2007 Board of Regents of the University of Wisconsin System

4. We are clearly not meeting the needs of campus, we lack a blueprint © 2007 Board of Regents of the University of Wisconsin System

5. Analysis and an organized approach can get this thing built © 2007 Board of Regents of the University of Wisconsin System

6. Form a project, assign resources and recommend a direction © 2007 Board of Regents of the University of Wisconsin System

7. We had been working on a small space for over 4 years © 2007 Board of Regents of the University of Wisconsin System

8. We decided to build it our selves © 2007 Board of Regents of the University of Wisconsin System

9. There were no vendors that could meet our needs © 2007 Board of Regents of the University of Wisconsin System

10. We love to build things © 2007 Board of Regents of the University of Wisconsin System

11. Who knows? All the original decision-makers are gone! © 2007 Board of Regents of the University of Wisconsin System

12. Overly complex design © 2007 Board of Regents of the University of Wisconsin System

13. Never really structured as a project © 2007 Board of Regents of the University of Wisconsin System

14. Customers are getting grumpy © 2007 Board of Regents of the University of Wisconsin System

15. For 4 years, customers have been told that PASE will solve everything © 2007 Board of Regents of the University of Wisconsin System

16. The executive sponsor decided it was time for some changes © 2007 Board of Regents of the University of Wisconsin System

17. A new enterprise architect was assigned © 2007 Board of Regents of the University of Wisconsin System

18. A “real” project manager was assigned © 2007 Board of Regents of the University of Wisconsin System

19. The team reexamined the requirements and the decision to build VS © 2007 Board of Regents of the University of Wisconsin System

20. We formalized our requirements and did a high level evaluation of the options Functional /Non Functional IAM Category Scope Requirement Compliance Module or Feature Effort F AuthorizeSystem Shall provide the ability to define combinations of create, retrieve (read), update (modify) and delete permissions to created appropriate system roles (e.g. "Affiliation Manager") None Authorization Manager Difficult F AuthorizeSystem The system shall support integration with the institutional and/or standards-based authentication mechanisms (e.g. pubcookie, Shibboleth, SAML). None Authentication Manager Moderate F AuthorizeSystem The system shall support an "auditor" role which allows a subject to read and create reports from system logs, but allows no other system access. None Authorization Manager/UI Moderate F LogSystem Shall support logging of, and reporting on governance activities. Partial Log/Audit facility Easy See: WIBuyVSBuild.xls Build vs. Open Source vs. Buy © 2007 Board of Regents of the University of Wisconsin System

21. We also completed a high-level pros and cons analysis Acquire Total Solution (Commercial Vendor) Pros: –Consulting resources. Consulting resources are readily available to assist in commercial vendor implementations. –Provisioning. Commercial vendor identity management suites include advanced provisioning functionality. –Workflow. Commercial vendor identity management suites include workflow. –Functionality. In addition to provisioning, many vendor suites include other advanced identity management functionality that might be useful to the organization (web access control, federation services, virtual directory or meta-directory, etc.). Acquire Total Solution (Commercial Vendor) Cons: –Cost. Is more expensive than some other solutions. –Lack of higher education community. Though there is high adoption of commercial identity management software in private industry, there is much less adoption in higher education, particularly at large institutions See: WIProsAndCons.xls © 2007 Board of Regents of the University of Wisconsin System

22. We decided that the Grouper/Signet solution best met our needs © 2007 Board of Regents of the University of Wisconsin System

23. We went to some camps, and installed a POC system © 2007 Board of Regents of the University of Wisconsin System

24. The natives were getting even more restless © 2007 Board of Regents of the University of Wisconsin System

25. Priorities have changed © 2007 Board of Regents of the University of Wisconsin System

26. Our customers wanted us to address provisioning first © 2007 Board of Regents of the University of Wisconsin System

27. That was going to take a lot of building or maybe purchase of another product © 2007 Board of Regents of the University of Wisconsin System

28. The only reasonable thing to do was look at vender solutions © 2007 Board of Regents of the University of Wisconsin System

29. We did proof-of-concepts with Oracle and Sun © 2007 Board of Regents of the University of Wisconsin System

30. Our sponsor was exploring ways to pay for the solution © 2007 Board of Regents of the University of Wisconsin System

31. Through hard work and masterful persuasion funding was secured © 2007 Board of Regents of the University of Wisconsin System

32. We began an RFP, dividing the work into 3 high-level capabilities Directory Services Identity Management Integration Access Management History SupportCost © 2007 Board of Regents of the University of Wisconsin System

33. Each capability section was built with standard bricks See: WIRFPSpecs.doc © 2007 Board of Regents of the University of Wisconsin System

34. Capabilities, functions and “other considerations” were weighted © 2007 Board of Regents of the University of Wisconsin System

35. We ended up with something like this: 3Web Access Management CapabilityRating GuidancePoints Total Points= 3,400 We define Web Access Management Capability as a central policy and enforcement infrastructure capable of protecting heterogeneous web resources for the purpose of providing users with single sign-on. Note, in the context of this RFP, Web Access Management includes federation functionality and the protection of SOAP-based web services. 3.1. Architecture: Describe at a high level the elements and technologies that make up this capability and their relation to each other. Provide diagrams. What are the advantages of this architecture? Specify any disadvantages or limitations of this architecture. If your solution supports multiple high-level configurations, describe the advantages and disadvantages of each. Describe the logical architecture of the servers that make up your solution. SHOULD follow good application architecture practices with an architecture that is compatible with the University of Wisconsin's Common Systems technology infrastructure. 544 3.1.1. Policy Administration Points (PAPs): Describe how the PAP(s) are deployed. Do you provide a single PAP or must policies be individually managed on each Policy Decision Point (PDP)? SHOULD provide a single point of policy management 72 See: WIRFPSpecs.xls © 2007 Board of Regents of the University of Wisconsin System

36. We developed an evaluation methodology EvaluationDefinitionScore No Support No support according to the ratings guidance. No documentation. Extension to meet requirement is difficult, extremely expensive, or not possible to extend. 0 Partial Support Partially supported, with some aspects missing according to the ratings guidance or the answer doesn't follow expected format. Lacking clear or specific documentation. Unreasonable, or somewhat expensive to extend. 1 Strong Support Mostly supported, with a couple aspects missing according to the ratings guidance. Somewhat well documented in the vendor response with reference to technical documentation. Provides functionality out-of-the-box or easy to extend to provide functionality. 3 Full Support Completely supported according to the rating guidance. Fully or somewhat documented in the vendor response with reference to technical documentation. Requirement requires standard expertise to implement, perform, or meet. 9 © 2007 Board of Regents of the University of Wisconsin System

37. We sent it out, received the responses and scored them © 2007 Board of Regents of the University of Wisconsin System

38. And the winner is….. © 2007 Board of Regents of the University of Wisconsin System

39. Where do we go from here? FunctionCapability Capabilities GapsPrinciples Policy, Standards, Guidelines Stakeholders, Sponsors Identify Needed CapabilitiesIdentify FunctionsCompare to Current CapabilitiesIdentify GapsPrioritizeRecommend ProjectsDevelop PrinciplesRecommend Policy Projects Policy Working Groups © 2007 Board of Regents of the University of Wisconsin System

40. Questions? © 2007 Board of Regents of the University of Wisconsin System