Greeting..!, I am making a asp.net chat webApplication using SignalR were I want to keep track of every user and store there actions is database. I use userId to keep track of them.
My problem is that I don't want to pass confidential data(like userId) from client form to signalR hub.And I know SignalR hub class does not support sessions.
so how can I do that.
I am new to signalR and I googled a lot about this problem but couldn't find any simple answer.
SignalR supports different ways to authenticate and authorize users:
Cookie
Windows authentication
Certificate
Connection header
You can find more information about SignalR and security here:
http://www.asp.net/signalr/overview/signalr-20/security/introduction-to-security
Keep in mind that even though some info might be transferred, there is often an abstraction that does not really let someone map a user to a token or vice versa on anything else than the server.
Authentication and authorization is only a small part of security which goes further by using SSL and to carefully think what you transmit as you already said., etc.
But on some point you need a link between relevant information on your server side application and the caller. This might be a session identified by the cookie after a classic forms based authentication, an hash based header or whatever you want to create. SignalR is flexible so you could think about something like authentication against a different system and pass only a delegation token.
You have different ways to map your userId and the connectionId.
Take a look at this tutorial on asp.net
Related
I'm completely new to ASP.NET Web API. I've done some research but I haven't been able to find an answer to my problem. I am starting to become very confused about how to secure the data that is being responded to the caller.
My overall objective is to create an ASP.NET MVC web application and a Xamarain Android application that allow users to register and login into an account and their data stored in a MySQL database.
I thought that a Web API would be a good solution as both applications could call functions to get a collection of users, an individual user and put new users into the database through HTTPPost, HTTPGet requests.
So far I have created an ASP.NET Web API with one controller and one HTTPGet request which returns all the users from the database.
When I run it I get a response of all the user's details.
My Controller Code
public class UsersController : ApiController
{
// GET api/values
[HttpGet]
public IEnumerable<Users> Get()
{
using (NorthYorkshireContext context = new NorthYorkshireContext())
{
return context.Users.ToList();
}
}
}
My Response:
If I were to deploy this to a server what is stopping anyone from seeing all the users details? For example, If I deployed this to http://mydomain.co.uk what is stopping anyone from querying the API like http://mydomain.co.uk/api/users and seeing all the details?
P.S I understand passwords should be encrypted, sorry if this is a bad question.
This question reads as "I created a publicly accessible API endpoint that outputs my entire users table; why are APIs so insecure?". Why did you create this operation in the first place? What problem does it solve? When I make a human-sized hole in my house, can I rightfully complain that after a few days my computer and television are stolen?
For each API endpoint you must consider:
Do I need this? I really can't figure out why you would need a list of all users.
Do I need this to be publicly accessible, or should it be limited to localhost traffic (i.e. infrastructure)?
When publicly accessible, who may access it (authorization)?
When called, should it return all columns that are in its data source, or should there be some kind of mapping?
And no, passwords don't need to be encrypted, they need to be hashed. Use ASP.NET Identity for authentication, don't roll your own.
an API is a perfect solution for what you are trying to do.
When you build an API, that is exposed to the outside world, you need to secure it somehow. This is where something like OWIN, OAuth2 come into place.
A token based system (JWT) is usually a good solution to secure the API. I would start with some reading on the subject if I were you.
Once you secure you API from unauthorized access then you need to think what data you should provide to the users / apps who have the right to access it.
Having passwords in clear is a huge security risk, sending them to the app is an even bigger risk.
Normally you'd let the users authenticate, you would not send passwords to the app.
Make sure your API works over https and do not send anything private in URLs, use POST requests and put the sensitive data in the body.
Security is a big topic, I am afraid.
https://identityserver4.readthedocs.io/en/release/intro/support.html
I currently issue tokens myself in my web api with JwtSecurityToken and I use standard ASP.NET Core middleware calling AddJwtBearer to verify the tokens. It works fine.
What advantage will give me using OpenID Connect (through IdentityServer4) over the approach described above? How to answer myself question "Do I need OpenID Connect?"
From my basic understanding about OpenID Connect, it is used to allow third parties to access your API. But I make API for myself and not for third parties and I don't know why should I favor IdentityServer/OpenIddict over my simple approach.
I read that if I want Single sign-on I should use this, but JWTs itself aren't bound to any specific domain and I can use single sign-on with just pure JWTs(they're self-contained)
I understand it implements some kind of standard for issuing tokens. (protocol). It might be good if I ever wish to expose some API to third parties. But for internal APIs? Is it worth using it?
This is my current auth flow (from https://jonhilton.net/2017/10/11/secure-your-asp.net-core-2.0-api-part-1---issuing-a-jwt/)
What I really want to implement to secure my Web API:
Login
Logout (invalidate token?)
No consent screen (want to have API only for myself), auth happens in the background in my native desktop, mobile, web app (no redirection)
Remember me feature (refresh tokens?)
Could someone clear out the fuzzy picture of OIDC/OAuth2 for me? i.e. give me some disadvantages going my own way (implementing my own flow) and advantages of using OIDC in place of my own flow.
What will it save me from doing later on (on the client-side for example), and what will not. And most particularly, is it good to start every project using standard flows like OIDC? Will it somehow benefit me in the future?
In any case you will implement OAuth2. Think of Oidc as an extension of OAuth2. The most important thing to keep in mind is seperation of concerns.
Forget Oidc, Identity Server 4 is all about authentication: "who is the user"? Consider Google login. When a user logs in for the first time, the application doesn't know the user, it only knows that Google does.
Authorization takes place on a different level and isn't really a concern of IdentityServer. For that you could take a look at PolicyServer.
So you'll need to keep the user database seperated from the application database. This doesn't mean you need another database, just don't mix contexts. If you have a relation from the "business context" to e.g. the user table in the "Identity context" then you are going to have a problem eventually.
In your setup your web api is both the resource and the identity provider. This means that every new web api you create has to be implemented as both resource and identity provider. For maintainability you could create a seperate web api that acts as an identity provider, while the web api is a resource only. You can implement something like that as long as all apps can read the token.
The same counts for the front. Why should the front have anything to do with the user? All it needs to do is pass the token in order to get the user authorized. In case of IdentityServer, the app contacts it to verify the user and receives a token. It knows nothing about credentials. This is more secure. The client app can be compromised. The credentials can be intercepted.
Having single apps with a specific concern makes things more maintainable. And it is quite easy to add a new resource without having to code when you use IdentityServer. Just add the configuration. It also allows you to add other flows in the future that are not needed at this time. And as a side note, the consent screen is optional.
The bonus is that you can implement SSO, where in your setup that could be harder, if not impossible.
So you don't have to use IdentityServer, nor Oidc. Your setup may be just fine. But if you build something, keep seperation of concerns in mind.
I'm developing a social network. I have a RESTful API coded in C# and my front end application on objective C. My architecture is very simple:
Iphone Users (mobile app) < - > RESTful API < - > DATABASE
I want to implement authentication for my service and to make is secure. Also i want to be able to retain something in the phone that tells if it is logged or not and with which account.
I've been reading and i found out that oauth is standard for this. i have a lot of questions that i don't understand. There is suppose to be a previously shared between the resource owner and the server.... who's the resource owner in this case? the user itself? and i imagine the server is the RESTful API. About the security token, is it coded in the mobile app? and in the server?
About the token. does the token retain information about my login? I mean, is the token what tells me what user I am while I use the app? this is what differences two users when they ask for example GetMyFriends ?
and for last, whats an API Key and how do I implement it and use it?
thanks.
This question will require a book volume to provide every possible answer, so I'll try to answer a small bit of questions I can and hopefully that will direct you on the right track.
1) How do I make my client-server connection secure?
Use SSL certificate for the HTTP server that hosts your API.
2) How do I implement my authentication and keep track of which user is currently active in the system?
There are numerous ways to implement your own authentication and I'll only provide a short description. Use two instances of UITextField to get user's username (or e-mail) and password. Send those values to your REST API. To keep track of a currently active User you'll either nee to implement a fairly complex solution using CoreData, where you would create a User entity and have something like an "isActive" boolean value that you'll set to YES once a given user logs in. Keeping it a bit simpler you can just store an NSDictionary representation of your active user's parameters you get from server after authentication.
3) Is oAuth standard for this?
No, do not use oAuth for your own application. You only need to use oAuth to provide third-party applications an ability to log in users into your web application. xAuth is standard - request authentication credentials from user via UI in an application and send those credentials via your API to server and process the response.
4) About the token. does the token retain information about my login? i mean, is the token what tells me what user i am while i use the app? this is what differences two users when they ask for example GetMyFriends ?
Answer #2 should answer how do you know which user sends request. You can retain an information about the currently active user by setting the values you're interested in in the current session, for example - user_id, so you can distinguish which user sends the GetMyFriends request.
I know this doesn't even remotely covers the whole area of what you're asking about, but you need to do a bit better research on this topic.
I have an ASP MVC4 web site. Originally, most of the content was served via controllers as one would expect. I have moved the data storage from SQL Server to MongoDB. I have also added a lot of ajax to update data client side, without a full refresh. This is working fine, but my controllers now have lots of methods that take json and return json. I was able to build a Node.js server that hits the database and exposes exactly the same functionality, without lots of going to and from C#.
My javascript client-side is now calling a Node.js REST API, this works great. My 'secure' code (like adding a new user) hits the same REST API from the server side.
My question is this: How can I handle security properly with this? I have three scenarios:
GET api/messages: No need for security, I want to expose my site's messages to anyone who is interested via a Json REST API.
GET api/my/messages: I need to allow access to this only if the user is logged in (it gets the user's messages).
POST api/users: This is a function that should only be called from the server, and nothing else should be able to use it.
As the user is already logging in to my ASP website, how can I use their logged in credentials to authenticate them with my REST service? While the user is logged in, the pages client side will hit it regularly for updates.
Is there any sensible/standard way to do this? The core idea is that the client side code uses a REST API that is at least partially open to the public, and that in fact that API offers all of my business logic - only parts of it (like creating a user) are locked down to super-admins only.
Thanks in advance!
Create two authentication middleware handlers. One you add to all your "my" routes and another which you add to your POST routes.
The "my" authenticator takes the asp.net auth cookie that is present in the request and makes a http call to your asp.net mvc site with it.
You'll need an action which either returns a 401 if the cookie is invalid otherwise it returns some info about that user's permissions perhaps.
If the request into node doesn't have a cookie, return a 401 again.
In addition, to prevent excessive calls to your mvc site to check the cookie, you could use the cookiesession middleware to set a cookie on the client with a flag of authenticated. That will result in 2 cookies for your client, but that shouldn't be an issue. Just make the node one expire before the aspx one.
The POST authenticator middleware can use any shared secret you like between your node and mvc server. e.g. a special header in the request.
If the user is required to login you can use [Authorize] on your controller actions. Autorization will be handled like any other webrequest.
Furthermore you might consider to add a key to your api requests which you can provide in the initial page load. A autorized user will have a GUID which he will sent with the api call. You can check if this key was issued by your app to a valid user.
As you said all the secure calls already go through your MVC server code which in turn calls the Node.js code, am I right? Basically you need a way to block calls to this Node.js from other clients that are not your MVC code.
Thinking out loud, these are the ideas that pop into my mind:
Use SSL only between MVC and Node. You can set up client and server certificates so that the Node code will only respond after authentication (I don't know how Node handles SSL so you will need some documentation here
If you want, the Node server could also check the call origin and so you can filter based on IP and only allow IPs where your MVC code is sitting
Use an encrypted authentication token on the secure methods on the Node code. Again I'm not really a Node expert but I can imagine it has ways of decrypting a token, or you can simply base it on a random number with a common seed... If noone has access to your server code ideally noone should be able to guess this token. Again, SSL will help against traffic sniffing
I am quite sure that people will come up with other ideas. For me, the most basic thing is anyway ensure that the secure methods are only accessible through an SSL connection and on this connection you can exchange all the info (token, passwords, etc.) you desire.
I have created a MVC 4 Web Api using Entity Framework Code-First and a WPF-Application as a client in VS 2012.
The problem I'm struggling with at the moment is that I have to enable Authentication from the client and authorize users for access to the Api (for example: Every authenticated user can access GET methods but only admins can use POST or DELETE). I used MVC 4 Internet Application because of Forms Authentication already being included, which worked fine until I tried to login from my client application. After spending some time researching my problem about I realised that Forms Authentication is mainly supposed to work with webbrowsers. I even found some possible solutions to get it working with HttpClient using CookieContainers (e.g.: How do I set a cookie on HttpClient's HttpRequestMessage), but nothing works for me.
After spending some hours researching ways to accomplish what I'm trying to do I feel completly stuck..
I've read about SimpleMembershipprovider, BasicAuthentication, OAuth and someone mentioned Thinktecture.Identitymodel, but wasn't really able to decide which would work best.
If there is really no way to use Forms Authentication when connecting with a client other than a webbrowser then what is the best Authentication/Authorization method to take?
I would be very happy if anyone could provide me with a hint on what works best in this case, because after researching for hours I only get more and more confused.
Thanks in advance for any help!
You should be able to do this easily enough, but you haven't said what your problem actually is. Are you
unable to get access to your web api actions because you aren't logged in; or
unable to make it enforce authorisation (i.e. you can get anonymous access to actions)
For the second scenario:
There is a very good overview of using Authentication and Authorization in ASP.NET Web API on the server side, and the various ways you can enforce different roles on Actions.
There is also another approach that is appropriate for machine-to-machine (i.e. where you don't have a user who will type their login details into an appliation dialog box) in Making your ASP.NET Web API’s secure, but it doesn't focus on using SimpleMembershipProvider. Instead of using the framework auth&auth components it uses tokens (take care with this approach - rolling your own security is very very hard to get right).
For the first scenario:
From the client side, it sounds like you have some a C# application that user's interact with. If this is the case (rather than the machine-to-machine scenario) then your Forms-based approach is still suitable, and you are doing the right thing with your cookies. The approach would be:
Ask the client to type their username and password in to your application
Send a request to your LogIn action on your AccountsController, this will return your authentication cookie, session cookie etc.
Store the cookies that are returned from this (successful) login (or notify the client if the response was "login failed"
Then use those cookies in the request to the web api
As you are already talking about using HttpClient, I'm guessing you know what you are doing for this, so haven't provided code samples. I wouldn't use HttpClient, for what it's worth, but HttpWebRequest which allows you to keep a common CookieContainer through the HttpWebRequest.CookieContainer property.