I'm using the Client Application Services for Client (WPF) authentication with ASP.Net membership, which is working just fine. However, on the server I have additional MVC queries that I must authenticate when calling them from the client. When looking at the available Membership.ValidateUser call, I fail to see how this helps me in any way, as I need to validate every single call.
I assume sticking [Authorize] on each MVC call is the first step.
Can I get a security token, or extract a cookie for the CookieContainer, or am I simply misunderstanding something here?
I am assuming you ASP.Net MVC site, WCF services are hosted in same virtual application and ASP.Net compatibility mode is on.
If you are using WPF to authenticate your user by calling a web service do the following
On Server side
Implement code to do authentication
Once authentication is successful
create a form authentication cookie
and add it to response cookie
collection.
On the client side
The client class that you are using
to connect to authentication service
should contain a static CookieContainer class instance.
Once authentication is
successful add the cookie received to
this cookie container and pass it along every subsequent request.
Hence forth all request to ASP.Net MVC application or any service would contain the cookie and the user would get authorize automatically. Check this blog post for sample
Hope this helps.
Related
I have a web api server on lets say, api.app.com which serves data for my app and i have a separate web server on www.app.com which serves users the pages for the app. I am using a JWT created on the webapi to Authorize the user. The token is created when the client logs in from the login page served on www.app.com with a username and a password. I want www.app.com (web server) to send a request to api.app.com (web api) to authenticate the user and then store the token gotten from the web api inside a cookie on the client.
Then i want only api authenticated clients to have access to pages on the web server, while the web server gets data from the web api on the behalf of the client per request.
I have checked everywhere online, without a clear solution to this
Web apis are usually consumers of JWT tokens. Once received they validate the token, and check claims and proceed based on the result. Your environment is a little confusing to me.
It seems your api app is used as an identity server as well as data provider. It is best to separate these concerns.
I'm currently looking to secure my ASP.NET Web API service using windows authentication. In terms of configuration, this is quite simple, and is explained here. Then, in order to secure your API, you place [Authorize] attributes on your controllers or actions.
However, if I wanted to check if a user was authenticated in a custom message handler prior to the request being routed, how would I do that? How do you pull the Windows identity out of the HTTP request and then check the active directory to see if the user is authenticated (essentially, how do you manually do whatever the [Authorize] attribute is doing)?
So we are currently looking to build out a site that utilizes a Web API for all of our authentication and communication with the database. What we are unsure of at the moment is how to persist users in our MVC application by authenticating through the Web API.
Where does this happen on the MVC side of things and how should we be authenticating with the Web API?
EDIT: Another thing I am wondering is if we can make a call to the API to get an Identity user after they are authenticated and instantiate the identity user on the MVC side of things and just store them in a session variable to persist on our application. Would this be doable and any idea what it would look like?
MVC utilizes the session for authentication. A cookie is sent to the user, and the web browser sends that cookie back with each request to enable to the server to restore the session and recognize the user as authenticated.
Web Api is REST-based and stateless. There's no concept of a session, cookies, etc. Each Web Api request must be authenticated in the request, usually by passing an Authorization header with a bearer token or similar.
If the MVC application utilizes the Web Api to authenticate, then the Web Api should return an authentication token to the MVC application. The MVC application then, should "log in" the user by setting that normal authentication cookie and save the token so that it can authenticate future Web Api requests with that. In other words, the MVC application still handles authorization as it normally does. The only difference is that the response of the Web Api determines whether or not it considers the username/password combo to be correct, rather than a database query made directly.
I've created a new ASP.NET Web API and things are working well. I'm at the point now where I want to secure the API.
I put the [Authorize] attribute above my base controller and it's working properly if I want to make API calls within the ASP.NET application itself.
However, I'm wondering, what's the best practice for an external client that wants to make API calls and get past the authorization? Also, keeping in mind I have custom authentication logic.
How should the client send over credentials? At what point do I process these credentials?
How should I send the client credentials?
The default location to send authentication info, is the authorization header. You can use this for basic authentication but also for other types of authentication (JWT, Bearer, etc.).
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
To add, for example, a basic authentication header to your request you could use the following code on your client:
WebRequest request = (HttpWebRequest)WebRequest.Create("https://yoururl");
request.Headers.Add(HttpRequestHeader.Authorization, "Basic " + Convert.ToBase64String(System.Text.ASCIIEncoding.ASCII.GetBytes("user:password")));
At what point do I process these credentials?
I would write a DelegatingHandler and use it to resolve your 'principal'. You can then set it to the HttpContext.CurrentPrincipal to have it available wherever you need it within the scope of the request. The DelegatingHandler is called before your controllers as you can see in the image below, which makes it ideal for authentication logic.
I would do the same on the client (write a DelegatingHandler or ActionFilterAttribute) to add the authentication header on a default location. Note that DelegatingHandlers are part of the HTTP pipeline and ActionFilterAttributes belong to the MVC pipeline.
Last but not least I would recommend not to write your own custom authentication logic but stick with one off the default frameworks. This can be as easy as using basic authentication over HTTPS and as complicated as implementing OAuth. But I would stay away from do it yourself solutions.
I did like to also invite you to have a look at this answer I gave to a similair question.
Note: ASP.NET Web Api is REST based, so imho you don't want to keep session information at all.
Edit: For an example on how to implement a delegatinghandler that handle basic authentication see: basic http authentication in asp.net web api using message handlers.
Basically you'll want to send the username and password encrypted over the net to your server application, then you can let your API generate a random session ID and keep it in a list (serverside) and send the ID back to the client. Now each time your client sends something to the server, include the ID he received in the packets and so the server can check it each time.
On client disconnection or fixed timeout you can remove the ID from the server list and ask the client to re-authenticate.
I'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!
You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.