Would like to understand what is the difference between WAF and APIM (Like APIGEE or AZURE APIM).
What are capabilities of WAF and which needs to be choose to protect the backend web application.
Thank you in advance.
Aaditya
WAF protects your backend web server by stopping every request that having malicious values. Malicious requests can be SQL injection, Cross site scripting.
Modern WAF also protects server from blacklisted IPS (tor or bots).
You can also define rules like whitelist IP or regex match for parameters and header.
Regards,
Jaikey sarraf
Google Apigee plateform also has capabilities like whitelisting, security(OAuth, JWT, Basic and key based), CORS header and others.
I think that you should more focus on what kind of architecture you might need in order to support future requirement. As with Apigee, Google has great support for cloud as well(AWS, GCP and Azure) with support to almost all type of language and virtual target backend for complex mesh ups as well.
Apigee provides inbuild support for Analytics and Monetization services as well, which you might want to consider.
Apigee has 24X7 support for all your issue/concern for different level of environments.
Related
Good morning everyone,
My apologies if this post is too similar to this post:
Dynamics 365 and Azure integration
but I am struggling to understand exactly what is needed in order to setup a web service on an Azure server that is consumable by a Dynamics 365 plugin. Based on my research it appears that it goes as follows but I would like to see if any knows of a better guide.
1.) Construct the web service as normal on the Azure Windows Server.
2.) Register a proper DNS Domain name (friendly-name) and route it to the Azure server.
3.) Secure that Azure server/URL with a certificate.
4.) Call the web service from my C# Dynamics 365 plugin.
Is that everything or might I be missing something critical? Thank you!
4 might be an issue, given you want to use certificate based security, not sure that will work, you might need to use another mechanism, e.g. basic user name and password. Otherwise looks okay.
Plug-in isolation, trusts, and statistics
Web access
Sandboxed plug-ins and custom workflow activities can access the
network through the HTTP and HTTPS protocols. This capability provides
support for accessing popular web resources like social sites, news
feeds, web services, and more. The following web access restrictions
apply to this sandbox capability.
Only the HTTP and HTTPS protocols are allowed.
Access to localhost (loopback) is not permitted.
IP addresses cannot be used. You must use a named web address that requires DNS name resolution.
Anonymous authentication is supported and recommended. There is no provision for prompting the logged on user for credentials or saving
those credentials.
Getting started with Okta in a "security-conscious" organization, where connecting across the firewall requires a mound of paperwork.
Wondering if there are any best practices for testing applications internally before heading to the DMZ. There are two parts that we're primarily concerned with:
Authentication - any way we could emulate authenticating against something like an Okta preview env't without traversing the firewall?
API testing - while doing internal development, it would be great to be able to make API calls like "create user" against something that is purely internal - even if it's just a stub.
Okta doesn't currently offer a full-fledged mock Okta client, so there's no officially supported method for testing Okta locally.
There's a partial, undocumented mock-okta client here. However, it currently only supports the /oauth2/v1/authorize authorization code flow.
I am developing an App for iphone,android using PhoneGap for the client side. On the server side, i have a Restful API with Sinatra/Ruby(Not Rails). The App is free and anyone can access the services but i need to make sure the minimal level of security is implemented so my API is available 24/7.
I heard about oAuth but i am not sure if that is the way to go.
oAuth is a standard for authorization across different authorization domains (e.g. between services) and is probably not what you want.
The easiest way to secure a REST API is the usage of HTTPS. To secure Sinatra have a look at How to make Sinatra work over HTTPS/SSL?
Since Google lists the ClientLogin API as deprecated what is the recommended alternative?
In my case I need a server to authenticate and post things using credentials which I own. Alternatives like OAuth won't work in this context
The authentication method varies based on the scenario of your application. The scenarios reported by Google documentation are:
Login
Web Server Applications
Client-side Applications
Installed Applications Devices
Service Accounts
In your case, the Web Server Application scenario might be useful (if you give more details about what do you mean for "In my case I need a server to authenticate" I can be more precise about this point).
However, the recommended alternative to ClientLogin is OAuth2.
I am migrating one ASP.NET MVC 3 intranet Website to the Windows Azure and DB to SQL Azure.
On Premises my site uses Windows Authentication to authenticate and authorize the user(By Placing AUTHORIZE attribute on controllers).
It would be very kind of you If you can let me know How to go about the same.Thank You In Advance !
You have two choices here:
Use federated authentication and something like ACSv2. This requires a bit of work to setup a relying party, install ADFS2, etc. However, it is the most robust and future proof option. It is a very good option.
Use something like Windows Azure Connect. That will bring Windows Authentication to the cloud by joining your running instances to your domain controller on-premises. In effect, you have something of a VPN between your cloud instances and your on-premises domain controller. There are some caveats to this model today (requires installing agent on DC for instance), but it would be from a 'just works' stand point, the easiest. Longer term, this is less attractive I believe than option #1.
You can get more details for each of these by checking out the Windows Azure Platform Training Kit.
I should also add that you have no option (today at least) of using Windows Authentication with SQL Azure. You must use SQL authentication there, so what I am talking about here only applies to the web site itself.
I'm very successfully using Windows Identity Foundation with Azure AppFabric Access Control Service to authenticate using ADFS v2.
As well as straight authentication, it gives you lots of flexibility over other claims, such as roles (which don't need to be based solely on AD group membership).
In my opinion, its biggest strength is that there is no communication channel required between the Azure platform and your on-premise AD. Everything is done via the browser. From a security perspective, this means that although anyone can reach your application, nobody can authenticate to it unless they can also reach your ADFS server. Access to this can be restricted to on-premise clients only or via VPN, greatly reducing the attack surface.
Also, because ADFS does not need to be exposed externally, it can greatly ease the bureaucratic overhead of deploying it, in my experience.
Only configuration is required, which although it can be a bit of a fiddle initially, is pretty straightforward once you've got to grips with it. You configure WIF to use ACS as it's Identity Provider and create a Relying Party in ACS for the application. Then, you configure ACS to use ADFS as its Identity Provider. You could configure WIF to talk directly to ADFS, but the additional level of abstraction of going via ACS can be useful.
Once you've done your configuration, using the [Authorize] attribute 'just works'.
Note that if you're using Ajax calls into your controllers, you'll need to take some precautions, as Ajax calls don't handle the federated authentication redirect (or the ADFS Shuffle, as I like to call it), but it's nothing that's insurmountable.
All in all, I'm very impressed with the combination of WIF+ACS+ADFS for transparent Windows integrated authentication.