CIT Seminar SeriesISC Forum

1

SOA 101Ian Sebright

SOA Technical Lead

2

So what is SOA?

• Service Oriented Architecture (SOA) is an IT architecture methodology that focuses on providing a flexible set of services rather than a single application. – Reusable– Service-based– Based on true business needs

3

The Web Service ApproachFunctional Building Blocks

4

SOA Design Principles• Abstraction - Services have a clear

business context• Standardized Service Contract-

Services comply with same contract standards

• Encapsulation - Only consumers know what’s in the contract

• Discoverability - Service metadata are managed in order to be available as needed (role played by the ISC)

• Reusability - Some services are agnostic

• Granularity- Service interfaces balance reusability and business context

• Autonomy - Service implementations control their runtime environment

• Loose Coupling - From consumers and the environment

• Statelessness - Service implementations defer management of state information whenever possible

• Composability -Services are effective in the aggregate, regardless of the complexity of the compositions

5

6

The Lego MetaphorWhat NIH Wants From IT

• Interoperability• Reliability• Composability• Loose-coupling• Reusability

6

7

NIH needs your business services/processes

Give us your old …

We can make it NEW

…and reusable

7

8

Drivers for SOA

• Reuse of software services across the enterprise

• Business flexibility

• Ease of integration

• Speed of integration

8

SOA Case StudyNIH Business Systems

Jeff Zhong, NBS SOA Architect

9

Four Years and Five Successful SOA projects

at NBS

10

NBS SOA Overview

• Started SOA implementation in 2007• NBS program holistic approach for

entire enterprise-level integrations• Followed NIH enterprise architecture

(EA) and SOA guiding principles• Utilized the existing NIH CIT/ISC and

NBS infrastructures

11

Successful NBS SOA Implementations

• eTravel– the first successful SOA implementation in eTravel

among all Federal agencies (average 8,000 transactions/month)

• Federal Acquisition (two contracts)– the first NBS SOA implementation (average 20,000

transactions/month)• NIH annual grant commitments and obligations

– (average $20-25 billion US/year) • Patient Travel

– Expense reimbursement system integration (average 3,000 transactions/month)

12

2004: NBS conducted a 90-day study on how to integrate with Federal eTravel services and developed a prototype using Apache Axis software

2007: NIH CIO adopted SOA; NIH Integration Services Center (ISC) announced initial availability of SOA hardware, software and governance based on TIBCO

2007: NBS developed integration architecture for all future integration projects, and decided to use ISC TIBCO and NBS Oracle products

2007: NBS Requisition service went live with one Institute 2008: NBS eTravel phase I went live with Purchase Order, Voucher

services 2009: NBS eTravel phase II went live with more Institutes and

Centers (ICs) 2009: NBS Requisition service enhanced and usage expanded to

26 ICs 2010: NBS Grant Integration went live with enhanced Funds

Check service 2010: NBS Clinical Center Patient Expense Module went live with

significant reuse of Purchase Order, Voucher, and Funds Check services

Major Milestones of NBS SOA Implementation

14

Analyze strategic goals and business

needs

Leverage existing or build new services

Identify options, risks,

tradeoffs

Factor in non-functional requirements

Reuse or create design

patterns

Update/add to reusable services

framework

Baseline design for a

services-based project

Develop appropriate test plans

Implement to production

Understand strategic goals and analyze business needs

Make decisions based upon SOA principles

Embed principles into the design patterns

Reuse and iteratively enhance SOA framework

Be flexible and agile

with SOA principles

Applying SOA Principles to Formulate a Solution

Transactional Services Purchase Order (Create,

Amend, Cancel) Account Payables Account Receivables General Ledger Traveler Profile (Create,

Update, Remove) Document

Certification/Approval

Quality Reusable Services For High Valued Systems

Lookup Services Funds Check Project

Accounting Lookup

Patient Profile Lookup

Vendor Lookup Expenditure

Organization

16

NIH Automated Process

1. Profile automatically synchronized via web services

2. User accounts automatically generated when profile is created

3. Single sign-on automatically configured when account is created

4. User logs into NIH portal, clicks a link and goes directly to eTravel service

Non-NIH Manual Process1. Administrator creates user

profile2. User self-registers and creates

Login ID and password3. Administrator provides the user

an account token4. User logs in, links the self-

created user account with the administrator-created profile via account token

5. User configures challenge questions

6. Now user can login to eTravel Service

Streamlined Traveler Profile Management

Reduced Time to Services and Development Costs Reduce development time Patient Module - A web-based

solution completed within 12 weeks from requirements to deployment

Reduced duplicated systems and data inconsistencies

Reduced Development and Maintenance Costs Projected savings: ~ $2.18M over five years for Patient Module

service fees Purchase Order Module avoids double data entry, saves an

estimated $1M annually and won 2010 HHS Innovation award

Increased Service Quality 99% accurate first-time transaction processing resulting in a

reduction of service desk tickets Avoided manual data consolidation from batch processes

Reduced Costs and Increased Service Quality

Pure IT Project, No Support From Business SOA projects led and services owned by business owners SOA infrastructure supported by IT

Service Overdose and Too Many Services For system integration, services were used as system

interfaces For software composition, services are encapsulated as APIs

Vendor Defines Architecture Independent architecture design and vendor products

selected from Gartner group Separate PMO from development contractor to avoid conflict

of interests

No Governance Results in Duplicate Services Enterprise Architecture compliance

SOA Implementation Risks and Mitigations

SOA projects with Executive Sponsorship from

NIH Deputy Director for Management /Chief Financial Officer

Director, NBS Program

Solution Architecture was reviewed and supported by:

NIH CIO Office, Chief Architect Office, and Integration Services Center

Members from OASIS, OMG, and IAC Enterprise Architecture SIG

NBS Travel Team, Web Service Team, Healthier Financial Management Initiatives Team, Infrastructure Team

Some slides were presented to NIH EATS in February 2011 and the 4th International SOA Symposium and the 3th Cloud Computing Symposium in April 2011.

Acknowledgements

SOA Q&A

20

iTrust Technical OverviewChris Leggett

iTrust Technical Lead

22

Enterprise Authentication aka “iTrust”

– NIH iTrust• Single Sign-On (SSO)• Federated authentication service

– NIH Login – internal users – NIH Federated Login – external users

23

Supported Credentials

User Name/Password

PIV Card

NIH ADNIH External ADeRA Commons OIDHHS OPDIV via IAM@HHS

HHS PIV

24

Agent Deployment Model

25

Agent-less Deployment Model

26

Federation Support

• SAML 1.1• SAML 2.0• OpenID 2.0 **

27

Determining Who to Trust

Trust framework provider

General Services Administration

Universities U.S. Government

websites

Assessors& auditors

Disputeresolvers

User

28

Level of Assurance

Supported Credential

LOA Example

OpenID 1 Google assertion

SAML 2.0 1-3 JHU assertion

Username / password 1-2 NIH AD

PIV Card 4 HHS PIV card authentication

29

Federation Deployment Model

30

Another Fed Deployment Model(Internal ADFS)

31

Upcoming Changes

• SiteMinder R12 upgrade• eRA integration and federation

support• New governance model

eVIP Case StudyMatt Tebo

iTrust Architect

eVIP Problem Statement

• Users from outside NIH need access to NBS systems in order to conduct business

• To provide this capability, NIH must– Conduct identity proofing– Issue and maintain external credentials

• This process is manual, inefficient and costly

eVIP Challenge• To automate or outsource identity

proofing• To leverage external user’s existing

credentialsAnd while we’re at it

• Improve security• Increase efficiency• Protect privacy

34

Solution Components• Think Evite® for a system, not a party• Comprised of 3 primary components

Invitation Service•Application owner creates and addresses invitation•System provides: verification code, automatic reminders, auditing, & notification capability

Registration Service• Landing page for invitation

recipient• Presents list of credential

providers• Links credential to NIH account• Validates verification code• Provides interface to id

proofingProvisioning Service

•Pushes credential to enterprise LDAP

Solution User Flow

36

Solution User Flow

1.Application owner creates an invitation (email) inviting external user to application– System notifies app owner when invitation is sent– System generates secret code and provides it to app owner– Invitation includes link to NIH landing page

2.Invitee receives invitation and clicks link to NIH landing page3.Invitee selects a credential provider from list on landing page

– Credential providers may include PayPal, SAFE Bio, etc.– iTrust forwards invitee to credential provider to authenticate– Invitee provides secret code

4.The system verifies invitee’s credential and secret code 5.The system extracts attributes (e.g. DUNS#) and links

credential to local account

Solution Advantages• Outsource identity proofing

– Paypal verifies employment– SAFE Bio Pharma

• Leverage existing credentials

Credential Types•PIV-I•SAML, OpenID, Oauth

Credential Providers•PayPal•SAFE Biopharma•Others

iTrust Q&A

39

http://isc.nih.gov

40