Download presentation
Presentation is loading. Please wait.
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
The UW Madison has been doing IAM for a number of years with a mix of Open Source and custom development. Inflexible Meets current needs but does not provide the foundation and options for expansion that will allow for new services © 2007 Board of Regents of the University of Wisconsin System
3
You probably look a lot like us
Back track a minute. Your probably here because you have something in common with us One of the larger institutions in the US. If we can solve our problems, you probably can solve yours. One of the largest research institutions in the US. 42,000 students 16,000 faculty and staff More collaborative research Being asked to provide more services to groups not traditionally associated with the university © 2007 Board of Regents of the University of Wisconsin System
4
We are clearly not meeting the needs of campus, we lack a blueprint
Though we got out to good start, we let things get a way from us. We were really doing most of this off the cuff. We lacked a plan. © 2007 Board of Regents of the University of Wisconsin System
5
Analysis and an organized approach can get this thing built
So why should you listen to us? Well, we’ve retrenched, we’ve developed a plan and have high confidence we’re going deliver for our campus. © 2007 Board of Regents of the University of Wisconsin System
6
Form a project, assign resources and recommend a direction
Where did we go wrong and why do we thing we’re back on the right track? Mostly not about IAM or IAM expertise, but about project management and planning. Not professional project managers, poor communication and documentation of goals and objectives. So… out with Larry, Moe and Curly and in with a structured approach. We formalized the process, it’s really now a project and assigned dedicated resources. © 2007 Board of Regents of the University of Wisconsin System
7
We had been working on a small space for over 4 years
Lesson learned. This is taking too long. Lack of defined goals and objectives. The IT world changes a lot in 4 years.. © 2007 Board of Regents of the University of Wisconsin System
8
We decided to build it our selves
Working under old assumptions we decided and continued to think we could build this thing. © 2007 Board of Regents of the University of Wisconsin System
9
There were no vendors that could meet our needs
Lesson, thoroughly investigate your options. If a lot of time goes by, reevaluate. © 2007 Board of Regents of the University of Wisconsin System
10
© 2007 Board of Regents of the University of Wisconsin System
We love to build things Don’t let what you like to do get in the way of what you should do. We all have biases. At some point you have to decide whether you want to deliver or you want to play. © 2007 Board of Regents of the University of Wisconsin System
11
Who knows? All the original decision-makers are gone!
It’s tough to track what actually happened as everyone it gone. Old decisions carry over. Poor documentation. © 2007 Board of Regents of the University of Wisconsin System
12
© 2007 Board of Regents of the University of Wisconsin System
Overly complex design Nothing wrong with building it, but keep it simple at first. Deliver incremental value so you can keep people engaged. © 2007 Board of Regents of the University of Wisconsin System
13
Never really structured as a project
The bottom line “a project” Identify stakeholders Communicate Have goals and objectives. This can’t just happen! © 2007 Board of Regents of the University of Wisconsin System
14
Customers are getting grumpy
How did we get off our dysfunctional path? It’s the customers stupid. This isn’t about IT. Customers are demanding that progress be made in this area. © 2007 Board of Regents of the University of Wisconsin System
15
For 4 years, customers have been told that PASE will solve everything
Back to communication. You must deliver or if not, communicate why. © 2007 Board of Regents of the University of Wisconsin System
16
The executive sponsor decided it was time for some changes
Deliver something! It was time for a change (recognize and take advantage). New executive and new staff. © 2007 Board of Regents of the University of Wisconsin System
17
A new enterprise architect was assigned
Fresh view. Someone who’s actually seen this thing work. Able to counter the excuses of the incumbents. © 2007 Board of Regents of the University of Wisconsin System
18
A “real” project manager was assigned
Cannot stress enough the value of a real project manager. This is not a sideline for a techie! © 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
Requirement F Scope Build vs. Open Source vs. Buy
We formalized our requirements and did a high level evaluation of the options Build vs. Open Source vs. Buy Functional/Non Functional IAM Category Scope Requirement Compliance Module or Feature Effort F Authorize System 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 The system shall support integration with the institutional and/or standards-based authentication mechanisms (e.g. pubcookie, Shibboleth, SAML). Authentication Manager Moderate 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. Authorization Manager/UI Log Shall support logging of, and reporting on governance activities. Partial Log/Audit facility Easy General direction. Start at a high level. Analysis. Start to gather data that can help you decide on a direction. See: WIBuyVSBuild.xls © 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
Fit very well with our culture. It would be exciting to be part of something like this. © 2007 Board of Regents of the University of Wisconsin System
23
We went to some camps, and installed a POC system
Investigate. This is a big decision. © 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
University Directory Service © 2007 Board of Regents of the University of Wisconsin System
27
© 2007 Board of Regents of the University of Wisconsin System
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
Investigate. Don’t over promise. Be relatively certain of what you can deliver. © 2007 Board of Regents of the University of Wisconsin System
30
Our sponsor was exploring ways to pay for the solution
Funding is a problem and will influence how you do this. But… you have to do it. © 2007 Board of Regents of the University of Wisconsin System
31
Through hard work and masterful persuasion funding was secured
Thanks! Look outside you borders. Who can you partner with. We all have the same problem! © 2007 Board of Regents of the University of Wisconsin System
32
We began an RFP, dividing the work into 3 high-level capabilities
Identity Management Directory Services Integration History Support Access Management Scope. We had been applying scope to the wrong level. Needs to be applied to what we actually do, not what we acquire. Cost © 2007 Board of Regents of the University of Wisconsin System
33
Each capability section was built with standard bricks
Integration IdM Dir Services WAM See: WIRFPSpecs.doc © 2007 Board of Regents of the University of Wisconsin System
34
Capabilities, functions and “other considerations” were weighted
Cost IdM WAM Dir Services Integration Support History Because we used bricks, this was a lot easier. © 2007 Board of Regents of the University of Wisconsin System
35
We ended up with something like this:
3 Web Access Management Capability Rating Guidance Points 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
Definition Score 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
© 2007 Board of Regents of the University of Wisconsin System
And the winner is….. © 2007 Board of Regents of the University of Wisconsin System
39
Where do we go from here? Metadata worksheets for disk
Identify Needed Capabilities Identify Functions Compare to Current Capabilities Identify Gaps Prioritize Recommend Projects Develop Principles Recommend Policy Where do we go from here? Capabilities Gaps Principles Policy, Standards, Guidelines Stakeholders, Sponsors Function Capability Metadata worksheets for disk Policy Working Groups Projects © 2007 Board of Regents of the University of Wisconsin System
40
© 2007 Board of Regents of the University of Wisconsin System
Questions? Steve Devoti – Senior IT Architect University of Wisconsin-Madison © 2007 Board of Regents of the University of Wisconsin System
Similar presentations
