session abstract

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

Upload: jessica-george

Post on 02-Jan-2016

21 views

Category:

Documents


0 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Session Abstract

ITANA Screen-to-Screen: Enterprise Authorization

Presented by: Marina Arseniev, Director of Enterprise Architecture, Security, and Data Management Services

Administrative Computing Services, UC Irvine

April 16, 2009 - 1:30-3:00 pm EDT

Page 2: Session Abstract

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.

Page 3: Session Abstract

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

Page 4: Session Abstract

What does UC Irvine’s Administrative Computing Services do?

Financial System IBM Mainframe

CICS/Cobol

Data CenterDesktop Support

And Helpdesk

SNAP Administrative Portal

uPortal Web/Java

TED Learning Management

Microsoft IIS/.ASPVendor

Facilities Management Work Order / BillingTririga ERP Vendor

JBoss/Java

Payquest Reimbursement

SolarisWeb/Java

Payroll at UCOP IBM Mainframe

CICS/Cobol

Purchasing andAccounts Payable

IBM MainframeCICS/Cobol

Human ResourcesSelf-Service

Solaris Web/Java

Student Billing SystemPowerbuilder

GreenTree Hiring Manager/

Applicant Tracking System Microsoft IIS/.ASP

Vendor

Budget SystemPowerbuilder

FacilitiesSelf-Services

SolarisWeb/Java

And much more…

Central Credit Card Payment - Solaris

Web/Java

Page 5: Session Abstract

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

Page 6: Session Abstract

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

AcademicServices

Student SSNs

RegistrarGraduate

Studies

Payroll

AdministrativeComputing Services

Office of InstitutionalResearch

ParkingHousing

HealthSciences

StudentHealth

Page 7: Session Abstract

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!

Page 8: Session Abstract

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

Page 9: Session Abstract

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…

Page 10: Session Abstract

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

Page 11: Session Abstract

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

Page 12: Session Abstract

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

Page 13: Session Abstract

Requirements: System Features1. 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.

2. High: Integration for Vendor and “Externally developed” systems such as Kuali Financial System, Kuali Coeus, Hannon Hill Content Management System (CMS), Portal (uPortal)

3. High: Web server file and directory access controls for IIS, Apache, JBoss, Tomcat

4. High: Delegated access control administration over different business domains. Roles.

5. High: Reports indicating when access was last reviewed

6. High: Complete audit capabilities including reporting and retention of all historical snap-shot and transaction records.

7. High: Shibboleth, Campus SSO (WebAuth) support

8. High: Identity Management Integration – Kuali KIM, Sun’s OpenSSO / Access Manager

9. High: Scalability, 24/7 availability, robustness, ability to cluster, performance

10. 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.

11. Medium: Operating System access control support (group and user) including Microsoft (Active Directory), Mac OS X, Linux, and Solaris.

Page 14: Session Abstract

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?

Page 15: Session Abstract

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

Page 16: Session Abstract

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!

Page 17: Session Abstract

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

Page 18: Session Abstract

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?

Page 19: Session Abstract

Part 2 – Working Session