1. CIT Seminar Series ISC Forum 1

2. SOA 101 Ian Sebright SOA Technical Lead 2

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

4. The Web Service Approach Functional Building Blocks 4

5. SOA Design Principles Abstraction - Services have a clear business context Standardized Service Contract- Services comply with same contract standards Encapsulation - Only consumers know whats 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. 6 The Lego Metaphor What NIH Wants From IT Interoperability Reliability Composability Loose-coupling Reusability 6

7. 7 NIH needs your business services/processes Give us your old … We can make it NEW …and reusable 7

8. 8 Drivers for SOA Reuse of software services across the enterprise Business flexibility Ease of integration Speed of integration 8

9. SOA Case Study NIH Business Systems Jeff Zhong, NBS SOA Architect 9

10. Four Years and Five Successful SOA projects at NBS 10

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

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

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

15. 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. 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 Process 1.Administrator creates user profile 2.User self-registers and creates Login ID and password 3.Administrator provides the user an account token 4.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

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

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

19. 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 4 th International SOA Symposium and the 3th Cloud Computing Symposium in April 2011. Acknowledgements

20. SOA Q&A 20

21. iTrust Technical Overview Chris 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 22

23. Supported Credentials 23 User Name/Password PIV Card NIH AD NIH External AD eRA Commons OID HHS OPDIV via IAM@HHS HHS PIV

24. 24 Agent Deployment Model

25. 25 Agent-less Deployment Model

26. Federation Support SAML 1.1 SAML 2.0 OpenID 2.0 ** 26

27. 27 Determining Who to Trust Trust framework provider General Services Administration Universities U.S. Government websites Assessors & auditors Dispute resolvers User

28. Level of Assurance Supported CredentialLOAExample OpenID1Google assertion SAML 2.01-3JHU assertion Username / password1-2NIH AD PIV Card4HHS PIV card authentication 28

29. 29 Federation Deployment Model

30. 30 Another Fed Deployment Model (Internal ADFS)

31. Upcoming Changes SiteMinder R12 upgrade eRA integration and federation support New governance model 31

32. eVIP Case Study Matt Tebo iTrust Architect

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

34. eVIP Challenge To automate or outsource identity proofing To leverage external users existing credentials And while were at it Improve security Increase efficiency Protect privacy 34

35. 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 proofing Provisioning Service Pushes credential to enterprise LDAP

36. Solution User Flow 36

37. 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 page 3.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 invitees credential and secret code 5.The system extracts attributes (e.g. DUNS#) and links credential to local account

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

39. iTrust Q&A 39

40. http://isc.nih.gov 40