Tag: Mobile

mobileJoin us in the next installment in the MuleSoft webinar series as we talk about how to becoming a mobile enterprise.

Once a supplementary channel for the enterprise, mobile is now quickly becoming the primary channel for delivering business critical information and experiences to partners, customers and employees. Join Sarvesh Jagannivas, VP of Product Marketing at MuleSoft, and Uri Sarid, CTO at MuleSoft in, “The Path to Becoming a Mobile Enterprise” as they discuss the mobile enterprise opportunity and the biggest challenges preventing enterprise from a successful mobile delivery.

Register for the webinar:

  • Learn why mobile applications are the new imperative for the enterprise

Financial services information technology (IT) has transformed from order taker to strategic business partner. As part of this transformation, IT organizations are finding they must address key challenges with legacy modernization, data management and digital transformation.

MuleSoft has launched a three-part white paper series discussing these challenges and how financial institutions are overcoming them. In the first installment in our Connected Financial Institution white paper series, we discussed how aging back office systems, operational effectiveness and open source adoption are driving legacy modernization initiatives across the financial services industry. The second installment in the series discusses key data management challenges facing firms including an ever-evolving regulatory compliance landscape, deepening customer relationships with a 360-degree view, and improving data driven decision making.

reza.shafii on Thursday, January 3, 2013

How to Protect Your APIs with OAuth

0

On this 10th ‘Day of Christmas’ Mule blog post, we tackle an increasingly important question in the world of APIs: Presume that you would like to create a remote API (which perhaps exposes some legacy business logic) for access by internal and/or external clients. How can you make sure that access to your API is protected in such a way that:

A) Only clients that you trust can access them;
B) Those clients can access your API through the explicit authorization of their end-users; and
C) The end-users can be authenticated with a central entity, *withouth* having to share their credentials with your API’s clients.