I have a logic app with http trigger. I am trying to create a proxy for the logic app using APi management. The issue I am facing is that APi management when calling the Logic App, adds operation name which makes the logic app url invalid.
Example: logic app url: azure/invoke
API manager operation name: pass
Looking at trace logs, URL to call Logic app is:
azure/invoke/pass
I am trying to manually add url to backend service with Blank API design instead of using LogicApp.
API management preserves operation URL template while forwarding request to backend API. You can use rewrite-uri policy to control that behavior. In your scenario try adding <rewrite-uri template="/"/>
Anyone struggling why this is happening. The url in the front end is being passed in to the back end. You can either make it empty, add a policy to trim that off
Related
I have a Rest API using controllers, etc, hosted in Azure that has been working for some time. I want to secure the various methods. I added the API App (.NET core) to the App Registrations, and also added the javascript client app to App Registrations. I believe I'm initializing everything in startup.cs in the REST Api OK. I added [Authorize] to one of the methods. I used a simple javascript example which calls myMSALObj.loginPopup, and gets back a token which I then add to the Authorization header and make a fetch call. When I call, I see HTTP Error 401.0 - Unauthorized in the log stream for my App Service.
Any ideas how I can troubleshoot this to get more specifics about what is wrong?
Also, a related question: in App Registrations, Api Permissions, how does one correlate the API permission name with the method in the controller?
Add this in front of the method in the controller
[AuthorizeForScopes(Scopes = new[] { "My.Scope" })]
My logic app HTTP url is something like this:
https://prod-98.eastus.logic.azure.com/workflows/8767e7ecd19c45adbfb01d681e35a888/triggers/manual/paths/invoke/ABCDEFG/api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=U-M0hnvs9BICC_JV7_nTJRQhWg5oZnD_SVo9Sbm03oo
It is not presentable.
I like to make the URL of HTTP request trigger more polished and presentable.
Is there any way to customize the URL of a HTTP request trigger?
Using a clean custom DNS and URL path ( like https://MyDnsName.com/Path/Action ) is the prefrable solution, but anything better than what currenty provided would do.
As far as I know, When a HTTP request is received trigger will automatically generate the URL, and it cannot be changed manually.
This URL includes query parameters that specify a Shared Access Signature (SAS) key, which is used for authentication.
I haven't thought of a way to completely customize the URL to https://MyDnsName.com/Path/Action, but there are two ways to make it look more meaningful.
1. Function App Proxy
After you create an Azure Function App, you can create an proxy.
After you create Azure Function App proxy, your URL is in this format:
https://<function-name>.azurewebsites.net/xxx
2. API management
After creating an Azure API Management service instance, you can customize the URL suffix.
After you create a API management, your URL is in this form:
https://<API management-name>.azure-api.net/xxx
I have seen lot of examples where, there is a custom Login page with Angular JS, and then we make a rest POST call with the username/pwd, and then Spring authenticates based on whatever Auth Service we provide. Then we receive a success, grab the user object from Spring Security and then create a Session cookie in Angular.
https://github.com/witoldsz/angular-http-auth/blob/master/src/http-auth-interceptor.js
I also have seen, integrating Siteminder with Spring Security where we install a policy agent on the web server, and then grab request headers with Spring Security, and then pull the roles and build a user profile object.
I'm looking for a solution where I can combine both the above. This is the scenario :
When the user requests for index.html (Angular), the policy agent on the web server intercepts, authenticates with a Siteminder login page and then passes the headers to the app server. The Spring Security on app server will read the headers and pull the roles from our app database and then build a userprofile object. Now here, I want to continue the flow and display angular page, but Im trying to figure out, how do I send the user profile object to angular, because angular is not making a POST call at this point. Also, how do I get the http-auth-interceptor in play, because I need to keep checking if the user is still authenticated on the change of every view/state in Angular.
Help appreciated ! Thanks !
You may implement a tiny JSON REST service "/your-app/profile" which is protected by SiteMinder, reads and evaluates the headers and returns the result as a JSON object.
Your Angular App (e.g. /your-app/index.html) should better also be protected by SiteMinder so you receive an immediate redirect to the SSO Login when accessing it without session. In addition, it must read the JSON REST resource "/your-app/profile" when loaded. It must also expect that SMSESSION is missing when reading "/your-app/profile" and react accordingly - perform a reload of the protected index.html page to trigger a SM SSO re-login (if "/your-app/index.html" is protected, otherwise you must trigger login by a redirect to some protected resource).
If you want to constantly check to see if SiteMinder session is still present, you may either access the "/your-app/profile" or check for the presence of the SMSESSION cookie (only in case it is not set as HTTP-only).
One SECURITY NOTE: If you rely on the seamless SSO which is provided via SMSESSION cookie, be aware of the possible CSRF (Cross-Site Request Forgery) attacks!
Apparently both roles and the username will be available in spring if the integration is done as this describes
Integrating Spring Security with SiteMinder
I'm using AngularJS with UI-Router and am attempting to attach a query parameter to a url on all http requests across my site.
I have an OAuth system on the backend and was previously applying Authorization headers to all requests, however to preserve backwards compatibility - have discovered I will have to instead apply a url parameter with the user identification to the backend.
My issue is that, I cannot use $httpInterceptor in the config portion of the app, because at that point in the app I don't have the current User, and can't inject $http to resolve the current user because that creates a circular dependency.
I was trying to use $http.defaults.transformRequest in the run portion of the app, but that didn't seem to be able to append a parameter to the url.
Is there a way to do this short of hand writing it on every REST request across the app?
I had similar problem in my current project.
To solve the problem I manually request current user info before app bootstapping & store it in localStorage.
Then bootstrap the app & in the config section you will have accesss to current user info.
TIP: to get user info before app bootstrap you can still use $http service by manually injecting it:
angular.injector(['ng']).get('$http');
I have an AngularJS application (using ASP.NET Web API as the backend) that does not require the user to authenticate (the application has no login). I want to make sure that the REST API methods the AngularJS application invokes can only be invoked from the application. I obviously cannot use token based authentication for that.
If doing nothing special the REST API methods can be invoked freely using the browsers address bar or by writing a desktop application that invokes them. The same-origin policy is only regarded if a browser invokes an API method by a HTML page coming from a site having another origin. The REST API is therefore open to the public and easily hackable.
I wonder what I could do to securely restrict the access to the REST API. Any ideas or experience?
Edit 1:
I found an easy solution for my problem: I just check if the host of the URL referrer is the same as the host of the requested URL. Using ASP.NET Web API the code the REST API actions use is:
private bool ApiCallIsAllowed()
{
var request = HttpContext.Current.Request;
return (request.UrlReferrer != null &&
request.UrlReferrer.Host == request.Url.Host);
}
I am just not 100% sure if I always get the URL referrer.
Edit 2: According to this question the URL referrer ist not reliable. Bummer.
use ssh - that's obvious :)
login process should generate token - write it as a cooke - every http request will use it in header
prepare rest interceptor that will read your token and authorize every request
use some Javascript Obfuscator
Don't forget to invalidate session ;).
you can use spring-security or other framework to simplify this process