I am having a heck of a time trying to figure out how one is supposed to have AMS authentication with SignalR while using a JavaScript client.
I downloaded the JavaScript client for Azure Mobile Services, I've got Signal R on AMS - that's all hooked up and ready to go. I've got the authentication setup.
I can actually call .login("microsoftaccount") on the AMS JS client and go through that process and get back a token and id.
What I don't know is how to connect the two.
I tried just calling $.connection.hub.Start() - it gives me 401. I tried putting the token in the query string, again it gives me 401. Am I supposed to be calling a login function via SignalR somehow?
The documentation on SignalR and AMS is severely lacking but does anyone know where there might be some kind of explanation of how this is expected to work? JavaScript client with SignalR, I mean.
Thanks
The client.currentUser object has a token defined in it - it's a standard JWT. Once you have that, add a header X-ZUMO-AUTH with the value of the JWT to the connection request. This will authenticate the request with the ASP.NET application.
A good resource is the 12 days of ZUMO: http://www.thejoyofcode.com/The_twelve_days_of_ZUMO.aspx
Related
I am implementing notifications within an action. I am able to register users. However, I am not able to figure out how to do the push notification.
As the sample code uses the SDK, I am now stuck at the part "Exchange key for an access token" found in this documentation.
Is it possible to do this without the SDK? using a rest service?
Yes... but...
There is a REST service that does this, in fact, the library ultimately calls it. It is the standard OAuth2 token exchange endpoint at https://www.googleapis.com/oauth2/v4/token. The catch is building the JWT that you can pass to this service. To quote Google's page on the subject:
Although your application can complete these tasks by directly
interacting with the OAuth 2.0 system using HTTP, the mechanics of
server-to-server authentication interactions require applications to
create and cryptographically sign JSON Web Tokens (JWTs), and it's
easy to make serious errors that can have a severe impact on the
security of your application.
For this reason, we strongly encourage you to use libraries, such as
the Google APIs client libraries, that abstract the cryptography away
from your application code.
In short, if you want to do this, you need to:
Create a JSON Web Token (JWT) which includes a header, a claim set, and a signature.
Request an access token from the Google OAuth 2.0 Authorization Server.
Handle the JSON response to get the access token.
Keep track of the lifespan of the access token and, when it expires and you need an access token, repeat steps 1-4.
Details are at
Using OAuth 2.0 for Server to Server Applications
I'm not familiar with C# libraries, however I've been told that Google's C# Client Library seems to support it, and the high level documentation for ServiceAccountCredential appears to be able to generate auth tokens from the credentials.
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.
Let's assume that client wants to be a new user(sing up) with using iphone/ipad application. I need to add this new user record in to MSSQL database in my host. This request should come to my asp.net pages, and then i need to reply to client. I was using this:
www.exampleWebSite.com/registerUser.aspx?newUserEmail=aaa#aa.com&newUserPassword=123
and then i can return result with JSON like this:
{
"processResult":"True",
"processMessage":"sign up is done"
}
it works like this but i know this is not good for security, right?
by the way, i can return all values(from mssql database) and all CRUD process from my asp.net web site. (.net 4.0) i must use this.
so first question, what is the best way for this? using rest api?
second question, how can i send the data? (client side is ios)
third question, how can i get the data? (host side is asp.net c#)
fourth question, can i develop rest api with visual studio 2010? or do i need higher version?
thanks!!
Several ways to do it but I can go over a few points
Make it a POST rather than a GET as you are doing it in the querystring. This is an idealistic approach, there's nothing stopping you from putting the username and password in the querystring but it's nicer if you put the registration info in the body.
Make it HTTPS and ensure, in the client, that you trust the certificate that the server presents. This allows you to maintain an SSL connection between the client and the server without someone snooping in on the body.
You may want to consider making your JSON response more meaningful. By virtue of it being a 200 response, you can imply that processing was successful. You can return a 401 or 500 if the processing was unsuccessful. The JSON response could simply return OK or a user token that the client stores and uses to communicate with your server.
The MVC Web API is a great framework for building RESTful web services in ASP.NET. See instructions here for VS 2010.
As for getting the data, you could use the generated token in each request to get user specific information; you would need to store that generated token upon user registration in a database against the user.
As a further topic, you may also want to, at least, read up on OAuth and implementing OAuth in your Web API. This would involve performing the login on your own website but giving the mobile client a secret token to use when communicating with your API; the token can also expire every, say, 30 minutes and you would keep reissuing new tokens for that user. However, depending on the nature of your audience and size of your application, you may not want to do this and just having a 'static' token for each user suits your purposes.
I'm struggling to decide how best to add authentication and authorisation to my SignalR service.
At the moment it is hosted in Owin alongside a WebApi2 web service. I use OAuth2 bearer tokens to authenticate with those, and it works perfectly. However, I wonder if they're suitable for SignalR?
My client is JavaScript based, and SignalR uses WebSockets if available. This means I can't use the Authorization header. I figured out that I can supply the token using the qs property before I connect. But of course an OAuth2 access token will expire (and relatively shortly in my implementation). I assume that updating the qs property won't make a difference once connected (particularly with web sockets).
I suppose my question is what is the best way to supply a security token, ticket, or any kind of authorization information to SignalR? Preferably a way that can be consistent on both my WebApi and SignalR, but I am looking to know how I should be doing it.
Thanks
It's been sometime now - but we used to look for the auth cookie in the signalR request to ensure that only a signed in user can subscribe to signalr notifications.
It didn't handle the case where the token expired - since the cookie was checked only on connect. This wasn't a problem for us.
I built a wcf rest service with form authentication. All the settings are set in config file. This service needs to be consumed by android client. So can any body please tell me how to send the request with log in credential to the rest service which is implemented using forms authentication.
Note: I know by implementing custom login service method we can validate the client and pass the cookie for the wcf rest method to authenticate.
I am looking for different solution like in single request we pass the credentials it validates the user with membership and gives the response. Please let us know if u need any further information.
This is a very broad question, so it will be difficult to answer completely. For the WCF side, you can follow this: How to Consume WCF Service with Android. The idea is to return a token, or session, ID when the user successfully authenticates in the system, and each subsequent request uses this token to identify itself. That approach uses SOAP, but you can also use REST too, which REST may be easier to consume in an Android client (REST worked great for me).
See this post, Need advice on authentication for android client connecting to the WCF Rest setup, for more guidance on the setup too. When I setup my authentication mechanism, I did a lot of research online to figure out the best approach to take. A lot of people mentioned just use OAuth 2, and make sure you are using HTTPS communication. So if you can use OAuth or Facebook/Twitter/Google+ for authenticating, that would be a good approach and take a lot of the headaches away.