Centralizing and Automating Centralizing and Automating PeopleSoft Authority Management PeopleSoft Authority Management

(Security)(Security)

Session #20647

March 14, 2006

Alliance 2006 Conference

Nashville, Tennessee

2

Your PresentersYour Presenters

Kevin Dale – Information System Analyst−At Stanford since July 2001 –

• Business Analyst for Financial Aid, Student Records and Security.

• Lead for the Authority Manager Automation Project.

Minh Nguyen – Software Architect−At Stanford since June 1997 –

• Lead the development of Authority Manager, version 3.0

• Part of the Signet core development

3

Stanford UniversityStanford University

• Founded in 1891Founded in 1891

• Private university Private university

• 6,753 undergraduate 6,753 undergraduate

• 8,093 graduate 8,093 graduate

• 1,775 faculty1,775 faculty

• 7,565 staff7,565 staff

Located 30 miles south of San Located 30 miles south of San Francisco and just north of Francisco and just north of Silicon Valley.Silicon Valley.

4

Your Organization and Your Organization and OracleOracleCampus Solutions 8 SP1Campus Solutions 8 SP1

• PeopleTools 8.22.05PeopleTools 8.22.05

Enterprise Portal 8.8 SP1Enterprise Portal 8.8 SP1• PeopleTools 8.44.03PeopleTools 8.44.03

Enterprise Learning Management 8.8 SP1Enterprise Learning Management 8.8 SP1• PeopleTools 8.45.12PeopleTools 8.45.12

Oracle e-Business Suite 11.5.9Oracle e-Business Suite 11.5.9

5

AgendaAgenda

Authority Manager – SignetAuthority Manager – Signet• What is Signet?What is Signet?• FeaturesFeatures• BenefitsBenefits• ConceptsConcepts• TechnologiesTechnologies

PeopleSoftPeopleSoft• Before AutomationBefore Automation• Project GoalsProject Goals• How it Works – Business ProcessHow it Works – Business Process• DemoDemo• How it Works - TechnicalHow it Works - Technical• MetricsMetrics

Questions and AnswersQuestions and Answers

SignetSignet

Minh Nguyen

7

What is Signet?

Privilege Management System• Web application• Toolkit/API• XML Schema

Open Source Project from NMI-EDIT Consortium

Based on Stanford’s Authority Manager

8

NMI-EDIT ConsortiumNMI-EDIT Consortium

• Comprises Internet2 and EDUCAUSE − NSF Middleware Initiative (NMI)-Enterprise and Desktop

Integration Technologies Consortium (EDIT)

• Funded in 2001 by NSF Middleware Initiative

• Researches and develops inter-institutional Identity and Access Management tools

• Guided by MACE – Middleware Architecture Committee for Education

− Group of R&E IT architects from US, Europe, and Australia

9

FeaturesFeatures

• Grant/Revoke Privileges

• Grant-only

• Distributed Delegation

• Rules-Based Conditions

• Proxy

• Grant to Groups

10

BenefitsBenefits

• Standard user interface for users to grant privileges

• Consistent, simplified policy definition via role-based privileges

• Improved visibility, understandability, and audit ability of privileges across the enterprise

• Reduces latency in access privileges lifecycle events (activating/deactivating)

11

Building Blocks - ConceptsBuilding Blocks - Concepts

• Function - things a person can do; what they are getting privileges for.

• Scope - organizational hierarchy governing distributed delegation

• Limits - qualifiers, constraints for a privilege.

• Permission - atomic units of control that map to specific access rules in systems.

12

Building Blocks – Concepts Building Blocks – Concepts (cont.)(cont.)

Condition

• Must be true to retain a privilege• Provides automatic revocation of privileges• Based on date, person’s status, affiliation,

etc.

Pre-requisite - pre-conditions that must be met to activate privileges, e.g., training

13

ExampleExample

By authority of the Dean grantor

principal investigators grantee (group/role)

who have completed training prerequisite

can approve purchases function

in the School of Medicine scope

up to $100,000 limit

until January 1, 2007

as long as a faculty member at…

conditions

14

TechnologiesTechnologies

• Java Language

• Servlet Container, e.g. Tomcat

• Struts MVC Framework

• Tiles for UI Customization

• Hibernate for Data Access Layer

15

ResourcesResources

• NMI-EDIT – http://www.nmi-edit.org

• MACE – http://middleware.internet2.edu/MACE

• Signet – http://middleware.internet2.edu/signet

PeopleSoft & Authority PeopleSoft & Authority ManagerManager

Kevin Dale

17

Before AutomationBefore Automation

• Totally Manual Process

• Email

• No Tracking

• Potential for Incorrect Assignment

• Delay in Assignment

• No Audit / Validation Process

18

Automation BenefitsAutomation Benefits

• Prerequisites – Enforcement

• Assignment Expiration

• Acting As

• Auto Revocation

- Identity ManagementLoss of Single Sign-On = Loss of PS Security

19

PeopleSoft - Project Goals PeopleSoft - Project Goals

• Assignments or changes made in authority manager update PeopleSoft directly.

• The process will no longer require manual intervention.

• Minimal changes to the Authority Manager user interface, Student Admin will no longer use limit data.

• Speed up the authority process. Assignments to PeopleSoft are made in near real time.

20

How it works – Business How it works – Business ProcessProcess1. Grantor inputs Assignment

2. Authority Sends Data to PS to update Security (Application Messaging)

3. Row Level / Data Permission Security is updated

4. Application Sends Security to Portal

Start DemoStart Demo

22

125 objects in project.125 objects in project.

30 Records

20 Fields

2 Translate Values

9 Pages

2 Menus

8 Components

24 Record PeopleCode

2 Process Definitions

8 SQL

2 Application Engine Programs

10 Application Engine Sections

1 Message Node

1 Message Channel

1 Message Definition

2 Subscription PeopleCode

2 Application Engine PeopleCode

1 Page PeopleCode

23

How it works – How it works –

XML from authority

Transformed (XLST)

Application Messaging

Message Definition (STF_USER_PROFILE)

PeopleCode

Security Gets Assigned

24

XML – XLST - XMLXML – XLST - XML XML snippetfrom Authority

Manager

XML snippetFrom XSLT

XML snippetfrom PS

25

Application MessagingApplication Messaging

26

MetricsMetrics

Volume

• On average 38 (includes HR, Student and Financials) new / changes to security assigned each day

Latency

• Events harvested every 10 minutes

• All updates completed within 1-2 minutes

End DemoEnd Demo

Questions?Questions?

29

ContactsContacts

Kevin DaleKevin Dale

Information Systems Analyst, Administrative SystemsInformation Systems Analyst, Administrative Systems

Stanford UniversityStanford University

E-mail: E-mail: kdale@stanford.edukdale@stanford.edu

Minh NguyenMinh Nguyen

Software Architect, Administrative SystemsSoftware Architect, Administrative Systems

Stanford UniversityStanford University

E-mail: E-mail: mnguyen@stanford.edumnguyen@stanford.edu

This presentation and all Alliance 2006 This presentation and all Alliance 2006 presentations are available for presentations are available for

download from the Conference Sitedownload from the Conference Site

Presentations from previous meetings are also availablePresentations from previous meetings are also available