Have webapi odata v3 endpoint implemented with Microsoft.AspNet.WebApi.OData, exposed under API management, how do I change the service root path, instead of returning the azurewebsite one return the api management URL.
Try using the <redirect-content-urls/> policy in an outbound policy to update the URLs. If that doesn't work as you need, you can use the <find-and-replace/> policy. https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies#MaskURLSContent
Related
I'm new to url rewriting process in Marklogic and need help to resolve the below issue.
I have written Xquery implementation to redirect my API endpoints to the respective Xquery modules as /rewriter-ex/rewriter.xqy.
xquery version "1.0-ml";
let $url := xdmp:get-request-url()
return if(fn:matches($url,"/fetchRecord")) then
fn:replace($url,"/fetchRecord","/lib/fetch-record.xqy$1")
else if(fn:matches($url,"/saveRecord")) then
fn:replace($url,"/saveRecord$","/lib/save-record.xqy")
else (xdmp:set-response-code(404, "Not found"),"/no/such/resource")
And the url-rewriter path in the App server configuration is set to /rewriter-ex/rewriter.xqy and rewrite resolves globally parameter is set to true in App server.
I'm able to redirect my API urls to the respective endpoints.But I'm not able to use predefined ML Res-API endpoints like /v1/documents,it is showing 404 error as returned in the rewriter.xqy.
Is there a way I can implement rewriter to support both rest api endpoints as well as custom API endpoints?
If you'd like to create your own RESTful API on top of MarkLogic, with your own custom end-points. Please check out XQuery API for RESTful Services (XQRS).
declare
%rest:path("/fetchRecord/{$record-id}")
%rest:GET
function fetch-record($record-id as xs:string) {
fn:doc($record-id)
};
declare
%rest:path("/saveRecord/{$record-id}")
%rest:PUT("{$doc}")
%xdmp:update
function put-record($record-id as xs:string, $doc as document-node(element())) {
xdmp:document-insert($record-id, $doc)
};
Your RESTXQ Modules can sit on their own separate HTTP App Server (on their own port) and live side by side with another HTTP App Server which has the default MarkLogic REST API on it.
XQRS is totally compatible with the rest of MarkLogic's software, including Data Hub Framework, they can party together.
The REST API doesn't support customization or replacement of the default declarative rewriter configured during initialization of a REST API server. In addition, the REST API doesn't provide an XQuery API interface to the functionality of the REST API endpoints.
Instead, the recommended approach is to extend the REST API through one of the following alternatives:
Providing an endpoint module in the modules database and specifying the actual path of the module in the modules database on a request to the REST API server to invoke the endpoint without rewriting as in http://myhost:8010/the/directory/path/to/my/module.xqy
Such endpoints can be Data Service endpoints. See https://docs.marklogic.com/guide/java/DataServices
Using the /v1/invoke endpoint to invoke a main module. See https://docs.marklogic.com/guide/rest-dev/extensions#id_72813
Using a Resource Service Extension. See https://docs.marklogic.com/guide/rest-dev/extensions#id_41710
Hoping that helps,
Thanks for your answers.I'm planning to use two app servers one for rest calls and other for API calls.These two app servers will point to the same DB.Please let me know if this is a right approach.
I am working on a webapi core and have few methods within it. This is a restful web api.
I don't want a situation where people will grab my uri and start using it. I want only
authenticated users to have access to the webapi. I am new to this. I am using the webapi core.
A xamarin.forms app will be using this webapi.
I will appreciate some directions on how I can secure this.
I would suggest you below approach
User DB - either Identity or custom store
Authorize your web api controller
Use JWT for generating JSON web token and validating them.
Provide access if only JWT validates. Excellent support in ASP.NET Core API
Provide Login (token generator API endpoint), pass JWT for further API calls as Authorization header
I think this REST Security Cheat Sheet can be useful
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md
I already have configured Federation service. I have to use Web API with WS-Federation service. As Federation services use cookies to store security tokens and there is no support of Cookies in Web API. Now, how to use Web API with WS-Federation?
This link discussion will help you:
Invoking webapi throws No Access-Control-Allow-Origin header is present on the requested resource
It states that WebApi uses host's sign-in protocol.
Ok, the situation is this.
We already have an existing ASP.NET MVC 5 site with Custom Forms Authentication, Logon, Registration etc with a custom database for roles and profiles already implemented.
We now are adding some new functionality to the MVC site and we decided to use Web Api 2 OData 3 endpoint which lives in another domain. The Web Api currently doesn't include any authentication but we need to be able to map the requests to a certain user to get his roles etc from the backend. The MVC and API sites use the same backend.
What we would like to accomplish is, that when the user logs on in the MVC site, the MVC site calls the Web Api server-to-server with the user's credentials and receives a token that the client can then use to call the web service with.
When API receives a request with the token, it can then map the request with the user in backend and do authorization.
As far as I understand it, Simple Web Token (SWT) could pull it through. But considering the environment, .NET 4.5.1 / Web Api 2 / OData 3 with Entity Framework in Azure Web Role, I started thinking is this SWT something I should really use or if there is any NEW technologies recently published that could easily pull this through. I don't want to add any unnecessary 3rd party dependencies to the project if the .NET stack already contains something like it.
So, what would be the simplest way of pulling this kind of authentication through without adding unnecessary dependencier to the project.
The solution we are looking for, is only temporary meanwhile we redesign our authentication scheme. So we are looking for something really simple to implement that works with least dependencies that need to be removed later on.
I'm using this in a project I'm currently working on. I use the OAuth 2.0 OWIN Middleware component that ships with Web API 2.0 (if you add a new Web API project with Authentication enabled, it includes the base infrastructure).
You would use the Resource Owner Password Flow as defined in the OAuth 2.0 specification. Basically you request a Token from the Web API OWIN Middleware sending:
client_id - identifies your MVC endpoint
client_secret - identifier your MVC endpoint
username
password
And in response you get a bearer token. The token generating is based upon a claims principal, the OAuth middleware component has predefined hooks for adding claims. This token now needs to be added as authorisation header to each response. On the MVC side you might add this to session so that it's always available to make backend API calls in the context of the user associated with an incoming HTTP request. If you're using WCF Data Services Client, you'll need an authorisation service/manager or similar that you can hook into OnRequestSending and OnResponseReceived events, so that you can insert that bearer token into the HTTP headers.
You can customise the OAuth Middleware component as you need to quite easily, it took a bit of time to figure it out as it's not too well documented, but downloading the Katana source code did help a bit as the source code does have some good documentation.
The nice thing about it all is that you simply need to enable HostAuthenticationFilter and add Authorize attributes on the Web API side and it's ready to go. You can get access to the claims principal object and use claims as identifying pieces of information for your user - e.g. identity, roles, other attributes etc.
To get started, look at http://www.asp.net/vnext/overview/authentication/individual-accounts-in-aspnet-web-api
Also as a wrap, I did consider the use of JSON Web Tokens (JWTs) as there is an OWIN library available for generating and parsing these. The use case here would be that you authenticate, get a JWT back, and then use the JWT to get an OAuth 2.0 bearer token. The JWT is useful if you want to move authentication elsewhere, or if you want to get additional information about the user at the MVC side of things.
I have a WCF service which needs to be called from client side(ajax call).
I want to use ScriptManager on ASPX page to add a ServiceReference to the WCF service (or) JQuery ajax call to the WCF service. I want to deny anonymous users accessing the WCF service. Is there any way to do user authentication before calling a service method from JavaScript? how to secure my WCF service calls from client side?
There are a number of things you can do to secure your WCF services. Probably the easiest way is if your services are already part of the existing overall ASP.NET application is to enable ASP.NET Compatibility Mode for your services. If your ASP.NET app uses authentication to validate users (e.g. forms authentication) and you are enabling that via a session cookie, then ASP.NET Compatibility Mode does most of that work for you.
By default, this is disabled, but you can enable it with an addition to your web.config:
<system.serviceModel>
...
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
...
</system.serviceModel>
This will enable compatibility mode for all your services in your application. You can also enable this on a service by service basis by setting the web.config value and also using the AspNetCompatibilityRequirements attribute on your service class not the interface):
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class FooService: IFooService {
}
When you enable this setting, you have access to HttpContext.Current (like an ASP.NET page) and it will also enforce that a user must be authenticated before accessing the .svc file (just like you have to be authenticated before accessing any .aspx file). If you try to access a .svc file without being authenticated, and you're using forms authentication, the caller will be redirected to the default login page and, after successful authentication, will be redirected to the .svc file.
This suggestion makes a few assumptions:
your services are in an ASP.NET application;
you're using some type of ASP.NET authentication (like forms authentication) to validate users' credentials and persist a validation ticket in a cookie;
This suggestion, while maybe not the most secure or robust, is probably the simplest to at least get up and running and secure your site to a reasonable degree.
Here's a good MSDN library intro article on ASP.NET compatibility mode.
If this works, perhaps the next step is to look into something like HMAC authentication (which involves a bit more work and the coordination of secret keys - but it's definitely more secure IMHO). Here's a nice walk-through of implementing it - http://blogs.microsoft.co.il/blogs/itai/archive/2009/02/22/how-to-implement-hmac-authentication-on-a-restful-wcf-service.aspx
I hope this helps. Good luck!!
I'm not sure if this will help but I placed a layer between my WCF and webapp. I'd make an AJAX servicereference call to a local asmx. This came under the protection of the forms authentication ticket. The asmx would then do any further security checks (if that specific user making the call was allowed to request that data or shape the data based on the user) and then forward the call on to my WCF service.
This way my service layer did not need to know about the users for each app accessing it and only had a concern for delivery of requested data.
The asmx webservice took the responsibility of security.
Then I made the WCF hosted in IIS using WAS and only allowed Windows Auth access for the identity that the webapp app pool was running as.
So:
ASPX -> ASMX WebService -> WCF
I think that would give you the control/separation and security you are asking for?
for WCF web http service The only way to secure a Web endpoint is to expose it through HTTPS, using transport security. When using message-based security, security information is usually placed in SOAP headers and because the messages sent to non-SOAP endpoints contain no SOAP envelope, there is nowhere to place the security information and you must rely on transport security.