ADDENDUM 2. This Addendum forms part of and modifies Proposal Documents dated, July 10, 2015, with amendments and additions noted below.

Transcription

1 DATE: August 10, 2015 PROJECT: Identity Management Consulting Services RFP NO: 744-R1525 Identity Management Consulting Services OWNER: The University of Texas Health Science Center at Houston TO: Prospective Proposers This Addendum forms part of and modifies Proposal Documents dated, July 10, 2015, with amendments and additions noted below. 1. Questions & Answers QUESTION 1: We understand that under section 5.2- Minimum Requirement point number 2 on page 8 of the RFP; minimum requirement is that the service provider should have demonstrated experience deploying NetIQ Identity Manager Products in academic institutions of higher education, preferably those that are also health institutions. Will UTHealth consider an implementation of similar product as relevant to the RFP e.g. Microsoft Forefront Identity Manager? ANSWER 1: The Microsoft s product implementation would not be accepted in that requirement. We need a consultant that is well versed in NetIQ s product, not a competitor s. QUESTION 2: Further, is UTHealth open to relax the requirement regarding deploying the NetIQ Identity manager in academic institutions of higher education? ANSWER 2: The requirement of higher education experience with NetIQ IDM will not be relaxed, but we would accept a vendor that has worked on an existing deployment of NetIQ IDM in higher education, as opposed to deploying it themselves. The important thing is that vendor has worked with NetIQ IDM in the higher education space. QUESTION 3: What is the total user population? ANSWER 3: Approximately 18,000 or so active users. Approximately, only 1,133 of these are active residents. Page 1 of 7

2 QUESTION 4: How many SQL Server databases need to be replaced? ANSWER 4: One. There is a production and test instance of this database. QUESTION 5: What use-cases exist today for the existing Residency Management System (RMS) which needs to be migrated? ANSWER 5: Need clarification on use-case. QUESTION 6: Will the connection to the cloud based RMS be over proxy? ANSWER 6: No. QUESTION 7: Is password synchronization with RMS system in scope? ANSWER 7: No. SAML authentication will be established independent of this proposal. QUESTION 8: Does the new RMS system expose Webservices required for the functionalities to be implemented as a part of this project? ANSWER 8: Yes. SOAP based web services are available. QUESTION 9: Is the current SQL driver for the home-grown system well documented for reference purposes? ANSWER 9: Formal documentation is not available, however access to all of the SQL views and driver rules can be provided, as well as a verbal explanation of the system. QUESTION 10: How many system users are on the home-grown Residency Management System currently? Page 2 of 7

3 ANSWER 10: There are currently 1,133 active and 4,736 inactive. Inactive users should be factored into the scope as we maintain IDM associations to them. QUESTION 11: Is there (or will there be provided) a test/dev instance of New Innovation s Residency Management System? ANSWER 11: Yes. QUESTION 12: What is the version of Net IQ? ANSWER 12: AE QUESTION 13: What is the number of environments in place? Dev, Test, Prod etc. ANSWER 13: One Test and one Production. QUESTION 14: Kindly provide the Net IQ Identity Manager existing logical architecture with the list of target systems integrated. ANSWER 14: Our IDM environment consist of two split environments with two separate meta directories, one for registration and provisioning which we call our Registry, and the other which we call our Vault that is used for directory services. The Registry consists mostly of publisher drivers that feed the directory with users from various source of authority systems. These source systems include PeopleSoft HCM (HR system), PeopleSoft Campus Solutions (students and applicants), Guest SQL DB (for guest users), UTP SQL DB (Physicians HR system), and GMEIS (residency system). Users are on-boarded into these respective source systems and provisioned to the Registry. Any duplicate accounts are automatically or manually merged, and given both a random and identifiable unique identifier. Additionally, users are given a multi-valued attribute we call a data source indicating what source system(s) they are associated with as a single user may exist in several source systems. The presence of this attribute/value dictates whether a user should be further activated in various subscriber systems, such as our second IDM environment, our Vault. Users with an active data source are automatically provisioned there, locked when removed, and finally purged after a period of inactivity. Page 3 of 7

4 The Vault serves are our primary enterprise user store, from which other drivers provision active users to additional downstream systems such as Active Directory, as well as a number of SQL databases. QUESTION 15: Is there a TEST instance available for the Residency Mgmt System on the cloud? ANSWER 15: Yes QUESTION 16: What is the count of users that have access to the existing system and that need to be migrated? ANSWER 16: There are currently 1,133 active and 4,736 inactive. Inactive users should be factored into the scope as we maintain IDM associations to them. There are approximately 2,500 additional users which access the system for administration who are not residents, and will not be in scope of this driver. QUESTION 17: Please confirm that the scope of work is restricted to only the new driver development, testing and deployment and does not require any other configuration / customization changes to existing Net IQ implementation. ANSWER 17: The scope of this work is to develop and integrate a new replacement driver. The need to modify other existing drivers is dependent on the approach selected to integrate this new driver. For example, the residency driver creates an attribute value we call a data source, indicating an associated user should be active in that system. This data source value is used on dozens of other drivers. If integration requires creating a new data source value, policies in other drivers may need to be adjusted. Otherwise, we do not anticipate customizations will be required to other drivers. QUESTION 18: What are the timelines / schedule for the new Residency Management system (Cloud based)? Can you kindly share the high level plan? ANSWER 18: Begin IDM interface in September; complete by end of October. QUESTION 19: Is there any other SOAP based driver already integrated? Page 4 of 7

5 ANSWER 19: No QUESTION 20: Is the Web Service interface for the new system ready for integrating with the SOAP Driver? ANSWER 20: Yes. QUESTION 21: Will this application require explicit password for user authentication or some other authentication mechanism is available? Like SSO. ANSWER 21: SSO (SAML) will be implemented for user authentication separately from this project. QUESTION 22: Are all the web services required for user provisioning into new system available out of box? Example: Add User, Modify User, Change Password, Delete user etc. ANSWER 22: The vendor has already created customized web services for us to replicate how our existing residency driver interacts. If any new web services are required, the vendor can create these. QUESTION 23: Will it be a request based provisioning or a birth right provisioning? ANSWER 23: There should be a status available on the source account indicating if a user is active. All active users will be provisioned. We expect the source system to notify the IDM driver when a user is available to be provisioned. QUESTION 24: In current existing implementation, how users are getting access to this application (the home based solution)? Are we going to follow the same approach in new integration? ANSWER 24: User access to the application is not in scope. This project only involves user provisioning into IDM. The logic of the new provisioning driver should work as close as possible to the existing one. Page 5 of 7

6 QUESTION 25: For migrating existing users to new System, what approach is desired to follow keeping the data security into consideration? ANSWER 25: Migration of users between the old and new RMS system is not in scope of this request. It can be expected that existing users will already be imported into the RMS prior to work engagement. QUESTION 26: Are there any schema changes, attribute mapping and other data model changes that are expected in the new Residency Management system? ANSWER 26: Yes. This new system has its own schema and attribute naming conventions separate from the legacy system. QUESTION 27: Is HUB subcontracting a mandate for this RFP? Is there a separate HUB Document attachment as an addition to the RFP document? Section seems to be absent/unavailable in the document. ANSWER 27: UTHealth has determined that a HUB Subcontracting plan is not required for this solicitation. QUESTION 28: Is there an additional addendum/attachment for W9 form to be submitted? ANSWER 28: You should submit your W9 on your own form. QUESTION 29: Is there a developer site for the New Innovations SaaS application? ANSWER 29: No. QUESTION 30: Is there a "WSDL" (Web Services Description Language document) available? ANSWER 30: No. This will be set up as a Web API and route documentation will be provided by New Innovations. Page 6 of 7

7 QUESTION 31: Is the existing SQL driver primarily subscriber (IDM to application), publisher (application to IDM) or both? ANSWER 31: Both, however this driver is primarily publisher based. We currently only send two attributes back on the subscriber (unique ID and address). QUESTION 32: Does the existing residency management system support only users or are other classes of objects supported? ANSWER 32: For the purpose of this project, only the user class is subscribed to IDM. QUESTION 33: Are any sorts of behaviors programmed beyond a simple synchronization in the existing driver for adding, renaming, moving, modifying or deleting users? ANSWER 33: The driver has a number of attribute formatting rules. QUESTION 34: What attributes are currently synchronized from the home-grown SQL based residency system? ANSWER 34: , unique ID, active status, department name, date of birth, gender, application identifier, SSN, first/middle/last name, place of birth, postal address, room number, street, telephone, emergency phone, title. QUESTION 35: Are any attributes written back from IDM to the application? Which ones? ANSWER 35: Unique ID, address END OF Page 7 of 7