Central Person Registry ITS ITANA Architecture Review 10 November 2010

Central Person Registry

ITS ITANA Architecture Review

10 November 2010

Agenda

• Overview of Person Registry• Requirements• Data Model• Services Model• Service Providers• Production Implementation• Resources• Contact Information

Terms and Abbreviations

Abbreviation Definition

IAM Identity and Access Management

CPR Central Person Registry

FPS Friends of Penn State

CIDR Central ID Repository

CACTUS Central Accounts Coordination Tracking of User Services

IAP Identity Assurance Profile

SoR System of Record

RA Registration Authority

What is the Central Person Registry?

It’s the Foundation

of IAM

Current Person Registries

• At its simplest form, a person registry is a data store of user information

• Examples– Central ID Repository (CIDR)– Friends of Penn State (FPS)– Central Accounts Coordination Tracking of User

Services (CACTUS)– Integrated Student Information System (ISIS)– Integrated Business Information System (IBIS)– Many others

Central Person Registry

From The Identity and Access Management Final Report dated 2/18/2008

A centralized person registry is a single data store that combines and consolidates identity information currently stored in separate and non-integrated sources throughout the University.

Central Person Registry

Systems of Record

Registration Authorities

DatabaseWeb

Services

Service Providers

Data Views

Central Person Registry

CPR Data Flow - Interactive

Registration AuthorityApache Geronimo

ESB

Oracle 11i1. SOAP Request

5. SOAP Response

2. JDBC Request

3. JDBC ResponseSOAP Service

Service Provider

Service Provider

JMS R

eque

st

JMS R

espo

nse

1. RA makes request to CPR via SOAP call

2. Service validates information and makes JDBC request to the database.

3. Database responds to request via JDBC

4. Service determines which service providers need to be notified and does so via JMS

5. Services sends a SOAP response back to RA

JMS Request

JMS Response4.

CPR Data Flow - Batch

Batch Inputs

CPR Batch Processor Oracle 11i

1. Upload Request 2. SQL*Loader

JDBC Response

Service Provider

Service Provider

JMS R

eque

st

JMS R

espo

nse

1. Batch data is acquired from various sources and uploaded to the CPR batch processor.

2. Batch processor uses a combination of SQL*Loader and stored procedures to load the data.

3. Batch processor determines which service providers need to be notified and does so via JMS

JMS Request

JMS Response

3.

Requirement Sources

• Existing Registries– CACTUS, CIDR, FPS

• Regulations and Legislation• University Sources

– Survey– Interview Sessions– Use Cases

• External Sources

Regulations and Legislation

• University Policies– AD11 - University Policy on Confidentiality of Student Records

– AD19 - Use of Penn State Identification Number and Social Security Number

– AD20 - Computer and Network Security

– AD23 - Use of Institutional Data

– AD35 - University Archives and Records Management

– AD22 - Health Insurance Portability and Accountability Act (HIPAA)

• HEOA - Higher Education Opportunity Act

• Red Flag Rules

• PCI - Payment Card Industry

Data Model

• Design based on concepts derived from CACTUS, FPS and CIDR data models

• Guiding principles– The data model shall only store information related

to identity.– The data model shall store information necessary

for matching.– The data model shall store information necessary

for life cycle changes.

• Must support current functionality and include flexibility to change as needed

Data Model

• Contact information– Name(s), addresses, phones and E-Mail

addresses

• Identity Information– Digital identities (PSU ID and credentials)– Date of birth and gender

• Identity Assurance Profile Information• Affiliation Information

Service Model

• A Service-Oriented Architecture (SOA) • Web Services• SOAP• Enterprise Service Bus• JDBC and stored procedures• JMS

Service Model - SOA

• IAM will move to SOA from the world of batch processing and flat files

• SOA Guiding principals– Reuse, granularity, modularity, composability,

componentization and interoperability.– Standards-compliance– Services identification and categorization,

provisioning and delivery, and monitoring and tracking.

Service Model - SOA

• Important features of SOA for IAM:– Standardized service contract between provider

and consumer.– Service reusability - services are developed as

building blocks in which logic can be reused by other services.

– Service abstraction - service logic is hidden from the outside world.

Service Model - SOAP

• SOAP supports a generic transport (not just HTTP)

• SOAP uses a formal contract between provider and consumer

• WS-*

Service Model - SOAP

• WS-Security– Supports SSL– Standard implementation of data integrity and data

privacy

• WS-AtomicTransaction– ACID (atomic, consistency, isolation, durability)

transactions

• WS-ReliableMessaging– SOAP has successful/retry logic built in and

provides end-to-end reliability even through SOAP intermediaries.

Service Model - Enterprise Service Bus

• Standard integration platform• Multiple event-driven messaging modalities• Provides a set of core services:

– transformation– routing– proxy– logging– Apache CXF framework for SOAP– Automatic WSDL generation

• Ease the burden of integration of large number of heterogeneous systems

Service Model - Enterprise Service Bus

• Apache Geronimo – http://geronimo.apache.org/

JDBC and Stored Procedures

• JDBC (Java Database Connectivity) API– Industry standard for database-independent

connectivity between Java and SQL databases– For IAM purposes JDBC is only used to call stored

procedures.– Geronimo provides a database connection pools

• Why Stored Procedures?– Enables the encapsulation of complex database

logic into a highly optimized database object.– Precompiled enables faster performance than in-

line Java code.

Java Message Service (JMS)

• Message Oriented Middleware (MOM) API for sending messages between two or more clients.

• Supports two models– Point to point (queuing)

• Will be used to communicate with specific service providers to request actions, for example provision authentication for a user.

– Publish and subscribe• IAM will provide a facility where entities can subscribe to

messages related to user information changes.

Service Model

• Authentication and Authorization– Spring framework or similar framework will be

used for authentication.– Authorization will be performed using a policy

engine like Drools.

Service Model

• All services return a service code and status message indicating the result of executing the service.

• All service calls are logged for auditing purposes.

• Messages between a service and service provider(s) can be queued if there are any failures.

Service Model

• The initial set of IAM services will be centered around the CPR and will include:– Applications and system access to the CPR information.– Management services for maintaining:

• Identities, contact information, affiliations, PSU IDs, Penn State Access Account user ids, sponsored accounts, identity assurance profiles.

– Matching services (with the goal of minimizing duplicate identities in central systems).

– Address validation services.

• Additional IAM services will be developed as the project matures

Service Providers

• Service provider– An entity that provides services to other entities.

– Examples: authentication, LDAP and so on.

• Communications between SOAP services and a service provider will be done using Java Messaging Service (JMS).– JMS API is a Java Message Oriented Middleware (MOM)

API for sending messages between two or more clients

– JMS queuing available from Geronimo is Apache’s ActiveMQ.

Production Implementation

• All of the services are being developed using Java.

• Services interact with the database using JDBC.

• All of the database manipulation is done with Oracle PL/SQL stored procedures.

• All Java services are tested using JUnit 4.0 test cases and test coverage of at least 85% is required.

• Documentation is done using JavaDoc.

References

• IAM Community Website https://iam.psu.edu/

• IAM Developer Site https://iam.psu.edu/developer/

• Apache Geronimo http://geronimo.apache.org/

Contact Information

• IAM Technical Architect Group E-Mail: iam@psu.edu• Renee Shuey, Principal Lead - IAM, rshuey@psu.edu • Jimmy Vuccolo, IAM TAG Manager, jvuccolo@psu

.edu • Hash Tag #PennStateIAM

– Del.icio.us

– Twitter

– Facebook

– YouTube