08-5878 (Amendment

A REQUEST FOR PROPOSAL (RFP)

RFP #08-5878

UNIVERSITY OF WISCONSIN – Madison

Identity and Access Management Software

Issued by:STATE OF WISCONSIN

UNIVERSITY OF WISCONSIN - MADISONPURCHASING SERVICES

Amendment #1 - August 17, 2007

NO PUBLIC OPENING

Proposals must be submitted by

September 6, 2007 - No later than 2:00 p.m. CDT

PURCHASING SERVICESUniversity of Wisconsin-Madison 21 N Park St, Suite 6101 Madison, WI 53715-1218608/262-6121 (Fax) 608/262-4467 www.bussvc.wisc.edu [email protected]

AGENT: Vera Laufenberg at (608) 262-3198 / FAX: (608) 262-4467 / TTY 608/262-0825

E MAIL: [email protected]

If NO BID (check here) and return.

NOTE TO PROPOSERS: Amendment #1 issued to: (1) replace Table of Contents – added ATTACHMENT I (Page 64-67); (2) Page 4 (Section 2.1- changed due date); (3) Page 36 (section 6.3.1.4 – removed word “external”); (4) Pages 45 and 46 replaced in their entirety; (5) added Attachment I (Pages 64-67), (6) provide questions and answers received from Proposers; and (7) The DUE DATE has been EXTENDED to 09/06/07 @ 2:00 PM CDT.

mailto:[email protected]

AMENDMENT #1

SUBMITTAL INSTRUCTIONS

A completed and signed proposal response must be received and date/time stamped in by UW-Madison Purchasing Services prior to 2:00 p.m. CDT on the stated proposal due date to be considered. Proposals not so date/time stamped in shall be considered late. Late proposals shall be rejected. We have supplied you with a pre-addressed return label. Please fill in your vendor name and address on the return label to help us identify this transaction. Please use one of the options below for return of your proposal.

MAILING:Original and seven (7) copies of mailed proposals must be received at Purchasing Services, 21 N. Park Street, Suite 6101, Madison, WI 53715-1218, prior to 2:00 p.m. CDT on the stated proposal due date. HAND DELIVERY:Original and seven (7) copies of hand-delivered proposals may be delivered by vendor or third-party/courier service. Proposals must be received at Purchasing Services, 21 N. Park Street, Suite 6101, Madison, WI 53715-1218, prior to 2:00 p.m. CDT on the stated proposal due date.

E-MAILING: For your e-mailed proposal to be considered valid by UW-Madison Purchasing Services:1. Send a complete copy of the entire response prior to 2:00 p.m. CDT on the stated proposal due date via e-mail to: [email protected]. Submitting a proposal to any other e-mail address than [email protected] does not constitute receipt of a valid proposal by Purchasing Services.

2. Original and seven (7) copies to be delivered (via hand delivery, mail or courier) within one (1) business day after the stated proposal due date must be received at Purchasing Services, 21 N. Park Street, Suite 6101, Madison, WI 53715-1218.

Prior to the proposal deadline, proposer is responsible for confirming that their e-mailed proposal response has been successfully received. Proof of transmission doesn't constitute proof of receipt. The original e-mail submission must be supported by the last page of Section 6 “RFP Checklist and Submittal Page”. This page must be signed and returned via fax (608-262-4467) and must be received prior to 2:00 p.m. CDT on the proposal stated due date.

RETURN ADDRESS LABEL:

OFFICIAL SEALED PROPOSALNUMBER: 08-5878DUE DATE: 09/06/07 TIME: 2:00 PM CDT NO PUBLIC OPENINGINSERTVENDOR NAME HERE: ______________________________________ADDRESS: ________________________________________________ ________________________________________________ ________________________________________________

UNIVERSITY OF WISCONSIN-MADISONPURCHASING SERVICES21 N PARK ST, SUITE 6101 MADISON, WI 53715-1218



UNIVERSITY OF WISCONSIN AMENDMENT #1 PROPOSAL NO.: 08-5878

PAGE(S)

Attachment A – Specifications (19-44)Attachment B – Cost Proposal Form (45-47)Attachment C – Client Reference List (48)Attachment D – Supplier Diversity, Minority Business Enterprise (MBE) Program Commitment (49)Attachment E – Standard Terms and Conditions (50-53)Attachment F – Software Rider (54-59)Attachment G – Personal Services Rider (60-62)Attachment H – Designation of Confidential and Proprietary Information (DOA-3027) (63)Attachment I – UW Madison Enterprise IT Infrastructure: Current State (64-67)

UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 4 OF 63

Section #2: RFP Process Instructions

2.1 Applicable Dates

DATE

August 3, 2007

August 13, 2007

September 6, 2007 -- 2:00 PM CDT

EVENT

Date of Issue of the RFP

Written questions due

RFP Due Date (Local Madison Time)

2.2 Clarifications and/or Revisions through Designated ContactAll communications and/or questions in regard to this request should be in writing and proposers are encouraged to FAX or e-mail written questions to the Purchasing Office. Verbal questions, when permitted, must be directed to Vera Laufenberg at (608) 262-3198.

If a Proposer discovers any significant ambiguity, error, conflict, discrepancy, omission, or other deficiency in this RFP, they have five (5) business days prior to the RFP due date to notify, in writing, Vera Laufenberg at the address shown below of such error and request modification or clarification of the RFP document. All written questions will be responded to in writing and provided to all proposers.

Vera LaufenbergUW Purchasing

21 N Park St, Suite 6101Madison, WI 53715-1218

E-mail: [email protected] PHONE 608/262-3198 -- FAX 608/262-4467 – TTY 608/262-0825

If a Proposer fails to notify the Purchasing Office of an error in the RFP document which is known to the Proposer, or which must have reasonably been known to the Proposer, then the Proposer shall submit a response at the Proposer’s risk and if awarded a contract, shall not be entitled to additional compensation or time by reason of the error or its later correction.

In the event that it becomes necessary to provide additional clarifying data or information, or to revise any part of this RFP, supplements or revisions will be provided to all recipients of this initial RFP.

2.3 Preparing the ProposalTo be considered, Proposers must respond to each of the requirements listed in Section #4 and per the attached Submittal Instructions. Responses should be formatted to correspond numerically to the requirements listed in Section #4.

2.4 Conflict of InterestBy submitting a proposal, the proposer certifies that no relationship exists between the proposer and the University that interferes with fair competition or is a conflict of interest, and no relationship exists between such proposer and another person or firm that constitutes a conflict of interest that is adverse to the University.


6.3 Consulting Services: There are two components to this portion of the RFP. The first is the Detailed Implementation Road Map, described below. The second component is a general price list for additional consulting resources that the University may need during the term of the contract 6.3.1 Initial Engagement-Detailed Implementation Road Map (for Madison Campus):

The University Wisconsin-Madison will require a phased implementation of any IAM suite purchased, integrating the deployed capability in each phase with our existing infrastructure and any previously deployed capability. The initial engagement between your consulting services and the University Wisconsin-Madison will therefore be a detailed road map for the succeeding phases. The exact nature of those phases is to be considered negotiable until the road map is complete, but what follows is the University Wisconsin-Madison’s current understanding of the work required to deploy an IAM suite. Provide a detailed Statement of Work for a project that would cover this effort. On your Price Sheet, also give the estimated cost for this project. 6.3.1.1 Implementation Road Map

Policy analysis with multiple University-represented sponsors, constituents, and IT personnel.

Vendor garnering a complete understanding of the existing University identity management components, directories, and manual provisioning processes.

The map itself, with defined phases and milestones within phases. Provide diagrams describing the migration from existing to new or the integration of existing

with new. Describe the general time frames associated with each phase. Describe the primary team roles involved in each phase. Describe the testing plan for measuring the success of each phase. Describe the training or expertise required to complete each phase successfully.

6.3.1.2 Phase I - Replacement of Custom Identity and Affiliation Manager (UW Madison Special Authorization for Photo ID System) Policy analysis. Large data migration of identities, roles and attributes in production. Creation of production and pre-production systems for new solution, possibly while

maintaining a parallel solution using existing infrastructure to minimize source provider disruption.

6.3.1.3 Phase II - Replacement of Custom Linking Between Authoritative Source Systems Policy analysis. Multiple source system data transformations. Moving sensitive data and accompanying security issues. Process for reconciling multiple source data records into a single identity. Process for unlinking improperly linked identities, such as when bad data is submitted from

source system. Process for communicating new identities or changes to identities to downstream systems. Creating pre-production and production systems that communicate with authoritative

sources. 6.3.1.4 Phase III - Replacement of Manual or Custom Provisioning to Key Systems

Policy analysis. Business process analysis with possible consulting service to assist with process change. Moving sensitive data and accompanying security issues. Creating pre-production and production systems that provision to external University

systems.6.3.1.5 Documentation and Training

Describe the business, technical, and end user documentation provided.

UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 45 OF 63ATTACHMENT B – COST PROPOSAL FORM

Option 1: UW System Enterprise License 1st year 2nd year 3rd year 4th year 5th year

Unlimited instances Maintenance Maintenance Maintenance Maintenance Maintenance

Software Net Price Net Price Net Price Net Price Net Price

Head count information is for reference only Net

Total of Faculty, Staff and Students for all Campuses instance Price Software

Please note: Fac/Staff data first/Student data second

University of Wisconsin System-Enterprise Licenses

Total head count is: 193,372 (28,497: 164,875)

Source: UW System 2006 Fact BookServices Net Price

UW-Madison Detailed Implementation Roadmap

as described in Attachment A

Technical Specifications- Section 6.3.1

Provide detailed Statement of Work and price for the project

Price must include all travel expenses for contractor

Consulting Positions

Project Manager (hourly rate including expenses)

Solutions Architect (hourly rate including expenses)

Programmer Analyst (hourly rate including expenses)

System Analyst (hourly rate including expenses)

Business Analyst (hourly rate including expenses)

Other Relevant Positions as proposed by contractor

List position and hourly rate including expenses

Additional Price List for Misc. Items rate Training - administrative - rate per day contractor site

Training - administrative - rate per day customer site

Other resources that may be required - please identify in detail


Option 2: UW System Campuses Purchase Instances Individually 1st year 2nd year 3rd year 4th year 5th year

Maintenance Maintenance Maintenance Maintenance Maintenance

Software Net Price Net Price Net Price Net Price Net Price

Head count information is for reference only Net

Total of Faculty, Staff and Students for each Campuses instance Price

Software

Please note: Fac/Staff data first/Student data second

University of Wisconsin- Madison - includes Madison plus other Campuses for Shared Resources - 193,372 (28,497: 164,875)

UW- Eau Claire - 11,588 (1,082:10,506)

UW-Green Bay - 5,913 (565: 5,348)

UW-La Crosse -9,482 (947: 8,533)

UW-Milwaukee - 31,329 (2,973:28,356)

UW-Oshkosh - 12,267 (1,197: 11,070)

UW-Parkside - 5,417 (502: 4,915)

UW-Platteville - 6,666 (655:6,011)

UW-River Falls - 6,592 (602: 5,990)

UW-Stevens Point - 9,835 (1,012: 8,823)

UW-Stout - 9,200 (974: 8,226)

UW-Superior - 3,215 (389:2,826)

UW-Whitewater - 11,546 (1,023: 10,523)

UW-Colleges - 13,084 (802: 12,282)

UW-Extension - 1,092 (1,092: no student data)

UW-System Administration - 248 (248: no students)

Source: UW System 2006 Fact Book


Attachment I

University of WisconsinEnterprise IT Infrastructure: Current State

OverviewThis document represents an overview of the current enterprise applications and infrastructure in place at the University of Wisconsin in support of the business needs of higher education. This document is intended to baseline the understanding of the University of Wisconsin’s current state to vendor representatives so that a roadmap for the adoption of enterprise application infrastructure (middleware) is well grounded.

Enterprise Applications

1. Oracle/PeopleSoft Student Administration a. 10 of the 14 campuses in the UW-System have deployed – other 4 will deploy in the next 2-3 yearsb. Most deployments are done at the campus – with the exception of 2 deployments at the UW-Madison

shared resource (FASTAR) servicec. Customizations vary from campus to campusd. Most campuses will be @ 8.9 by end of year – one is thinking about staying @ 8 until 2008e. Systems operated mostly autonomously with some sharing of code, experiences, tools and techniques.f. UW-Madison implementation is called ISIS – Integrated Student Information System

2. Oracle/PeopleSoft Financialsa. Centrally deployed to most campuses within the UW-System. All campuses will be using within the

next several yearsb. Adding Expense Reporting and Grants as modules within the next 1.5 yearsc. Currently upgrading to version 8.9d. Possible future target for federated authentication and access management (integration with local

campus authentication and authorization schemes)


e. Possible future target for presentation through multiple venues (integration with local campus portals or content management infrastructure)

f. Work being done by the State of Wisconsin is influencing University of Wisconsin’s timelines and strategies (e.g. eProcurement)

3. Oracle E-Business Suitea. Internal business application for DoITb. Storefront integrated with inventory and order modulesc. Data feeds for customer base come from legacy Human Resource and student administration system

4. Legacy Human Resources/Benefits/Payrolla. Payroll is used by all campuses within the UW-Systemb. Faculty/Staff payroll is COBOLc. Student payroll is Oracle Developer applicationd. Human Resources (IADS – Integrated Appointment Data System) contains data about all employees in

UW-System. Each campus accesses IADS data (via sFTP) to run their own shadow Human Resource systems (providing supplemental information about their employees)

e. Benefits uses the same IADS model

5. Oracle/PeopleSoft Human Capital Management (HCM)a. Licensed – to be deployed in the next 2-3 years – not sure of versionb. Questions surrounding benefits of partial implementation of HCM in support of workflows and/or system

of record for employeesc. Likely to need some level of federation in identity and access managementd. Likely to be a popular source for data to drive detailed authorization decisions.

6. Clarify Customer Relationship Management (CRM)a. Help Desk application for UW-Madison campus is currently Amdocs/Clarifyb. Data feeds for customer base come from legacy Human Resource and student administration systemc. In early phases of evaluating future CRM solutionsd. Some basic integration with uPortale. Help Desk has developed a custom-built Knowledge Base

7. Oracle Collaboration Suite – Calendara. Licensed for all students and staff for the UW-Madison campusb. Policy is to retain calendar account until NetID is de-activated (scheduled process – sometimes takes

months)c. Entitled through service flag in LDAP – changes to authorization driven by role as defined in UDS

systemd. WebISO enablede. Available through uPortal (web client)f. Some basic integration with campus event systems through batch extract and loadg. Calendar group management driven through batch extract and load of Human Resource information

8. Sun E-Maila. Licensed for all students and staff for the UW-Madison campusb. Policy is to retain email account until NetID is de-activated (scheduled process – sometimes takes

months)c. Entitled through service flag in LDAP – changes to authorization driven by role as defined in UDS

systemd. WebISO enablede. Available through uPortal (web client)

9. uPortala. Open Source portal software (Madison campus only)b. Integration with student content – link to student center w/ single sign-onc. Advisor content required custom code to allow advisor to assume role of studentd. uPortal is not the sole presentation layer for enterprise applications – many end users access these

applications directlye. Some role-based content delivery based on very broadly defined roles (student, employee, applicant,

etc)

f. WebISO enabled


10. Desire2Learn CMSa. Web-based CMS built in ASP/SQL Server (moving to .NET)b. Interfaces are customizations created by vendorc. Primary interfaces are course roster (student, courses, instructors) feeds and eGradingd. Used UW-System-wide – authentication using AuthHub (a locally developed system for federated

authentication)e. Potential for other CMS products to be run across the enterprise

11. University Directory Service (UDS)/Registrya. UW-Madison directory and registry servicesb. Populated from Human Resource system (FTP/file), PeopleSoft Student (DB Link), and “Special

Authorization” database table (DB Link) – with potential for more feedsc. Central IT organization does not control data sourcesd. Feeds are Near real Time and batche. UDS service consolidates these feeds into a master representation of the constituent with some

consolidation of specific business information into broad roles (student, employee, applicant, etc)f. UDS masters campus identifiers and credentials (NetID, PVI, Campus ID, Photo ID)g. View of consolidated constituents (DRExport) is used as an attribute store and also populates LDAP

and Kerberos servicesh. LDAP population sets service flags based on source system granting access to enterprise applications

like uPortal, Calendar and emaili. WebISO solution (pubCookie) uses LDAP service

12. IAA (Identification, Authentication, Authorization)a. Populated in the same manner as UDS/Registry – but for all campusesb. IAA masters system-wide identifier (SPVI)c. IAA is used for minimal authorizations based on attributesd. IAA has a custom proxy authentication service that authenticates users into enterprise applications

using local credentials (Auth Hub)e. SFS will be using IAA Auth Hub for authentication in February 2007f. Working towards a combined registry (UDS/IAA)g. Potential to migrate IAA/AuthHub to Shibboleth

13. Hyperiona. System-wide Business Intelligence suiteb. Authenticated through IAAc. Used to access data views from data martsd. General interest around dashboards across System

14. Informaticaa. System-wide Extract Transform and Load (ETL) toolb. Used sporadically (along with techniques like SQRs) to populate data marts

15. Kronosa. System-wide timekeeping application deployed to subsets of employees (primarily student employees)

across various UW campusesb. Current pressure from campuses to integrate Kronos with IAA and Auth Hub

16. Xythos (My WebSpace)a. Web-accessible file storage systemb. Licensed for all students and staff for the UW-Madison campusc. Policy is to retain account until NetID is de-activated (scheduled process – sometimes takes months)d. Entitled through service flag in LDAP – changes to authorization driven by role as defined in UDS

systeme. WebISO enabledf. Available through uPortal


17. Auxiliary Applicationsa. Large applications that are either purchased or custom-builtb. Not necessarily run by central IT organizationc. Examples include Housing, Parking, E-Commerced. Main points of integration with enterprise infrastructure include authentication services, attribute

delivery (either from IAA, UDS or data marts) and uPortale. Frequent pressures from these applications for infrastructure that supports federation of identity and

access management and multiple venues for presentation and integration.

18. Network accessa. Comprehensive wireless infrastructure integrated with campus LDAP/RADIUS authentication systemb. Some implementations of port-based authentication and access control on the wired network.c. VPN service integrated with campus LDAP/RADIUS authentication scheme. Little sophistication in

authorization or access control logic.d. Many tactical deployments of transport-level proxies controlling access based on authentication. No

holistic strategy and little in the way of sophisticated access control based on role or user data.

AMENDMENT #1

QUESTIONS & ANSWERS FOR 08-5878(IDENTITY AND ACCESS MANAGEMENT SOFTWARE)

Q1: Section 1.1Are you looking for changes to be tracked within the identities (themselves), or to changes to be tracked within the identity management suite itself (configuration changes?

A1: Both

Q2: I understand there are 900k identities (active and in-active), and growing. Can you help me understand the number of current active identities? Are these identities related in a 1:1 relationship with user accounts? Is there a way to distinguish between active and inactive users?

A2: There are 250,000 active identities. No- they are not related 1:1 with user accounts. There are attributes that distinguish between active and inactive users.

Q3: Section 3.4Who and how it’s determined whether the general market conditions change, regarding the lowering of prices?

A3: The Contract Manager from UW- Madison Purchasing Services in conjunction with the Division of Information

Technology (DoIT) is the sole judge of the acceptance of any prices changes whether it’s an increase or decrease. Increases are limited to changes in the Federal Consumer Price Index (CPI) from the previous year. This language is included in the RFP.

Q4: Section 4Are you looking for a replacement of your current LDAP directory, or an additional LDAP directory for greater functionality?

A4: Either/Both Q5: General Question:

I didn't see it, but it is important to ask. Are you looking for the proposal to include hardware? A5: No

Q6: Are there any other IAM modules in the UW's stack that are not listed in the RFP document? Are there any other details such as version, etc for those products?

A6: No

Q7: Would it be possible to get an extension of at least 14 days for proposal submittal?

A7: The deadline has been extended until September 6, 2007 at 2:00 p.m.

-2-

Q8: We only have two questions regarding pricing our solution at this time. Our proposed solution will be based on a User Based Pricing Model. We classify Users as either Internal Users or External Users.

An Internal User is part of the Enterprise. (i.e. employee of the State)

An External users is not part of the enterprise (i.e. Student, Alum, Contractor, Supplier)

For Option 1: UW System Enterprise License Total head count is: 193,372

Out of the 193,372 Users, can you classify how many are Internal or External Users?

A8: The detailed breakdown is provided in the chart below which is part of the answer to Question 9. This information

will replace the chart in Option 2 of Attachment B: Cost Proposal. Option 1 will also be updated to reflect separated numbers.

However, Proposers should note: Their response to the Cost Proposal for Options 1 and Option 2, should be provide in the format directed by the RFP process. Their proposal may not be considered if they do not comply with the instructions. Proposers may submit an alternative (Option 3) but at this point, it’s for information purposes only.

Q9: For Option 2: UW System Campuses Purchase Instances Individually

UW- Eau Claire - 11,588 UW-Green Bay - 5,913 UW-La Crosse -9,482 UW-Milwaukee - 31,329 UW-Oshkosh – 12,267 UW-Parkside - 5,417 UW-Platteville – 6,666 UW-River Falls - 6,592 UW-Stevens Point - 9,835 UW-Stout - 9,200 UW-Superior - 3,215 UW-Whitewater - 11,546 UW-Colleges – 13,084 UW-Extension – 1,002 UW-System Administration - 248

For each location User Count, can you separate by Internal Users or External Users?

-3-

A9: The information is below. It will replace Option 2 of the Cost Proposal. In addition, Option 1 has changed to reflect the Fac/Staff and Student counts separated.

SoftwarePlease note: Fac/Staff data first/Student data second

University of Wisconsin- Madison - includes Madison plus other Campuses for Shared Resources - 193,372 (28,497: 164,875)

UW- Eau Claire - 11,588 (1,082:10,506) UW-Green Bay - 5,913 (565: 5,348)UW-La Crosse -9,480 (947: 8,535)UW-Milwaukee - 31,329 (2,973:28,356)UW-Oshkosh - 12,267 (1,197: 11,070)UW-Parkside - 5,417 (502: 4,915)UW-Platteville - 6,666 (655:6,011)UW-River Falls - 6,592 (602: 5,990)UW-Stevens Point – 9,835 (1,012: 8,823)UW-Stout - 9,200 (974: 8,226)UW-Superior - 3,215 (389:2,826)UW-Whitewater – 11,546 (1,023: 10,523)UW-Colleges - 13,084 (802: 12,282)UW-Extension - 1,092 (1,092: no student data)UW-System Administration - 248 (248: no students)

Q10: The only other question we have is what requirements does the U of WI-Mad have for the Affirmative Action Plan. It sounds to us like it may be different than the Federal AAP.

A10: The reporting requirements based on dollar and employee thresholds are lower than the Federal Government Affirmative Action Plan. Their reporting requirements are more extensive than the State of Wisconsin.

Q11: Section 6.3.1.2 References replacement of the Custom Identity and Affiliation Manager. Is this synonymous with the current UW-Madison role-based access management system?

A11: Yes

Q12: Section 6.3.1.4What are the "Key Systems" along with expected instances that are within scope of a Services engagement SOW?

A12: Please reference Attachment A: Requirement 2.5.2 of the RFP. In addition, the list is below: ERP Applications

o PeopleSoft Student Administrationo PeopleSoft Financial Managemento PeopleSoft Human Capital Managemento PeopleSoft Enterprise Expenses

RDBMS (local accounts)o Oracle RDBMS (on various platforms)o DB2 on IBM Z/OSo MySQLo MS SQL Server

-4-

Q13: Will UW consider an extension to the due date of August 30 for the responding vendors?

A13: The deadline has been extended until September 6, 2007 at 2:00 p.m.

Q14: Can you share with us who else has been invited to respond?

A14: State of Wisconsin procurement processes do not allow for this information to be released at this time.

Q15: We are making an assumption that the consulting SOW and estimated pricing is limited for the Implementation road map section as defined in section 6.3.1.1 only. Please confirm. Hourly prices will address the implementation services required based on the output of the roadmap.

A15: The assumption is not correct. Proposers should provide an estimated price for the Detailed Implementation Roadmap based on the information provided in Section 6.3.1.1. This information may be considered as part of the cost evaluation at the sole discretion of the University.

In addition, Proposers should provide hourly rates for the resources defined in Section 6.3.2 of Attachment A: Technical Specifications. These resources may be engaged at any time during the five year life of the contract by the University. For each engagement a specific SOW will be developed by the Contractor based on the rates offered as part of their response to the RFP. During the term of the contract prices may be adjusted based on Section 3.0 of RFP Specification

Q16: In the RFP, there is a lot of reference to U of WI's current infrastructure and the new products compatibility with it. Do you have a document which would give us a better picture of the current environment state at U of WI?

A16: The University has added Attachment I: “University of Wisconsin Enterprise IT Infrastructure: Current State” to the RFP.

Q17: 3.1 Architecture: This is the language form the RFP:

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.

3.1.5 Hardware Requirements: Provide the minimum and recommended hardware requirements for each server given the scale of our implementation.

QUESTIONS:Q17a: How many authorizations per second are required?

A17a: See background information in RFP Section 3.0 Performance and Contract Requirements for this information. The directory performs an average of 600 operations per second.

Q17b: Are all transactions in SSL?

A17b: All Web Access Management Connections are SSI encrypted. SSL/TLS encryption of LDAP connections is offloaded onto separate hardware, so does not affect hardware planning.

-5-

Q18: 6.3 Consulting Services: This is the language from the RFP:

6.3.1 Initial Engagement-Detailed Implementation Road Map (for Madison Campus): The University Wisconsin-Madison will require a phased implementation of any IAM suite purchased, integrating the deployed capability in each phase with our existing infrastructure and any previously deployed capability. The initial engagement between your consulting services and the University Wisconsin-Madison will therefore be a detailed road map for the succeeding phases. The exact nature of those phases is to be considered negotiable until the road map is complete, but what follows is the University Wisconsin-Madison’s current understanding of the work required to deploy an IAM suite. Provide a detailed Statement of Work for a project that would cover this effort. On your Price Sheet, also give the estimated cost for this project.

6.3.1.1 Implementation Road Map • Policy analysis with multiple University-represented sponsors, constituents, and IT personnel.

• Vendor garnering a complete understanding of the existing University identity management components, directories, and manual provisioning processes.

• The map itself, with defined phases and milestones within phases.

• Provide diagrams describing the migration from existing to new or the integration of existing with new.

• Describe the general time frames associated with each phase.

• Describe the primary team roles involved in each phase.

• Describe the testing plan for measuring the success of each phase.

• Describe the training or expertise required to complete each phase successfully.

6.3.1.2 Phase I -Replacement of Custom Identity and Affiliation Manager (UW Madison Special Authorization for Photo ID System)

• Policy analysis. • Large data migration of identities, roles and attributes in production.

QUESTIONS: Q18a: How many identities to be migrated?

A18a: All current identities.

Q18b: Is any authoritative data currently encrypted and if so in what format?

A18b: Currently pass word data is encrypted but are looking to add for example: SSN information Drivers license data.

The encryption format is DES3. Data is encrypted in the database and in the directory.

Q18c: Where, how and in what format is this information stored today?

A18c: RDBMS

Q18d: What are the authoritative source(s) that feed the existing production system?

A18d: PeopleSoftMainframe- DB2 and IMSFlat Files

-6-

Q18e: What is the back end technology for the authoritative source(s)?

A18e: PeopleSoftMainframe- DB2 and IMSFlat Files

Q18f: How many roles to be migrated?

A18f: All – average of 12 roles per identity

Q18g: Approximately how many backend resource attributes are managed/effected by role membership to each role?

A18g: Range of 1 to 20

Q18h: Where, how and in what format is this information stored today?

A18h: RDBMS and LDAP

Q18i: How many user related attributes in the form of geography and other general user information is being migrated.

A18i: Average of 30 attributes coming from the four different sources systems.

Q18j: Where, how and in what format is this information stored today?

A18j: RDBMS and LDAP

Q19: All numbered and bulleted points are language from the RFP

6.3.1.3 Phase II -Replacement of Custom Linking Between Authoritative Source Systems

• Policy analysis. • Multiple source system data transformations.

QUESTIONS: Q19a: How many authoritative sources are in the scope of this phase?

A19a: Approximately six. .Q19b: For each authoritative source how many attributes are synchronized between the authoritative source

and the backend resources including the identity system?

A19b: An average of four attributes that we currently “reconcile”.

Q19c: What is the backend technology for the authoritative source?

A19c: PeopleSoftMainframe- DB2 and IMSFlat Files

• Moving sensitive data and accompanying security issues.

Q19d: What attributes need to be encrypted when stored on backend resources or in the identity system?

A19d: Currently pass word data is encrypted but are looking to add for example: SSN information Drivers license data.


-7-

Q19e: Is any authoritative data currently encrypted and if so in what format?

A19e: Currently pass word data is encrypted but are looking to add for example: SSN information Drivers license data.


• Process for reconciling multiple source data records into a single identity.

Q19f: What are the source data record systems?

A19f: PeopleSoftMainframe- DB2 and IMSFlat Files

Q19g: What is the backend technology for each?

A19g: PeopleSoftMainframe- DB2 and IMSFlat Files

• Process for unlinking improperly linked identities, such as when bad data is submitted from source system.

• Process for communicating new identities or changes to identities to downstream systems.

Q19h: What are the downstream systems?

A19h: Please reference Attachment A: Requirement 2.5.2 of the RFP. In addition, the list is below: ERP Applications

o PeopleSoft Student Administrationo PeopleSoft Financial Managemento PeopleSoft Human Capital Managemento PeopleSoft Enterprise Expenses

RDBMS (local accounts)o Oracle RDBMS (on various platforms)o DB2 on IBM Z/OSo MySQLo MS SQL Server

Q19i: What is the backend technology for each?

A19i: Attachment A: Technical Requirements: “Section 2.5 Provisioning Accounts and Managing Identities in Client Systems”, contains the detailed information.

Q19j: What change information needs to be communicated downstream to each?

A19j: All attribute changes or account creation/termination.

• Creating pre-production and production systems that communicate with authoritative sources.

Q19k: What are the authenticate source systems?

A19k: PeopleSoftMainframe- DB2 and IMSFlat Files

-8-

Q19l: What is the backend technology for each?

A19l: PeopleSoftMainframe- DB2 and IMSFlat Files

Q19m: What information needs to be communicated for each?

A19m: All attribute changes or account creation/termination.

Q20: All numbered and bulleted points are language from the RFP

6.3.1.4 Phase III -Replacement of Manual or Custom Provisioning to Key Systems

• Policy analysis. • Business process analysis with possible consulting service to assist with process change.

• Moving sensitive data and accompanying security issues.

• Creating pre-production and production systems that provision to external University systems.

QUESTIONS: Q20a: What will be the scope of this phase in regards to external university systems?

A20a: This phase relies heavily on what you propose in the previous sections of the SOW.

Q20b: What is the backend technology for each external system in the scope?

A20b: Yet to be determined.

Q20c: What type of information / attributes needs to be sent to external University systems?

A20c: We are changing this requirement in the RFP. Please reference the replacement page in this addendum it removes the word “external”.

Q20d: Is this a push of data to the external University systems or a synchronization of data?

A20d: We are changing this requirement in the RFP. Please reference the replacement page in this addendum it removes the word “external”.

Q21: Attachment B – Cost Proposal Form In order for us (Sun) to price our software we need to know Full Time Faculty count. We have this data for all UW System campuses (from IPEDS data) except UW-Extension.

Can you please provide Full Time Faculty count for UW-Extension?

A21: 1,092

Q22: We are vendor that can only provide a response to the user provisioning section of the RFP. In addition, we do not provide a web access management component and we would have to assume that Microsoft AD was the preferred directory services solution for the U Wisconsin.

A22: The University will only accept proposals that are for an entire Identity and Access Management Suite of products and related services and training.

Documents

08-5878 (Amendment