Identifying an Identity Management Solution

1. Identifying an Identity Management Solution Bryan Skowera Director of Network Services Fairfield University 914 Faculty Members (including Adjuncts) 883 Staff Members 8509 (8633) Students

3. Self-Service Password Resets Automated Provisioning • Access Management • Separation of Duties • Single Sign On • Self-Service Account Management • Attestation and Certification Automated Deprovisioning

4. Horribly Incomplete Glossary Authoritative Source Identity Roles Resource Central Authentication Password Synchronization Single-Sign On

5. Fairfield University 2008 Banner Active Directory/Exchange for Faculty Email through Luminis Portal for Students Numerous stand alone applications with no central authentication. And then

6. “All students shall be given the Google Mail by next Fall, so sayeth the Administration.”

7. Fairfield University 2009 Identity Management Authoritative Source: Banner Automatic (de)Provisioning to Resources (Active Directory/Exchange, Google Apps and new LDAP directory) Central Authentication (Active Directory and LDAP) Password Synchronization Self-Service Password & Basic Account Management

8. Lessons Learned

9. Agreeing on the meaning on a word is a near impossible task. • Death by committee is alive and well. • Own the expertise or owe the experts. • The biggest surprise…… • Identity Management does not fix broken business processes, it exacerbates them. • “Day One Blues” • “Standard Policies for Everyone…but Me” • “Department of Redundancy Department”

10. 2012: The Wheel in the Sky Keeps on Turning Three years in, our existing solution was: • Obsolete, with no in-place updates/upgrades. • Unable to communicate with newer applications. • Environment and business processes had changed. • Unsupportable (but “supported”) by the vendor with few reliable 3rd parties to provide custom work.

11. 2012 Summer: Pre-Search Phase Carefully set scope – Not a replacement, but a migration of functionality to a new platform. Small search committee with concentrated focus. Resolution to get the Value Add from our Value Added Resellers. Formalize Business Requirements

12. Business Requirements: Breaking their Wills The bare-minimum it takes to get in the running. Has a limited relationship to Selection Criteria. • Platform • Must run on an OS platform compatible with VMware ESXi 5.0. • Application itself must be compatible with VMware ESXi 5.0. • Must run on an OS platform compatible with Syncsort BEX. • CentOS • Microsoft Windows (Preferred) • Red Hat Linux (Preferred) • SUSE Linux Enterprise • Application must be secured with SSL. • Application must secure/encrypt sensitive data such as passwords and identity validation information.

13. Business Requirements (Excerpts) • Resource Compatibility • Active Directory / Exchange • Must have out-of-the box functionality for provisioning of Active Directory and Exchange accounts. Must support Exchange as an optional provisioned entitlement. • Must have out-of-the-box functionality for deprovisioning Active Directory and Exchange accounts. Must support the deprovisioning of both Active Directory/Exchange and only Exchange. • Must have out-of-the-box functionality for managing account enablement / disablement and password status of Active Directory. • Must either have out-of-the-box functionality to write Active Directory attributes or the ability to insert PowerShell scripts. • Must have out-of-the-box functionality for detecting, reporting and resolving duplicate account names during creation of a new identity. • Must have out-of-the-box functionality for truncating account names over twenty characters long when provisioning SAMAccountName.

14. Business Requirements(Excerpts) Identity Claim Process • Must support a claim process in which an identity is disabled until claimed. • Must support a claim process in which some attributes are not generated or are changed upon claim. Passwords • Password Policy • Must support implementation of password requirements defined by the University. • Must support password synchronization against all resources. • Must support password expirations across all resources with passwords. • Self-Service Password Resets for Forgotten Passwords • Must support self-service password resets for if a user has forgotten a password. • Must require password uniqueness against previous passwords. • Must require validation of user identity. • Self-Service Password Changes • Must support self-service password change. • Must require password uniqueness against previous passwords. • Administrative Password Resets and Changes • If the system automatically generates new end-user passwords during an administrator initiated change or reset, a prohibited character list should be enforced. (Example: Ambiguous characters like the number one (1) and the letter “l” should not be used.)

15. 2012 Fall: The Search Begins Business Requirements distributed to VARs and existing partners. Vendors who claim to meet our Business Requirements are vetted in follow-up conversations. Vetted vendors are asked to confirm in writing their ability to meet the Business Requirements. Refuse demos or sales meetings. Begin work on the Selection Criteria.

16. Selection Criteria:No Witty Subtitles Here Selection Criteria document contains both “must haves” and “wants”. Each criterion has a detailed description, a method to measure and an agreed upon importance/weight. Selection Criteria doc is an internal document, not to be shared with vendors. Selection Criteria almostset in stone before diving into any details with vendors.

17. Selection Criteria (Excerpts) Total Cost of Ownership (TCO) – Importance: 3 The TCO should be based on a five year model. For each of the solutions, the TCO should be calculated to include: • License of the base software, expressed either as a per year sum or per user per year sum. • License of all connection software needed to connect to Banner, Active Directory, Google and LDAP as a per year sum. • License of a la carte modules for attestation and reporting expressed as a per year sum. • License of any back-end databases, directory services or application platforms supporting the application expressed as a per year sum. (Example, Oracle Database). • Hardware costs. • Maintenance costs expressed as a per year sum. • Training costs to train four staff members on the installation, configuration and administration of the product and the development of workflows in the product. • Implementation costs based on a sample proposal. • Implementation time based on a sample proposal. • Miscellaneous costs associated with vendor’s recommended architecture, such as the addition of a load balancer. Method: Fairfield University will work with each vendor and potentially one or two of their implementation partners to develop a basic implementation plan. The implementation plan will need to include custom work to develop a claim process and non-employee provisioning. Non-employee provisioning should include a process to match the non-employee account to users in Banner. The vendor and the implementation partner(s) will generate a proposal including the TCO as defined above.

18. Selection Criteria (Excerpts) Vendor Reputation - Importance: 2 The reputation of the vendor should be rated on the following criteria: • Satisfaction of Fairfield University in prior dealings with the vendor. • Satisfaction of Fairfield University peers in prior dealings with the vendor. • Stability of the vendor’s business organization. Method: Fairfield University will send standardized evaluations to internal resources that have had prior dealings with the vendor. The vendor will provide reference clients to Fairfield, preferably with Google Apps, Active Directory and Banner onsite. Fairfield will send evaluations to the reference clients focusing on measurable standards, soliciting feedback on promised implementation times, delivered implementation times and satisfaction with service

19. Selection Criteria (Excerpts) Solution Reputation – Importance: 3 The reputation of the solution should be rated on the following criteria: • Satisfaction of Fairfield University peers in implementation of the solution. • Maturity of the product in its current incarnation. • Historical responsiveness of developer to support major systems • Date of support for Exchange 2007. • Date of support for Active Directory 2008. • Date of support for Exchange 2010. • Date of support for Active Directory 2012. • Date of support for Google Apps. • Satisfaction of Ellucian professional services in implementing the solution. Method: Fairfield University will send evaluations to reference clients focusing on measurable standards, soliciting feedback on integration with Google Apps, Active Directory and Banner, number of support tickets opened for the product with the vendor and time to resolve such tickets. Vendor will provide product revision history. Vendor will provide the dates of support implementation for the listed major systems. Fairfield University will send evaluations to Ellucian professional services to determine average implementation times and costs for each solution.

20. Selection Criteria (Excerpts) Workflow / Resource Requests - Importance: 2 The solution’s workflow and resource request capabilities should be rated on the following criteria: • Ease of implementing a two tiered approval to create an account in a downstream resource. • Ease of implementing a two tiered approval to add group members to an existing account in a downstream resource. • Ease of customizing feedback, rejection and reconciliation within a two tiered approval. • Ability to capture all data submitted during the workflow / resource request for auditing and reporting purposes. Method: Vendor or implementation partner will demonstrate the above processes.

21. Winter 2013:Fight for Our Affection An external version Selection Criteria document is prepared and distributed to vendors. Fairfield University resources spend time explaining our environment and helping scope the Total Cost of Ownership for vendors. The highest preliminary Total Cost of Ownerships is used to scope budget proposals for the next fiscal year (beginning Summer 2013).

22. A Word (or 20+) on Demos Continue to refuse sales demos. From external Selection Criteria document: A word about the demonstrations requested – We’ve asked for demonstrations of a number of system functions. In the majority of these cases, we do not expect a “teaching” demo. Instead, we’d just like to observe the amount of time and effort required to execute these tasks when performed by a trained administrator

23. Best Foot Forward All vendors do a walk through of their presentations and data with point person before addressing the Search Committee. Point person helps standardize jargon and confirm vendor understands what we expect in the demos. If a demo goes poorly due to human error or a shortcoming, give the vendor another chance at a later date.

24. Making the Decision Members of the Search Committee rate each vendor and solution against each component on the Search Criteria. • Very Unimpressed (-3) • Unimpressed (-1) • Neutral (0) • Impressed (1) • Very Impressed (3) Scores are compiled and weighted based on importance

26. Just Because We Picked…. “The search is still ongoing…..”….until a formal quote for all needed products, Master Services Agreement and Statement of Work were agreed upon.

27. Spring 2013: The Fine Print Negotiations with selected vendor begin. Sticking points: Time and Materials versus Deliverables Preventing last minute Scope Creep

28. An Abrupt End to the Presentation