Session Abstract

1. ITANA Screen-to-Screen:Enterprise Authorization Presented by: Marina Arseniev, Director of Enterprise Architecture, Security, and Data Management ServicesAdministrative Computing Services, UC Irvine April 16, 2009 - 1:30-3:00 pm EDT

2. Session Abstract • Truly enterprise-wide authorization solutions present challenges from the technology perspective and even more challenges from the business and cultural requirements perspective. Questions about scope, granularity, roles, delegation, and data integration with vendor and other software continue to be posed in many institutions where authorization solutions have difficulty meeting campus needs. Specific common problems and case studies, such as campus-wide access audits, are the focus of this session. We will share real-world experiences, identify common requirements and discuss solutions (successful or possibly not) to better understand common challenges. • This session will discuss why enterprise authorization is so elusive for so many of our institutions; it will be a forum to share successes and failures. The goal is to define what specific actionable steps or decisions architects across our campuses might be able to make that bring vision and clarity to their organizations.

3. Agenda • Part 1 - Presentation and Discussion – 30 minutes • UC Irvine’s Case Studies • Our Requirements • Alternative solutions and products reviewed • Role of “business process / data owners”. Campus Auditor / Controller role. • Part 2 - Working Session – 60 minutes

4. What does UC Irvine’s Administrative Computing Services do? SNAP Administrative Portal uPortal Web/Java Financial System IBM Mainframe CICS/Cobol Central Credit Card Payment - Solaris Web/Java Payquest Reimbursement Solaris Web/Java Purchasing and Accounts Payable IBM Mainframe CICS/Cobol Human Resources Self-Service Solaris Web/Java Payroll at UCOP IBM Mainframe CICS/Cobol GreenTree Hiring Manager/ Applicant Tracking System Microsoft IIS/.ASP Vendor TED Learning Management Microsoft IIS/.ASP Vendor Facilities Self-Services Solaris Web/Java Student Billing System Powerbuilder Facilities Management Work Order / Billing Tririga ERP Vendor JBoss/Java Budget System Powerbuilder Data Center Desktop Support And Helpdesk And much more…

5. Case Study – Our computing environment Cobweb • Effective authorization and access control across all the systems, platforms, vendor solutions, and languages we support is extremely challenging • User provisioning and termination of access is complex, error prone, and often not sufficiently timely • The “cobweb” is only Administrative Computing applications, not of the whole “enterprise”. • Extending authorization services across UC Irvine’s main computing centers requires campus governance and policy, which we struggle with. • We are a decentralized IT campus

6. Case Study – UC Irvine’s IdentityTheft and FBI/Police Collaboration • Campus incurs high risk because the measures being used to protect personal data are inadequate, difficult to administer and impossible to audit centrally. • Between September 2007 and February 2008, UC Irvine’s student SSNs were stolen and used to file their tax returns Registrar Graduate Studies Academic Services Payroll Student SSNs Administrative Computing Services Office of Institutional Research Parking Student Health Housing Health Sciences

7. Case Study – UC Irvine’s IdentityTheft and FBI/Police Collaboration • Group of students affected was finally identified as “Graduate Students” who filed for Student Health Insurance. • Identifying users who had accessed Graduate Student SSNs within a window of time for breach investigation proved difficult in our de-centralized computing environment. • *Many* applications in *many* departments required review and audit of access control lists and proprietary authorization solutions. • Finally, campus leak was ruled out • ‘United Health Care’, an agent of UC that provides student insurance, turned out to have an ‘inside job’ of a ring of identity thieves. Case solved!

8. Case Study – Campus Centralized Credit Card System (CCCS) • UC Irvine has a centralized credit card payment taking web service, offered to all departments • Payment Credit Card Industry Data Security Standard (PCI DSS) require audit trails • Departments are allowed to write their own “store front” and must maintain user access control

9. Case Study – our SAS 112 PriceWaterHouseCoopers Audit • Audit of our financial applications. • Like Sarbanes-Oxley for industry • ‘Proof’ that users only have access to what they need to perform their job requires research scattered across many systems and applications across the campus • Audits on who provided access to whom and when are almost impossible. • Audits on when user access was last reviewed require business “owner” verification and formal documentation. Are rarely done…

10. Case Study – our SAS 112 PriceWaterHouseCoopers Audit • Audits to determine if there is adequate separation of duties and no conflict of interests is difficult. • Example 1: Validate that the same person who is able to “cut a check” is also not the person who can “request a check” • Example 2: Validate that at a specific point in time, this person did not have access to request and approve a salary increase • We don’t use Roles and often, due to staff shortages, the same person may need exceptions to the policy… Our systems today do not meet the audit challenges

11. Case Study: Our current solution ‘SAMS’ • AdCom Services’ Security Access Maintenance System (SAMS) has worked well for delegated access control of AdCom’s administrative and financial systems that rely only on the campus Financial Hierarchy Organization Department Account Fund

12. Case Study: Our current solution ‘SAMS’ • New requirements to restrict by constraints other than the Financial Hierarchy, such as by Building (as in for door locks), Academic Hierarchies, Kuali Coeus research Hierarchies require redesign. • SAMS uses a home-grown proprietary HTTP API for validating access. • Vendor applications are increasingly using open standards including SAML for access control decisions, and integration with those vendor solutions using the homegrown API is expensive and difficult. • There are no Web server plug-ins for SAMS for PHP, ColdFusion, .Net or Java. • Can not be used outside of our Administrative Computing Department

13. Requirements: System Features • High: Web Application Integration for “home grown” applications – API for low-level granularity on access to business functions and resources - .NET, PHP, Java, Cold Fusion. Plug-ins to Apache, Tomcat, IIS at minimum. • High: Integration for Vendor and “Externally developed” systems such as Kuali Financial System, Kuali Coeus, Hannon Hill Content Management System (CMS), Portal (uPortal) • High: Web server file and directory access controls for IIS, Apache, JBoss, Tomcat • High: Delegated access control administration over different business domains. Roles. • High: Reports indicating when access was last reviewed • High: Complete audit capabilities including reporting and retention of all historical snap-shot and transaction records. • High: Shibboleth, Campus SSO (WebAuth) support • High: Identity Management Integration – Kuali KIM, Sun’s OpenSSO / Access Manager • High: Scalability, 24/7 availability, robustness, ability to cluster, performance • Medium: Access control solution should handle access to applications shared with other non-UCI users as well as third-party affiliates with access controlled by and assigned to other UCI users. Federation. • Medium: Operating System access control support (group and user) including Microsoft (Active Directory), Mac OS X, Linux, and Solaris.

14. Use Cases for Enterprise AuthZ • Push or Pull access from home grown and vendor apps • Course view / update • Web Financial application such as Kuali FS, Coeus • Can read/update specific or range of account-level data • Designate financial approvers for several electronic financial transactions • Push ACLs to hosted SAAS applications, such as Connexxus Travel Management or Learning Management System – 24 hour batch feeds • Surveys – access to result or to publish • Portal or Wiki groups • Files / directory access • Targeted Announcements / Calendaring / Events • Who has authority to publish campus emergency notification, budget deadlines?

15. Alternative Solutions Considered • Do nothing • Continue to handle access controls on a per Web server or application basis via internal database tables • Continue to use .htaccess files for Apache • SAMS for AdCom applications • Augment SAMS functionality to support more types of constraints on access and write Web server plug-ins for PHP, ColdFusion, Java, and .NET • Integrate Grouper + a SIGNET-like product • Handle all authorization in LDAP and integrate with Microsoft’s Active Directory and other repositories for access control. • No nice GUI, no auditing, no delegated access control, poor logging • Invest in a vendor product, such as Sun’s Access Manager, for enterprise authorization management

16. Rational for Enterprise Authorization Solution at UC Irvine • We currently spend a great deal of money on staff resources managing access control in individual solutions such as our Portal SNAP, Web servers, Vendor applications, home grown applications, LDAP, and others. • We would reduce costs long term by migrating to a single master-of-record system. • We would improve security, especially in dealing with “separations” and re-assignments of staff across departments. • We could more easily enforce policy, such as “separation of duties”, and detect “conflict of interests” across campus applications • We would pass PriceWaterhouseCoopers SAS 112 audit! • Campus Auditor/Controller would be happy!

17. Non Technical Considerations • Centralized AuthZ requires a culture change, coordination, and education • bottom up, top down, across • Marketing and education of programmers on tools and solutions • Departments: Registrar, Network and Academic Computing, Administrative Computing, Purchasing, Financial Services, Cashier, Payroll, Research and Graduate Studies, Office of Analytical Studies, Health Affairs, • Campus policy must be updated • Enforcement would be done by Audit department • All “business process / data owners”, such as Financial Controller and Payroll must have ultimate approval over all access (and confidence in proper management of delegated access) to their data. • Campus Audit/Controller role must periodically audit access

18. Do other campuses share UC Irvine’s challenges? • We have found no tool that meets all our needs, have you? • What are our common problems? Common Requirements? • How are other campuses handing AuthZ? Is it distributed and delegated? Centralized? • Who is in charge of AuthZ in the campus? CIO/IT? Campus Audit/Controller? Risk Management? • What policies govern AuthZ? • What access control granularity works most effectively? All-or-nothing access to an applications? How about specific functions within an application? • Are roles useful or do too many people span too many roles? • How do you handle “separation of duties” and “conflict of interests”? • What about “separations” and terminations? How are ties to IdM handled? • How do you deal with culture change and training required to run a centralized service? • What has worked well? Why? Good Tools? • Failures? Bad tools?

19. Part 2 – Working Session