CUNA Mutual Group Proprietary | Reproduction, Adaptation or Distribution Prohibited | © 2016 CUNA Mutual Group, All Rights Reserved.

HHA-1572 Move from IBM DataPower to IBM API Connect with Custom User Policies: Guidance from CUNA Mutual Group IBM InterConnect 2017 Conference

Bryon Kataoka – CTO iSOA Group Dmitry Dikavitski – Sr. Technology Integration Consultant

2

Speakers

Bryon Kataoka Dmitry Dikavitski

3

1

2

3

4

Agenda Solution Evolution Preserving the Investment

Need for API Connect

Custom Policies Rock

Tips, Tricks and Lessons Learned

4

Introduction to CUNA (pronounced Q-nah)

• CUNA Mutual Group and Application Development Environment – CUNA Mutual Group is the leading provider of insurance and financial services to

credit unions and their members worldwide. –  About 20 application development teams with 10 – 20 developers each. –  Technologies: Microsoft .NET (50%), Cloud Solutions like Salesforce, Ebix, Netsuite

(30%), IBM Mainframe (15%) and Others - Java WebSphere, Android, xCode, JavaScript (15%), DataPower, API Connect

– Multiple network zones –  24/7 operation in direct to consumer segment – Most access is managed through Windows identity and active directory groups

5

The iSOA Group

• Building the Foundation for Digital Innovation –  The iSOA Group helps clients optimize their IT investments in Digital

Innovation by building and utilizing Frameworks to: •  Build a strong platform foundation (DataPower and API Connect) •  Create a repeatable pattern for reuse and improved knowledge transfer •  Develop Custom User Policies to extend API Connect •  Assist with migration from DataPower Frameworks to API Connect •  See our slide at the end of the presentation or visit our pedestal #272

•  At CUNA Mutual Group we: 1.  Helped develop and implement the DataPower Frameworks 2.  Coordinated API Connect Digital Workshops to architect, plan and design 3.  Participated in the Pilot Development and implementation 4.  Created Custom User Policies 5.  Delivered API Connect Training 6.  Provide On-Demand Services for DataPower and API Connect

6

Enterprise Architecture Requirements

• Requirements –  Expose internal services externally to any 3rd party partner or customer –  Provide multiple endpoints to services to meet different consumer needs around

message, security, channel –  Expose file and MQ Series services as web services –  Expose only portions of a service (e.g. only expose quoting and not issuing to some

consumers) –  Be the proxy between consumer and provider to assist in reducing impact of change

7

The Need for API Management and Service Gateway

•  Two years ago… – Development teams were building their own API proxies in.NET –  Inconsistent security implementations, inconsistent integrations with the partners –  Lack of experience in API industry standards

• One year ago… – CUNA and iSOA built DMZ integration Framework layer on Datapower – Robust Framework with consistent and up-to-date security interfaces – Datapower team overwhelmed with projects

•  Today – Development teams can build and document their own APIs in API Connect

designer –  API Connect team provided building blocks for the advanced security and integration – Development team manage their own application logic in the integration layer

8

Existing Datapower Framework

•  Security – Windows Authentication over Kerberos –  401 challenge with Basic, Negotiate and Bearer tokens on single endpoint – Certificates over the SSL/TLS – Get credentials from the corporate vault

• Multiple environments •  Logging

– Custom Event to manage incidents and transaction logging –  SNMP – for integration with incident ticket system – NFS – for integration with the reporting solution

• Caching – Custom x-dp-cache-key based on JSON or SOAP payload

9

Framework Conceptual Diagram

10

Framework configuration file

11

Multi-Protocol Gateway Style Policy

12

Custom Policies Rock!

13

Custom User-defined Policies

• What are Custom User-defined Policies? – Defined externally from API Connect.

•  Could be security related •  Could be service related (like MQ)

–  You create and Import into an API Connect catalog for reuse –  Policy becomes available in an assembly in the Assembly editor

• Why we decided to use them: –  Added the needed additional security policies –  Set an established pattern for API developers to utilize –  Improved reuse of established patterns

14

Implementation using Custom Policies

15

7 Custom Policies

1.  Basic Auth Inbound Policy 2.  Basic Auth Outbound Policy 3.  Client Certificate Policy 4.  Kerberos Inbound Policy 5.  Kerberos Outbound Policy 6.  MQ Add Policy 7.  Retrieve Password Policy

16

Inbound and Outbound Kerberos Security Policies

•  Flow for Inbound Security –  API defines which security schemas are enabled on the single endpoint – Common code checks for the authorization header – throws 401 if missing – Custom policy takes in Active Directory authorization group as input parameter –  Performs authentication and authorization based on the authorization token

•  LDAP Load balancer – Needed an LDAP load balancer added to webapi XML manager to run LDAP queries – DataPower SOMA to the rescue –  Script to load all additional artifacts into APIMgmt domain

• Outbound Kerberos Security –  Pass in Kerberos properties – Generate SPNEGO token

17

Inbound Security

18

Outbound Security

19

Outbound Security – Processing Rule

20

Client Certificate over SSL Custom Policy

•  Flow – Can not configure client certs on API – all or nothing –  Setup additional domain with the listener on the secondary IP – Netscaler in the bridge mode – allows client certs – MPGW maps client cert to the AD account based on the configuration file and adds it

to the header – Generates hash of the account name and timestamp with the secret key attaches

hash to the header –  Sends call to the main API endpoint

• Client Certificate Custom Policy –  Takes Active Directory access group as an input – Checks hash for validity – Checks account against Active Directory group for authorization

21

Tips and Tricks

•  Auto-load of APIMgmt domain and custom domain with the script –  LDAP load balancers, MQ managers, key tabs, KDCs – enable custom policies – Custom events, logging targets – incident generations, custom reporting

• Custom domain for the additional functionality packaged as custom policies – Generic Cache, Password Retrieval, Client Certs, Web App Firewall (WAF)

• Gateway Script Custom Library –  Building blocks – generic code – Reuse of the existing code –  Enables to change code for all APIs

• Calling existing XSLTs from the gateway script policy –  Porting existing code with the minimal changes

22

Auto-load script example

23

Calling Common Code – GWScript example

24

Calling Common Code – XSLT example

25

Lessons Learned

• Debugging –  For the admins – in the DataPower probe follow “webapi-policy-invoke-gscript” rule –  Look at the context variables var://context/policy/fw/current-context –  Find the rule where it invokes backend call and look at the “Extension Trace” –  For the development teams we created a NFS log target and subscribed to all the

errors and the custom events • Community support

– Difficult to find others with similar situation –  IBM working on improving documentation

•  Looking at the code –  local:/isp/policy/apim.custom.js –  local:/isp/policy/apim.policy.restinvoke.js

26

Best Practices

• Utilize Custom Policies for reuse of needed policies •  Establish patterns to assist API developers • Create a logging mechanism for greater insight for developers •  If you have an established DataPower Framework, consider Custom User

Policies to help bridge from DataPower to API Connect • Use Source Code Management and scripting for DevOps • Work with someone who knows DataPower to ease the transition in creating

Custom User Policies

27

Q A &

28

PRESENTER

B R YO N K A TAO K A - C T O iSOA Group Building the Foundation of Digital Innovation 8 Keller St. Petaluma, CA 94952 bkataoka@isoagroup.com (707) 773-1198 office (707) 338-2274 mobile www.isoagroup.com

29

PRESENTER

D M I T R Y D I K AV I T S K I Sr Technology Integration Consultant CUNA Mutual Group Dmitry.Dikavitski@cunamutual.com 800.356.2644 , Ext. 665.3562

‹#›

Thank You!

For more information on Frameworks,  

or any other questions around

DataPower or API Connect please stop

by the iSOA Group Pedestal #272 in the

Concourse or contact us at:

contact@isoagroup.com.

31

iSOA Group

Secured Gateways: Providing secured, integrated and flexible connectivity for your enterprise

LifeCycle Solutions Supporting requirements across the IT lifecycle, including assessing business and technology requirements, successful deployment

API Management Delivering successful API management strategies and frameworks for developing innovative applications.

StandUP Services Assured success supporting the deployment technology solutions, leveraging iSOA Group expertise and proven best practices.

Hybrid Cloud Integration Developing a flexible framework that enables integration enterprise to the cloud, mobile and remote devices.

iSOA Accelerators Documented best practices, micro solutions, and custom extenders that enable quicker and more successful solution implementations.

Building a lasting foundation for the digital enterprise.

Certified in delivering proven, digitally innovative solutions.

www.cunamutual.com

33

Appendix Additional Custom Policies

34

MQ Add

• MQ Manager is pre-loaded to APIMgmt domain • Custom policy takes Queue name and Queue manager as input • Custom policy processing rule invokes XSLT to add payload to MQ • Custom policy rule formats custom response output based on MQMD headers

35

Retrieve Password Policy

•  Flow – Custom policy takes input parameters (safe name, object name, etc.) for accessing

corporate password vault –  Policy processing rule makes side call to the MPGW deployed in the custom domain –  Password retrieval MPGW makes call to the corporate password vault – Only calls for the specific APIs and inputs are allowed – based on the configuration –  Policy sets APIM context variable with the password from the response

•  This technique can be used to extend API Connect custom policies with the most advanced features available in IBM DataPower Gateway

• We used this method to enable generic cache function –  Built in cache does not work with the authorization headers –  Side call to custom domain with two MPGWs, first hosts cache, second sets cache

•  loopback if setting cache and throws an error if checking (no cache set in the first MPGW)