Process-based Identity & Access Management

Size: px
Start display at page:

Download "Process-based Identity & Access Management"

Transcription

1 Process-based Identity & Access Management Challenges in an extended enterprise model Dennis Attinger (Philips) Stuart Boardman (CGI) Dennis Attinger, Stuart Boardman Philips/CGI München, 24 April 2008

2 What you can expect from us Present the problem domain Compare solutions and architectural options Present the concept and solution approach Present 1 st phase of pilot and experiences Compare with alternative solution for the concept Future Phases Philips/CGI, DAT/SBO, München, 24 April

3 Assumptions and Principles The business paradigm is Extended Enterprise The design paradigm is Service Oriented Architecture. No assumptions on technology. Objective is: to realize the SOA promise of Agility to have Security as an integral part of Architecture and not as an after-thought Philips/CGI, DAT/SBO, München, 24 April

4 The Extended Enterprise The Extended Enterprise Partners Partners Suppliers Partners Customers Partners Agents Employees Suppliers Delivered By Services Capabilities Directed By Business Processes Philips/CGI, DAT/SBO, München, 24 April

5 SOA in the Real-World Service-Oriented Architecture as the architectural style: Promise of Agility: Mirror real-world activities Boundaryless Information Flow Re-use Design on Business Process level Implement by using Open Standards Philips/CGI, DAT/SBO, München, 24 April

6 Service-Oriented Architecture Customer Login/check PO creation Customer approval Process Order Release For Shipping Service HW: PC cards (on a PC-bus) SW: code with a defined function (on an Enterprise Service Bus) Business: activity (as part of a process) A service is a logical representation of a repeatable business activity that has a specified outcome Process Order Process Order Services are coupled with each other in an orchestrated Process chain Philips/CGI, DAT/SBO, München, 24 April

7 Service-Oriented Architecture: getting complex along the way Process Process 1 Process 1 Process 1 1 Process Process 2 Process 2 Process 2 2 User Role User 1 Role User 2 Role 1 Composite Composite 1 Composite 1 Composite 1 1 Composite Composite 2 Composite 2 Composite 2 2 Composite Composite n Composite n Composite n n User Role User 2 Role User 2 Role 2 Service Service 1 Service 1 Service 1 1 Service Service 2 Service 2 Service 2 2 Service Service n Service n Service n n User Role User n Role User n Role n Source: Rob Hailstone IDC Philips/CGI, DAT/SBO, München, 24 April

8 Extended Enterprise and SOA: Real-World Issues for IAM Two requirements in tension: Security view: Controlling who is actually entitled to use what Compliance view: Ensuring traceability and legitimacy of all transactions Current afterthought approaches: Security as an afterthought Each user and its credentials must be known to each service Architecture as an afterthought Multiple access mechanisms managing the same entities Philips/CGI, DAT/SBO, München, 24 April

9 Problem Statement If security or architecture is an afterthought these issues arise: Services are coupled to security functionality forget re-use Identities propagated to all access mechanisms forget agility Complexity performance, maintenance and governance risk can lead to security risks Managing growing numbers of identities across ecommerce, SOA and legacy apps Why give all users access rights to those back end systems? We re looking for: a solution that closely follows the A in SOA thinking a solution which is extensible (well adapted to change) Philips/CGI, DAT/SBO, München, 24 April

10 Line of Thinking Services are coupled with each other in an orchestrated Process chain.. Process view in SOA taken as conceptual starting point Promise of Agility largely based on a Processes focus 1. Identity propagation takes the service as the point of authorisation 2. Taking the process as the point of authorisation is the architectural approach Philips/CGI, DAT/SBO, München, 24 April

11 Process as the point of authorization Customer Login/check Identity flow PO creation Customer approval Process Order Release For Shipping Conceptual Solution Agent based, PEP/PDP solution Two identity contexts user and service Identities exist only in relevant contexts Access control rights driven No identity (or role) mapping required Process Order Audit compliance per transaction based on transaction characteristics Requires correlation across multiple logs Process Order Philips/CGI, DAT/SBO, München, 24 April

12 Service - Layering Partners Customers Suppliers Agents Business Process Services Business Process Services Business Services Task Oriented Business Services Infrastructure Services Utility Services Entity Oriented Business Services Application Services Application Services Component Services Enterprise Business Applications Philips/CGI, DAT/SBO, München, 24 April

13 Current Thinking: decoupled security architecture Policy Enforcement Point Portal Policy Decision Point Policy Enforcement Point Business service ID Assertion ID & Attribute Assertion Policy Enforcement Point Identity Management and Policy Management Application Service Application Service Policies can be changed centrally and rolled out without touching business logic Developing standards can be rolled out centrally Many ready to use agents (policy enforcement points) available Move security out of service design and into deployment Philips/CGI, DAT/SBO, München, 24 April

14 Component View of Service and IAM Partners Customers Suppliers Agents Audit Log Federation Id - Provider BPMS ESB Portal Policy Enforcement Point Business Process Services Policy Enforcement Point Authentication / Register / Authorization Assertion (token, roles, claims) Authorization, Insertion Policy Decision Point User Provisioning User Identity Context Business Services Audit Log Audit Log Correlation Enterprise Business Applications Application Services Service Identity Context Philips/CGI, DAT/SBO, München, 24 April

15 Component View Solution Partners Customers Suppliers Agents Federation Web Server Portal Server Policy Server Policy Enforcement Point User Provisioning Engine BPMS ESB Business Process Services Policy Decision Point Policy Administration Repository Business Services User Identity Context Enterprise Business Applications Application Services Service Identity Context Philips/CGI, DAT/SBO, München, 24 April

16 Correlation & Reporting Engine (SIM) Component View Solution Partners Customers Suppliers Agents Log Log Log Log Log BPMS ESB Web Server User id / token Portal Server Business Process Services Token, process id Token, process id Business Services Policy Server Policy Enforcement Point Policy Decision Point Policy Administration User Provisioning Engine Repository User Identity Context Token, process id, service id Log Log Enterprise Business Applications Application Services Service id Process id Service Identity Context Philips/CGI, DAT/SBO, München, 24 April

17 The Fulfillment Process Policy Enforcement Point User Id / token Token (user) Policy Decision Point User Id / token, Provider (service) Order Products (BPS) Token, Consumer (Service), Provider Capture Order (BS) Validate Order (BS) Log Place Order (BS) Correlator Manage Order (BS) Token, Consumer, Provider, Order # Order from LOB 1 (AS) Order from LOB 2 (AS) Consumer (Service) Id, Provider,Order # LOB Order # Consumer (Service) Id, Provider, Order # LOB Order # Consumer (Service) Id, LOB Order # Philips/CGI, DAT/SBO, München, 24 April

18 Deployment View Phase 1 Apache Agent (PEP) CA SOA Security Mgr JBoss PDP (App) Order Products Apache JCAPS BPM Agent (PEP) ESB Apache Agent (PEP) JBoss (WS) Place Order (WS) Validate Order (WS) Manage Order Apache HTTP Server CA SOA Security Manager JBOSS Application Server Sun JCAPS 5.3 CGI Octopus BAM (Correlation) SAP JBoss (WS) Order from LOB1 App SAP 1 JBoss (WS) Order from LOB2 App SAP 2 Philips/CGI, DAT/SBO, München, 24 April

19 An example log 16:16:22,750 INFO ( ) [PlaceOrderAction] place_order process started (date= ) [place_order: : ] 16:16:22,881 INFO (- place_order: : ) [PlaceOrderAction] Placing order... 16:16:22,911 INFO (- place_order: : ) [OrderPlacerWeb] Passing control to OrderValidator 16:16:22,931 INFO (- place_order: : ) [OrderValidatorWeb] Order has been validated 16:16:22,941 INFO (- place_order: : ) [OrderPlacerWeb] Passing control to OrderManager 16:16:23,462 INFO (- place_order: : ) [OrderManagerWeb] Managing order for 16:16:23,482 INFO (- place_order: : ) [OrderManagerWeb] Electric Shaver (1) 16:16:23,512 INFO (- place_order: : ) [OrderManagerWeb] Flat TV (LCD, 32") (1) 16:16:23,662 INFO (- place_order: : ) [OrderManagerWeb] to be sent to Herr Joe Bloggs at Niederkasseler Lohweg 175, Düsseldorf :16:23,662 INFO (- place_order: : ) [OrderManagerWeb] Passing control to LOB002 16:16:23,682 INFO (- place_order: : ) [OrderFromLOB2Web] Placing order with SAP 16:16:23,712 INFO (- place_order: : ) [SAP] Placing order for 16:16:23,712 INFO (- place_order: : ) [SAP] Electric Shaver (1) 16:16:23,712 INFO (- place_order: : ) [SAP] to be sent to Herr Joe Bloggs at Niederkasseler Lohweg 175, Düsseldorf :16:23,722 INFO (- place_order: : ) [OrderFromLOB2Web] Order successfully placed. Assigned Order No. dd9cb66d-29d2-4f17-81b8-5df84d2b :16:23,722 INFO (- place_order: : ) [OrderManagerWeb] Passing control to LOB001 16:16:23,732 INFO (- place_order: : ) [OrderFromLOB1Web] Placing order with SAP 16:16:23,752 INFO (- place_order: : ) [SAP] Placing order for 16:16:23,752 INFO (- place_order: : ) [SAP] Flat TV (LCD, 32") (1) 16:16:23,752 INFO (- place_order: : ) [SAP] to be sent to Herr Joe Bloggs at Niederkasseler Lohweg 175, Düsseldorf :16:23,762 INFO (- place_order: : ) [OrderFromLOB1Web] Order successfully placed. Assigned Order No. 5413d8 b8-b162-4f04-ae4f-ad73dcc95b16 16:16:23,762 INFO (- place_order: : ) [OrderManagerWeb] Order successfully managed. Assigned Order No. 83ae304d-39c cb8711a861 16:16:23,772 INFO (- place_order: : ) [PlaceOrderAction] Order has been placed (Order No.:83ae304d-39c cb8711a861) 16:16:23,772 INFO ( ) [PlaceOrderAction] place_order process terminated (date= ) [place_order: : ] Portal log file Services log file SAP log file Philips/CGI, DAT/SBO, München, 24 April

20 Technical aspects Process ID: place_order: :joebloggs HTTP; SOAP; WS-Security; WSDL stack Consumer identity in HTTP header Provider address in HTTP header Process ID in SOAP header PEP currently only inspects HTTP ESB requires proxy WSDL Introduction of BPEL pros and cons Philips/CGI, DAT/SBO, München, 24 April

21 Another Viewpoint Finance Sector Company Stricter view of user domain stops at Business Process Service All user management external identity provider created User management looks outward Possible collaboration with other enterprises Service to consumers Strongest possible Identity 2.0 approach using InfoCard Company specific scenario: Many external parties customers, partners, agents Existing federated governance No real Business Service layer (BPS -> AS -> legacy) But well adapted to changing business models Groenendael Philips/CGI, DAT/SBO, München, 24 April

22 Alternative Solution (NL Finance Co.) Identity Provider Partners Customers Suppliers Agents User Provisioning Engine Web Server Policy Enforcement Point Portal Server Policy Server Policy Decision Point User Identity Context Repository Business Process Services Policy Administration Policy Enforcement Point BPM/ESB Enterprise Business Applications Application Services Service Identity Context Philips/CGI, DAT/SBO, München, 24 April

23 Future Phases Phase 2 Introduce real SAP applications in place of the stubbed components. Enhance Services to ensure sufficient and correct information passed to (and received from) SAP Introduce a Correlation Engine. Phase 3 Implement a real ordering scenario with more services Enhance usability if necessary Implement BPMS Introduce a real portal Finalize configuration framework Phase 4 Stress testing scale up LDAP and transaction volume Philips/CGI, DAT/SBO, München, 24 April

24 Deployment View Phase 2 Apache Agent (PEP) CA SOA Security Mgr JBoss PDP (App) Order Products Apache JCAPS BPM Agent (PEP) (WS) Place Order ESB Apache Agent (PEP) JBoss (WS) Validate Order (WS) Manage Order CGI Octopus Correlation JBoss (WS) Order from LOB1 JBoss (WS) Order from LOB2 SAP LOB 1 SAP LOB 2 Philips/CGI, DAT/SBO, München, 24 April

25 Philips/CGI, DAT/SBO, München, 24 April