Unlocking Data Silos Securely: Standards‑Based APIs for Regulated Sectors by Erandi #apidaysindia

So very good morning to all of you. I have two sides to balance. I'll try my best to do it. I'm Mandi. I'm a solutions architect at WSO2. I've been in the industry around 10 years. And as a trusted advisor solutions architect, I predominantly work with North American customers of WSO2. So my expertise comes through API management and integration and I'm very happy to share my experience knowledge with this audience as well with the topic of how we can expose this critical data securely in these domains. Okay. So this is the agenda. I covered the introduction. So I will start with the problem landscape and I will explain the solution the world has come up with and then the implementation. We have the problem we have the solution how we can implement using APIs and then of course the modernization is a mindset change why we should do it and the benefits real world experience that I am dealing withmemes to fortune 100 fortune 500 companies today in the North American market. So I'll share my experience and I will close the session with the takeaway. So stay with me. Let's start with the problem landscape. How many of you have watched this animation movie? A lot of you. So it's a really cool animation. Go watch it if you haven't. So why I put it here? Just to give you a basic understanding. The dragon scroll Panda is holding in his hand as the legendary it contains really critical valuable information. But as for the legendary, no matter how other warriors are capable of, they can't access this piece of information. Only the desired person with the right access can get that information. If it's available, that person can be the most powerful person on planet. So that's the bottom story line, right? So let me get into my talk with that baseline. So if you come into the sectors like healthcare, banking and even the government sectors like national security, defense, they hold really really critical information. For an example, if we take healthcare sector, basically the data they deal with either with the birth or with the death that amount criticality they handle. Same goes with the banking sector. If you work with the bank, you might have experience. It's like one of the most inconvenient experience you have to go through because of the criticality of the information. They can't handle that data and expose it to third parties in the way the other sectors do like hospitality, transportation. They provide a really cool experience to all of our folks out there with third party applications. But these sectors they cannot do that because of the criticality of the data. But at the result we are experiencing compromised care quality. If you go into a hospital for an example I am originally from Sri Lanka. In my country uh the health care sector is public. But if you take a country like United States their health care sector is like private. If you go from one hospital to the other hospital most of the times with the patient there are 10 years history of records that is not going with them. So they get treated without knowing the 10 years of history because it's not easy to expose this data to all of the parties. Same comes with the financial sector if you go from bank to bank manual work is still there. And if you have experienced this, this is really incontinential experience and uh because data is not available of course the limited innovation will come into the picture. Even in the government sectors they can't do actual innovation because data is not available. This is not restricted to only an organization level. Even inside the same organization between two departments they face this problem. one department doesn't like to expose data to other department. So that's natural. So this is where we are today or most of the cases this is where we were in some countries few years back. So that's why world came up with a solution. Yes, we have critical data in silos in regulated sectors but we can't expose it through APIs in the same way we do with other sectors. So that's where these mandates, standards, regulations came into the picture. So as a result, if we can expose these data with standards and regulations, as the result of course, lifesaving decisions can be made very quicker and uh unified customer experience will be there and it will expose the new expansions. If you take a healthcare sector, private sector, so they would love to get into new expansions because they are revenuedriven, right? and new researchers innovations will come into the picture if this data is available. So that's the solution. So let me go bit into theory because we need to understand bit of terminology and might be a bit boring. I would like to uh keep it at high level as soon as possible. So when it come to sector specific standards and regulations like I said today's world is enforcing expose these data securely that is how they mandate it and for that they have bring the standards and regulations especially with these security levels authentication and authorization for an example when it comes to healthcare fire is the standard that we are going with in the world today and when it comes to fintech PSD2, open banking, open finance, financial grade APIs, ISO standards, these are like standards we have to follow. And when it comes to government and regulated sectors, rolebased access control, attributes based access control, policy based access controls, these are regulations or the standards these sectors will follow to securely expose. So fire is specifically for the healthcare. So as the name says it's fast healthcare interoperability resources. So this is a global standard and this is designed to exchange healthcare information securely this electronic data and this was developed by HS7. HS7 is like the previous standard we had but it was complex. HS7 had different versions and CDF formats. because of the complexity and the hardness to implement it, they came up with fire. It is rest based and uh it is on HTTP and the request responses are JSON based and it is secured through O2. So it is widely uh adoption we can see in the market and uh when it comes to healthcare there are different uh what do you call these u interested parties in this sector like members providers that means hospitals payers like insurance companies and uh electronic systems. So these are the parties we need to interoperably exchange data. So fire rest APIs help to get that done. And uh when it comes to our vendor market, so vendor market is growing on supporting to them. For an example, the company uh I am from WSO2. We have uh specifically built connectors to connect with these EHR EMR systems and we have tools built where we can convert these old formats HL7 kind of formats into fire data format. We have tools built to that. So likewise I know other vendors are also providing this because this is a mandate or a force that government is making towards the healthcare sector. uh we have to take that path and vendors are supporting through that as well right so a similar example I will give for the fintech sector so let's think it's like you need to invest in stock market right in that case let's say you have a third party application a very cool application you get all the status about the uh latest updates of the stock market the prices and those stuff but when you want to purchase a stock you definitely have to deal it with the money, right? You have to integrate your banking account or your uh merchants cards and those stuff. So maybe some years back this was not feasible at all because banks they didn't want to expose information but by now we have seen they are seamlessly connecting. How do they do that? If you see check this picture the right side to yours you can see in the bank internal network you have the core banking systems and such as like account opening transactions that you maintain and then the you have internal payment services such as financial services, credit card services. So these kind of core services uh they want to expose it to third party applications. So that is where this open banking standard APIs comes. So in our case we do support these kind of solutions using WS2 API manager and security parties supported through WS2 identity server. Likewise we support standardbased API securely exposed into these third party applications and uh little bit of terminology we need to understand here. So regulations came into the picture first. So PSD2 is a well-known term if you are working in the finance sector. Actually it got initiated from the Europe region and uh when it comes to other regions like u Australia, UK they had their own versions of it and this is a legal regulatory uh layer that we have and it got evolved as a framework we have the open banking open finance by now it's wildly getting adopted for the security layer we can use O2C these are mandates that they have to follow and for the data and messaging different ISO standards uh come into the picture and even world was following swift but now we have to migrate into the uh ISO 2022 with the mandate deadline as well. So these are like terminology when it comes to this domain and when it comes to the government sector or any other regulated sector this is can be commonly used fine grain access control. So basically rolebased access control you can grant access based on roles and attribute based that basically means you can uh grant the access based on different attributes like emails and user address and so on and policy based access control. If you need to go one level deeper that basically means you can write conditions and in that condition you can do different validations the different policies and attach them and make decisions based on that. That is where this opensource open policy agent or the OPA come into the picture. It is it is a engine that you can write policies and enforce them. So how governments and regulatory sectors can use this? They can apply OPA kind of or the rolebased access kind of limits in the gateway layer. If you want to make decisions or more granular decisions, you can talk to decision point and take that decision. So that's how u these regulator sectors they are enforced to follow these security standards and expose their APIs. Yeah. So that's like the standards we have to follow when exposing data. So when it come to the solution implementation so if you see this picture this is the common pattern that we have in any organization. So if you start from the uh middle part systems of record in any organization we have the systems of record that can be legacy systems, databases and so on. Then these records we have to access through services. These services also can be modeled as domains. So these are the ones we call as domain based APIs and these APIs are mostly consumed through internal services and domain based APIs will be consumed through experience layer. So these experience APIs are the ones actually consumed by the digital applications. So this is like the layer in any organization if you are going through proper API program we have to follow. So when it come to our picture also we have the application this can be mobile application of a bank or healthare system. So these applications will consume experience APIs and this this is the layer where we impose standards and regulations and that layer will connect with the domain APIs. This can be rest, graph, QL, gRPC kind of an API and it will connect to the microservices layer or the services and from that layer we can consume the systems of record like databases and so on and uh in the experience layer and domain based layer we have to do the proper API management that is where the API governance API security analytics full life cycle management contract management these are important For an example, if you need to do the API governance, API analytics, security, we can support it through uh vendor support like API manager gateway and so on. Yeah. So that's basically about theory part. I covered the problem solution and this is how you can implement it. But implementing it or making that change is really hard. Modernization is always a mindset and it's not very easy when it comes to the sectors like this. But this is a very famous quote uh by Charles Darin. What he says is it is not the strongest of the species that survives nor the most intelligent that survives. It is the one that is the most adaptable to change will survive. So no matter what how hard it is uh if you can't make that change in these sectors they will not survive. So why we need to do that is we need to treat the modernization as a strategic mindset shift and as the benefits organizations citizens we will face life saving system we will have that experience and organizations will have the revenue growth unified customer experience and the research and inversions will be improved. So these are like uh very high level benefits but we have tons of benefits by following this and I will quickly cover real world experience factor as well by working with this. >> Yeah. So uh when it comes to the real world experience this is a really hard move that is what we have seen in the industry because uh the first resistance usually come through the internal uh community or the internal workers because this is a hard move and this risk is always associated with this. So they do not like to uh expose the critical data and changes migrations usually they are very expensive. So this is a hard move but if you climb that mountain the top view will be really beautiful. So usually what countries are doing is they forced to adhere to these compliances these regulations and it it comes as a mandate and organizations internally has to evaluate the return of investment. So basically what they do is they evaluate 5 to 10 years of the return of investment and they make that decision. So that's what we have seen in the industry. Yeah. So I'm almost done and I would like to uh close this again uh with the movie scene. So I'm pretty sure you have watched this movie. Sorry if you haven't watched it, you are missing something. Go watch it. It's an amazing Hindi movie. So in this scene, the professor explains Amir Khan why this pen was invented. Basically uh this they have in invested a lot on uh innovating this pen. This was designed to take it to the space travels. Why? Because the ballpoint pen it couldn't do that job. If that ballpoint pen was taken to the space with the gravity because the gravity imbalance we don't have gravity there. Uh it can't you they can't use it for the right. So that is why this pen was invented. So likewise we have to use the right tool. It can be expensive but if you use the right tool we can get the job done. So I would like to close my talk with the takeaway. Use the right tool which is standards and regulations based APIs for these critical sectors and expose the critical data in regulated sectors with with that we will be able to have very powerful systems and cool experiences. Thank you and uh if there are any questions I would like to take. >> Yes. Uh thanks Arandi for the wonderful session and we impressed with lot of codes today. >> Thank you. >> Any questions? >> So actually I have one question. So as you are an architect right? So basically uh in our organization or any organization consider there are too many legacy APIs and so basically there are internal APIs as well as external API. Is it mandatory to use HTTPS for even internal APIs? It is not actually it really depends on the uh the audience you are exposing these APIs but what we have seen in the uh industry even with large organizations some internal APIs let's say even APIs like gRPC APIs they use without authentication but that's okay but as a practice if you can expose uh impose security in every layer that is the best practice >> okay so uh consider if we have like a composite composite controls like consider I'm going to place a load balancer internally I'm going to use basically like uh without HTTPS but load balancer will handle this HTTPS and HTTP termination >> yeah but from the load balance to the API uh there's no security right >> yeah internal there is no security but externally we'll use load balancer to terminate the SSL part >> yeah so from that yes you can uh save your all the internals with the outside traffic but uh then again we have this concept zero trust we we have to basically that the right thing is we have to secure each and every layer we don't trust from where this topic comes for an example I can say uh we have in our company we have the SAS platform uh in SAS platform from one service to the other service we can communicate internally so there can be hacks one user can get into find out some flow create a high traffic from one service to other service but the traffic goes internally but still they can aggregate the traffic. So at that kind of we have to ideally secure it make the throttling part of it even for the internals. Yeah. Any more questions? >> All right. Thanks so much