Pass ADFS Token in WebClient Call - asp.net

I am using ADFS 2.0 and WIF to authenticate and authorize my users to an ASP.Net MVC 4 application, WebAppA. WebAppA uses WebClient.DownloadString(url) to call another WebAppB and I would like to pass the delegated user's credentials to WebAppB to retrieve customized content for the user.
I see several examples of a web application calling a WCF service using CreateChannelActingAs, but this is not quite my situation.
Is there a way for WebAppA to retrieve the ActAs (or OnBehalfOf?) token for WebAppB and pass it with WebClient to WebAppB? I have seen a few possibilities, including the "bearer" Authorization header and inserting a cookie into the headers, but I don't quite understand these examples and it seems like something's missing, like how to use the BootstrapContext from WebAppA to retrieve and serialize the token for WebAppB.
Thanks for any help!
--Mark

Yes, you could have WebAppA call the STS and request an ActAs token for WebAppB, using the original token (the one intended for WebAppA) as the input, but this is normally used for web services (and it might be overkill). Looks like you are just GET'ing a page from WebAppB. Why not just use basic auth, SSL and pass a parameter of the user making the request? (in essence using a trusted subsystem approach).

Related

Authentication and authorization related doubts with asp.net web api

I have to start a new project to be developed in MVC 4 and Web API. I have prior experience with MVC 4 but with Web API this will be my first project. I understand that web api is there to be consumed by different platforms.
I have a few concerns related to web api. I am presenting them to you guys as following:
1) My first concern is related to user authentication. I looked into this SO question and followed the link1 and link2 given in the selected answer. I still have a couple of questions:
a) When we do user authentication through Form Authentication we create a cookie, that track if the user is authenticated or not, but with web api we do not store cookie, instead user credentials are passed in content header. I didn't get how user's logged in status is tracked in this case ?
b) My another concern is related to restrict unauthorized access, which I think I can find find out in link 1 and link2 provided above, if I am not wrong.
c) I looked at the Edward Brey answer (in the same SO question) as well for authentication but I didn't get the idea completely.
2) My second doubt is about mixing Form authentication and Basic Http authentication. Is it possible that for login I use forms authentication and then for consuming web api I use basic http authentication? If yes then please guide me.
My questions may sound inappropriate but please bear with me
1.a) Restful APIs are stateless, so you are not keeping track of user's logged in status, rather you are sending credentials which are verified for each of the requests
1.b) Yes, if not there are number of articles on web for that. Authorization Filters can help you in achieving this.
1.c) In short, he has mentioned simple logic to authorize user before executing any of the methods in your API. Call EnsureAuthenticated before executing any of the methods in a controller, or put that logic in you Authorize filter.
2) Yes you can do it. In Restful API's each call can be a new instance and you can pass in credentials with api requests whichever you are making.
If you go in discussion of Link 1 that you have provided, you will see:
In our specific case, the server generates the auth token by encoding
the concatenated username and password as Base64 (the reverse of what
is described in the article) and sending it back to the client via a
HTTP header when it performs their ‘log in’ action. The clients then
store this auth token and send it with each subsequent request that
requires it.
If the format of the auth token is well known (as it is in my case),
you could also just generate this yourself on the client and send that
without having the server do this work.
You can use your login to generate an authentication token for client, which you can use to send attached to your web api requests.

Token authentication and authorisation for a self-hosted ASP.NET Web API 2 REST service

I'm using VS2013 and Web API 2 to create a self-hosted (using OWIN), RESTful service over SSL using token authentication. Although I'm not a novice developer, this is my first time looking at ASP.NET technologies, so please keep that in mind.
I've got everything more-or-less working except for the authentication and authorisation parts. I fully understand the difference of authenticating a user (who is this user?) and authorising an already authenticated user to access a resource (can this user access this particular resource?).
A very simple overview of my auth process is as follows (makes some assumptions for brevity):
An unknown client connects to the API, e.g. GET api/values.
The server responds with a 401 and this response header: "WWW-Authenticate: Token".
Upon seeing this, the unknown client knows to connect to a different API endpoint here: POST api/auth (routed to the Login function), supplying the username and password.
The server will try to figure out if this is a valid user and can accept or reject the user depending on the validity of the credentials.
(Rejected) The server returns an error status code (403?). End of process.
(Accepted) The server creates a random token (e.g. a GUID) and stores it against the user record. Then it sends the token to the client.
The now authenticated client reconnects to the API, GET api/values, and this time also supplies the token.
The user returns the resource data to the client.
...
The user can log out by connecting to the same API as he used to log in: POST api/auth (this time, his request will be routed to the Logout function). This will remove the token from the server and the client will also have to remove its own token.
As you can see, this is a relatively simple process, but I can't find any concrete and simple examples to understand how best to achieve this with a self-hosted Web API 2.
I don't need to register users or do any password/roles management, etc. and there is no external authentication. All valid users have the same rights to access the resources and they're already created in the system by a separate process over which I have no control (I can only read their credentials for validation). Most examples I found are talking about security frameworks that I don't need, so I've ruled out using any of the following: Basic Authentication, Windows Authentication, Forms Authentication, Individual Accounts, ASP.NET Membership/Identity, OAuth, Thinktecture or any other security framework.
I've read articles about authenticating in a message handler and others about authentication in a custom Authorize attribute filter, while others even suggest I should use the new (in Web API 2) IAuthenticateFilter attribute. This is very confusing. Can you please advise on a very simple way to achieve my auth objectives? Any specific code examples will be greatly appreciated, even if they're just skeleton implementation or pseudocode. I just need some ideas to get me started.
After a lot of googling, I found this article on CodeProject: http://www.codeproject.com/Articles/630986/Cross-Platform-Authentication-With-ASP-NET-Web-API. While this is not Web API 2 or self-hosted, it has given me a number of ideas on how to proceed.
Someone also posted a comment to that CodeProject article referencing a NuGet package that may interest anyone looking for something similar: https://www.nuget.org/packages/WebApiTokenAuth. In my case, it is a bit much.
Finally, in addition to the authentication options mentioned in the question, there's also the option to write an OWIN middleware to do authentication if self-hosting using OWIN (as per the official MS recommendation). However, I plan to implement this particular form of token authentication with a message handler, as there's more support for this method available than for writing OWIN middleware.

How to secure my AngularJS and Web Api application

I am using AngularJS with ASP.NET Web Api server side. Seems to me like authentication has now become a breeze? Or is this too good to be true?
So I'm thinking of using the Web Api's "Individual User Accounts" authentication. And I am thinking that is all I need. As long as every request is authenticated and noone can get any data they shouldn't I shouldn't need to do much more right?
Or am I missing some key security fundamentals?
When it comes to securing the API you have two main approaches
Cookie based approach. This is the traditional way, where you use the standard form to authenticate the user and then set the form authentication cookie. All unauthorized request take the user to login page. If your API is always supported by UI front end to do login this method with work.
Second is using the authorization token in the header of the request. Once the user is authenticated he get a auth token, which he has to attach to every subsequent request in the Authorize HTTP header. Learn more about it here Individual Accounts in ASP.NET Web API . The advantage here is that you can expose your API without requiring a login page.
But remember when using the second approach, the auth token has to be stored on the client side as all subsequent request require this token. Look at this blog post Cookies vs Tokens. Getting auth right with Angular.JS to understand how to work with token.
Hope it helps.
Here's a great article about using Angular JS with WebAPI 2.0 token based authentication.
http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/

Basic Authentication

I have one VS application named Dotnetpanel, which provides a lot of webservices.
I created another another VS application say TestModule in which I need to create the webservice client. But when I try to create a client and call the webservice in TestModule, an error occured"The request failed with HTTP status 401: Unauthorized." From one of articles I have read that
DotNetPanel API implemented as a set of SOAP Web Services.
Requirements:
WSE 3.0 or Basic Authentication
****Each API call should have user’s credentials provided****
Basic Authentication:
For interacting with DotNetPanel API you should use Basic Authentication. DotNetPanel recognizes “Authorization” header with the user credentials provided in the following format: username:password.
So my question is I have a user credentials which can pass to the TestModule and after that how can I call the DotnetPanel webservices from the TestModule with Basic Authentication.
Regards
Fenix
Sounds to me that you have to send those credentials as a parameter to the web service.
Try to call the web service url to see its methods. When calling to the web service directly from the browser, you have to be able to see a list of methods, then search for the method you're trying to use and click on it. You'll see the SOAP request and response definitions. You can take a look at what parameters is the web service expecting. I think if it asks you for credentials, there has to be a couple of param for that there.
Hope it helps.

ASP.NET Web Service Security

I've built ASP.NET Web Services in the past that either were publicly consumed, or used Windows Authentication. I now need to build a Web Service that uses the SOAP 1.1 protocol and it needs to be secured with a username and password from the caller.
It seems setting up the infrastructure for WCP is overkill for one or two Web Services. Any other suggestions? I was also thinking of using ASP.NET 4.0 Beta, if anyone has explored that for this scenario, it would be helpful to know your opinion.
Thanks in advance for your suggestions.
The simple way is to create a special header that carries the auth info for every call and authenticate/authorize the user that way
Here's some sample code:
http://aspalliance.com/805_Soap_Headers_Authentication_in_Web_Services
Note that in this way you are sending clear text username and password so you would want to use ssl or use some kind of digest authentication
There are different ways of doing this. One could be enabling access to a specific sets of IPs. If the IP doesn't match one of the lists then you could easy reject the call at method's level.
Otherwise, you could create another method that would return a token and then make all the relevant methods to expect that token in return in order to process the request.
Use SSL. Force everyone who consumes your webservice to use https.
//Check for Secure Channel: HTTPS
if (!Context.Request.IsSecureConnection)
return "The HTTP Connection must use Secure Sockets (HTTPS)";

Resources