Scenario: Externally exposed API, connects to multiple backed Dbs. Multiple customers can use the API, they obviously should only have access to their data. In the past this is done by separate accounts for each customer/user, and consequently each account would need setting up in each of the backend systems with the correct authorities.
Problem: I want to use Azure APIM. I don't want the extra maintenance for each user in both the Azure APIM and the backend Dbs. I was wondering if anyone has any thoughts or cases where they accomplished this in a different way. Also the API may be built with access via one account with all access to tables.
I'm sure there are different ways to approach this but a common way I believe to do this would be using Application Roles.
I don't believe this is really dependent on Azure APIM as such, but you can leverage OAuth 2.0 support to pre-authorize requests and in your backend, depending on the claims present in the token passed, you can allow/deny access to the data.
You backend would usually authenticate to the different DBs as itself with full access to all data and your backend would be tasked with making sure only people with the right claims can access the data.
In order to use an API the user/customer has to register with the Developer Portal and get a Subscription to a given API and the associated key. So you have to authenticate them. When you publish APIs through Azure API Management, it's easy and common to secure access to those APIs by using subscription keys. Client applications that need to consume the published APIs must include a valid subscription key in HTTP requests when they make calls to those APIs. https://learn.microsoft.com/en-us/azure/api-management/api-management-subscriptions
The Developer Portal supports different authentication mechanisms including Azure AD. So if you plan to use Azure AD for your authentication for both portals you will need to configure it accordingly. https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-aad
Related
We are working on a web application that connects to BIM360 using 3-Legged authentication. We have created an app in Autodesk Forge that users can connect through a BIM360 Custom Integration.
We are considering using 1 Forge application with multiple BIM360 Custom Integrations, but we are not sure if this is the best approach. The alternative is to have 1 Forge app per BIM360 custom integration.
Our main concern is data security. We think this approach is correct, but we would like to check with you and get your thoughts. Is this a safe and correct way to implement this authentication workflow in this type of scenario?
I would appreciate any guidance based on your experience.
You can use both approaches.
With one app for each BIM 360/ACC hub, the apps would be completely isolated, though it will require extra work to manage all of them individually. Currently, we don't have API to handle apps creation or activation/deactivation of services. Even with one app for each hub, you'll still need to ensure you're not exposing too much data to the wrong user. That can be avoided by using the 3-legged authentication.
With one app for many hubs, you can ensure the users are accessing only their data by limiting your application to always use 3-Legged authentication.
You can refer to the blog posts below for recommendations:
https://aps.autodesk.com/blog/security-recommendations-bim-360-app-developers
https://aps.autodesk.com/blog/security-recommendations-bim-360-app-developers-select-account
I'm about to implement a web application (back office for an existing app.) using the ASP.NET Core framework. At the moment I'm thinking about on how will I authenticate the user. The main database is using MySQL (not supported on this framework), so I will access the database troughout an existing PHP SOAP API.
Is there any way to implement a token based (OAuth) authentication knowing that the data access will be done trough a SOAP API ?
You can take a look IdentityServer3 in combination with the default OpenID middleware. You can completely separate the authentication logic from your application. Your application will trust the tokens generated by the identity server. The same as signin in with facebook/google/linkedin accounts etc.. using your own secure ticket provider. Identity Server supports customization so you can use the datastore of your choice. It is also possible to use your identity server for a various set of applications as long as they are "known" by your identity server. Definitely worth the investigation if you ask me.
https://github.com/IdentityServer/IdentityServer3
I am newbie with CAS Server, I found it is a single sign on server between different application in terms of technology like php, .net & java. I explore it but even though there are some questions yet not clear. Before ask my doubt, I tell what am I trying to achieve?
I am using a gwt based application, Now for some of the features, development is in a php technology. It should get some session data from existing java application. another approach to customize CAS like integrate a web service layer for authorization, instead of using its existing like query to db.
The doubts are:
1) Can I share a session data between Java & php application using CAS?
2) is there any security issue while passing a data using CAS server?
Thanks in Advance.
Sharing session data accross application can be addressed by mechanisms not linked to CAS. Though, when authentication occurs in CAS server, user data are retrieved from various data sources and these user data can be pushed to client CAS applications through SAML validation and the appropriate configuration.
I have two applications one is a business process management (BPM) & the other is a document management system (DMS) , both systems exposes web services to enable integration with other systems. Both system provide a master login username and password to provide JSON API Authentication. for example to start a process ("process1") inside the BPM ; the DMS can send the following API call
/jw/web/json/workflow/process/start/process1?master_username=BPMadmin&master_password=982716171717&loginAS=currentusername
and same apply for calling DMS web services.
The limitation in this security approach is that i am unable to call any of the DMS or the BPM web services using JavaScript and consume the returned JSON using javaScript, since if i follow the javaScript approach i will be exposing the master_username & master_password to the end users and they can manually modify the LoginAs parameter to other usernames and perform actions they are not authorized to do.
so my questions are:-
Can i make the web service calls secure using JavaScript?
second question what other security approaches i can follow to make the web services calls secure using javaScript? baring in mind that i can modify the webs service security to other approaches rather than using master login username and password, but this might require more time and effort from my side?
Thanks in advance for any help
Best Regards
First of all JS is client side and does not include any special security/magic/irreversible functions, like browser aided crypto engine, high grate SPRNG for key generation and so forth. So long story short anything you do with js is not secure it can be obfuscated but it will be NOT SECURE. That is the point you already made. Another more approach is to use your server as 'proxy'. So lets say You are designing an JS aided gui and show some documents ro so, then you make an AJAX request to your app server (not BPM nor DMS) and it acts as proxy that will do the authentication against DMS and call WS and then return the result back to your JS :) So your setup would look like JS (session)-> App (ws auth)-> DMS -> App (sesion)-> JS (I assume you have authenticated user and we'll use users session as JS <-> server secure channel, if not you will have to incorporate some other js auth mechanism maybe one time pass or something but it will be easy because it is your system). And voila. Only security consideration is to not allow anyone to call your servers proxy site :)
Hi I have a question regarding security, and web services.
I need a web service to provide an interface for the underlying mySQL database. I am trying to get a Blackberry Application to store data on the web servers mySQL database through a web service.
My question is, how can I ensure that the bb-application is the only thing that is using the web service? The web service will essential insert data into a table. I want to ensure that only the bb-application is allowed to use this service and not someone who figures out the service and starts spamming my table.
Any pointers, best practices or links are greatly appreciated.
Also what sort of web service is best in this scenario?
Take a look at basic authentication over SSL. Configuring the application to include the username/password in the header should be fairly straightforward and the SSL connection will ensure they're not being transmitted in cleartext.
Use net.rim.device.api.crypto.HMAC to implement HMAC authentication and validation. Establishing end to end SSL connections on a Blackberry can be problematic and dependent on wireless provider support unless your users are activated on a corporate BES (which I srongly recommend as part of the solution if you want robust security).
I am going to assume that the BlackBerry application is made by yourself as well. How you can then do this is by creating a sequence or hash that only your application can create, that the web service can verify. For instance, in the beginning of the process, or better, for each step the web service sends down a key sequence, which maps to an internal dictionary within your application on the method to make the unique hash.
The flow would then be as follows:
Perform data task in BB application
Ready to transmit data to web service
Create unique hash from data + your own information from the mapped dictionary
Transmit the data with the key
Web Service verifies the key. If validation fails, it discards the data completely, if succeeds, it will then do what it needs to do.
Continue.
HTH
Disclaimer: Assuming this is an open ended WS.
Also see my answer here.
I would go with a REST web service over HTTPS it would take your problems away. I dunno anything about blackberry apps so I can't give u any pointers on how to use HTTPS in that platform.
If you are creating a SOAP web service then you want to read about ws-security.
Others have indicated using SSL to secure the site. However, that is only one part of the puzzle. Kyle was close with the second, but didn't quite cut it.
The answer is that every single transaction which is posted to your web service must contain some type of authorization key. That key can be pre-shared and baked into the application OR it can be acquired through some other means and set up as part of the application install / configuration process.
Nearly all companies which provide web services online following this method. The idea is that regardless of the underlying protocol (ssl for example) you have to validate that the request is indeed coming from an authorized device / program. Some vendors have the users create a unique key for each user, some for each device, and others just 1 key for the entire organization. Regardless of how deep you take it there is in fact a key.
The key usually isn't that large. It might be anywhere from 15 to 40 alphanumeric characters.