I'm looking for suggestions regarding methods of hosting a 'custom STS' within a self-hosted OWIN pipeline.
It seems that the current documentation on custom claims providers has changed very little in the few years since I created a custom-STS with WIF 3.5, and I'd like to bring the implementation up-to-date for use with ADFS 3.1 (Windows Server 2012 R2).
I'm aware that the SecurityTokenService has moved to the System.IdentityModel namespace in 4.5, and ideally I'd like to encapsulate an STS within an OWIN-self hosted WebAPI, but I would be happy to use something like Nancy instead if necessary (since MVC does not appear to run in OWIN owing to it's reliance on System.Web), but I am struggling to find a way to utilise my implementation of SecurityTokenService from my WebAPI's DelegatingHandler since the wrapper functions in System.IdentityModel.Service.FederatedPassiveSecurityTokenServiceOperations also appear to be reliant on System.web, and hence IIS.
I plan on presenting the required input form elements to the user by manually crafting the response stream and parsing the POST - I realise this is a terrible idea compared to using ASP.Net or MVC, but at this stage this is really just a proof of concept for me, I'll be letting ADFS handle the cookies, since this will just be registered as a custom claims provider.
Should I drop the SecurityTokenService class in favour of a better token-generation implementation, or should I drop the wrapper class and manage requests to the STS manually using the IOwinContext's Request and Response objects, but if so, how?
Many thanks
Related
First off, I apologise if this is a trivial question but I am getting so confused by the information I am reading. I have put off posting on here as I feel my question is too broad but I can't find a definitive answer. I am a C++ developer by trade but I am wanting to get into web development.
My end goal is to have a web API that is consumed by both a web app and mobile app. I want to get the structure nailed first by developing an web API and web app and then expand it to a mobile platform later on.
My aim is to have 4 separate sections - Database -> WebAPI -> Web App
-> Mobile App
all of which are protected with username/password etc.
I have decided to use ASP.NET Core but when creating an application I am given two options in visual studio - ASP.NET Core Application or Web API. I have tried creating a Web API and a separate Core Application but can't work out how to call the web API. I have also tried creating a Core Application as it seems like I should be able to do everything I want in one project but I am worried that the Web API won't be separated enough to be able to call from a mobile app.
I will be working with a database containing sensitive information so obviously want to protect access to the Web API and Web/Mobile app. I have been watching courses on Pluralsight about Identity but I have read that it doesn't work well with Web API's.
Basically I am getting extremely confused when in my mind my end goal should be relatively simple to achieve. If anyone could give me any pointers as to what technologies I need to use would be fantastic.
ASP.NET Core WebAPI is specifically designed for building REST-ful services.
ASP.NET Core Application is used to create web applications that returns both views and data (it's an analog of Asp.NET MVC from standard Framework).
Which to choose is really depends on kind of WebApp you are going to use. If you plan to use some SPA framework, you don't need mechanisms to generate views on server side - WebAPI is a great choice, otherwise choose Application. Here you can find more details on differences.
As of security concern, there no issues with WebAPI. It provides a lot of mechanisms to secure your API and restrict access to methods based on user's identity. Please look at this article as an example.
I am new the webAPI2, so please excuse me if my question is trivial. I want to implement token based security for my webAPI, so that other applications (apart from my SPA) can also call my webAPIs.
I started with Owin OpenAuth and implemented a POC. Everything worked well. But when I had to send client to Authorization to Authorization server, I could not find any inbuilt function to do that. I had to build this my self. Then I came across DotNetOpenAuth that provides APIs to set the communication as well. As far as I could find out, Microsoft is favoring Owin OpenAuth over DotNetOpenAuth.
Can anybody please provide the differences between these two? Also, which one is recommended?
Thanks In Advance
Brock Allen answered a similar question here
The OWIN middleware is grated more for just the protocol bits, but has
none of the necessary persistence bits (or replay protection or
refresh token support or many other things). If you are interested in
working directly with the protocol because you want to learn it and
really learn how to build a server, then the OWIN middleware is an ok
place to start. But if all you want is a sever that already has all of
those pieces implemented, then consider looking into IdentityServer
or DotnetOpenAuth
This is more of a design question than a problem. So here's the scenario, you have an asp.net 5 application with a webapi controller and it provides data to many types of clients: web, ios, java apps, etc. Let's say that one of those clients happens to be an mvc controller within the same web host and visual studio solution as the webapi.
What are the ramifications of calling into the webapi as a class instance, instead of doing what the other client types are doing--which is to make a rest based network call? The obvious benefits are eliminating the over head of a network call and eliminating the serialization. But I wanted to know what some of the possible negatives could be. Has anyone done this before?
The easy solution could be that you could extract that logic to a separate assembly... let say a "Business Logic Layer" so that both WebApi and MVC could access it.
This has the downside, that you will not be able to have MVC and WebApi separate. I mean, using WebApi as a single data interface could allow you to host MVC app separately from where the WebApi is hosted... but the approach in the first paragraph will couple both proyects and will force you to host them together to have access to the data.
If you call the class directly any work done by the HTTP pipeline won't be done. So your API class won't have access to the HttpContext for example.
Also none of the security or Http related annotations (attributes) will work, so your MVC controller may need to deal with that.
I'm using ASP.net Web API 2 via VS2013 to create a private API for a project. This is all working well, including the automatic Help functionality, with the exception of one thing:
The API is secured using OAuth 2.0 Resource Owner Flow and I want to include the "/Token" endpoint in the Help as without it there is a very important part of the API that is completely undocumented.
I can't see any way of doing this as it stands because the OAuth functionality is handled via the OAuthAuthorizationServerProvider class rather than a ApiController derived one, and hence it will never be included in the standard documentation.
Does anyone know anyway that I can add my own documentation to the standard Help functionality?
I've actually managed to find a workaround, albeit a nasty one: Because the OAuth functionality is handled further up the stack you can basically make a normal Action within a Controller which takes a "custom" object that conforms to the input expected by the actual OAuth endpoint. It will never be called because the OAuth endpoint handles the URI first, but it still shows up in the API Help.
I have a windows service that is supposed to send e-mails periodically.
Next to the windows service project there is an MVC 3 project that is sending e-mails with MvcMailer (beautifully).
I want to use the same engine to send e-mails for the windows service.
How should I do it?
Import the MVC binaries and create one controller and new views for this purpose? Will it work?
Saving it in the database and requesting my web project to send the e-mail might not be the best solution because the information is the result of a query and is too big to be sent in the request.
The only other option I see is to simply request the web project to do all the work but this way it wouldn't be beneficial to place the windows service in another service to save the site application resources.
How would you do it?
As an alternative to MVC Mail, ActionMailer.NET can now be used stand-alone outside of MVC.
The details are covered here
http://geeksharp.com/2011/07/06/actionmailer-0-6-released/
I would argue that calling a mvc mailer from the service might be an overkill. If the mvc project is supposed to expose sending the email API for all of your other solutions, then building a REST api might make sense. However, if you just want to bring the functionality of the action method to the windows service, then i would choose an in-process functional component. If you can refactor the logic of the mvcmailer action method into another assembly why not just do that and then include that assemlby as a depedency in your windows service solution.
If you can provide the over all purpose of the mailer and how it's used in the web scenario, it may help us to provide a better architecture.
Why do you think the query to send to mvcmailer us too large? If you have the mailer MVC project already working and exposed via a restful URL, that becomes your email service and simply call it as a web request from your service.
You can get around size constraints in your request That shouldnt be an issue.