Here is what I want to do.
I want to have a MVC web application that I can user to administer tables in my SQL server database (windows azure). I want to authenticate with a 3rd party login (google, twitter, facebook etc).
I want to have a mobile application that makes use of windows azure mobile services to access and modify those tables. The mobile app will log in with the same providers as above.
The problem: when I log in with the MVC application I have access to the username and email address.
When I log in with the mobile application I get access to a userId ="google":{
"userId":"Google:my-actual-user-id",
"accessToken":"the-actual-access-token"
}
on the mobile service side but not the email address or username.
So if I want to write a Server side script(azure mobile service) to get data from the tables, what should I use as the unique user identifier?? The MVC application does not have access to the userid the mobile application gets on login, and the mobile application does not have access to the username or email address available via the MVC login(OAuthWebSecurity)
I found this link: http://blogs.msdn.com/b/carlosfigueira/archive/2012/10/25/getting-user-information-on-azure-mobile-services.aspx
But looks like you cannot even get the google email using this…. So still no way to uniquely identify the user!!
Thanks for any help
It doesnt really answer how to get around the issues highlighted above. I imagine using the same type of authentication in my MVC application would have got around this, but then I would have to have found a way to get the email address for a google account. Then I would have had to consider how to handle other authentication providers which would have brought other issues. I found other issues with windows azure mobile services which meant it just wasnt for me
Does not seem to be a way of accessing data from a different database namespace with mobile services
I was re-writing business logic in the mobile service that I already had in my MVC application, which I had unit tested, with entity framework etc
It seems simple and straight forward if you follow the examples of mobile services but once you step off that track it becomes very problematic and in my view just not worth it. It is not flexible enough to do anything meaningful.... but that just might be me not using it correctly.
So I am now using web api within my MVC application. Using httpclient in my windows app to contact access this data. It allows me to reuse my business logic, and it is much more flexible. If you feel the assessment of windows azure mobile services (chocolate tea pot) is unfair would love to hear an opposing view.
Related
Not sure how to go about doing this; I'm not looking for B2C, I don't want my users to sign in. I just want my Xamarin app to be able to access an Azure AAD protected API. In other words, I want to authenticate the app itself with the Azure Active Directory, to access an Azure AAD protected API. From what I've found on the internets, service principal to service principal auth is discouraged when using mobile apps and I've not really found a way to do it service to service anyhow.
Any suggestions on how to properly do this? Links with tutorials would be great.
Thanks!
Azure does provide the ability to generate a client ID which you could have sent from your application and checked. Microsoft talk about this in this article. You will want to be careful with how you store this ID in your app as if someone were to steal this they would be able to access your API. Along with that you'd also want to make sure that your connection between your app and server is secured with a pinned SSL certificate so it cannot be man-in-the-middle'd.
Another interesting approach is software attestation where some service checks various aspects of your app to ensure that it is your app. Full disclosure, I work for a company which does this. See Approov. We take a fingerprint of your app and our SAAS checks that this matches at run time. We then issue a token which your app can use to prove that it is the real app.
I have similar question that was posted earlier in No application keys for Azure Mobile Apps - what's a simple replacement?.
But there doesn't seem to be any satisfying answer on that issue.
I just want to restrict the access to the the azure custom api & db tables with a simple key/code in my mobile client application. I dont want the users to be forced to login to their fb/google etc accounts.
The "new" app service/mobile app seems only to work with authentication where the user/client sign in using google/fb .
Is there any way to accomplish the "old" application key behaviour in this "new" app service?
The application key was removed as it does not provide any real security. If you are using the Node.js backend, check out https://github.com/Azure/azure-mobile-apps-node/tree/master/samples/api-key.
I am working on an application which has an azure asp.net mvc website and an azure mobile service. Both will be using the same azure sql database.
I understand that I can use custom or Microsoft, Facebook based authentication using my mobile service. The website and the mobile app that I will be building though will have different features in the website and on the mobile app based on the role of the user.
How should I go about implementing user roles? If this was just an asp.net application, I would have just used ASP.NET Identity but not sure how to do this with Mobile Services.
I found a similar question asked a year ago with no resolution - Using ASP.NET 4.0 membership provider with Azure Mobile Services
If there is an existing implementation or guidance out there, please point me in that direction. Thanks.
As of today, there isn't a super easy way to handle this no matter how you slice it. You can take a look at this post (there is another dealing with the JavaScript backend that is linked from this) http://www.acupofcode.com/2014/04/general-roles-based-access-control-in-the-net-backend/ that talks about role based access control using Azure Active Directory. AAD may not be the option you want to go with. In which case, you'd need to implement the roles and checks in your Mobile Service yourself. If you only have two levels such as "normal user" and "admin" you COULD dictate everything based off of the user.level property and if they are "authenticated" they only have basic user access but if they're "admin" they have admin functionality. You'd still need to do the role based logic in your backend but I think you'll need to handle that no matter what.
Alternatively, what I think you could look at doing, is using the ASP.NET Identity system. Then from your Mobile Service, you can use the same type of custom auth I've documented here (http://chrisrisner.com/Custom-Authentication-with-Azure-Mobile-Services-and-LensRocket) but instead of checking against and storing a username/password in your Mobile Service like that sample is doing, when the user goes to register / login, you could check against the user backend created by the ASP.NET identity system. I don't have a sample off hand of that working but it sounds doable in my head.
I know there is a lot of questions out there already and I've been reading blogs and looking at samples for well over a week and I'm still a little hazy on how some of this is going to work in the real world. The samples are very helpful, some are very complex some are simple, none have really clarified some of my questions.
The system comprises:
Web App (own IIS site, with SSL, consumes Public API)
Public API (own IIS site, with SSL)
Desktop Widget
Mobile (iOS, Android)
3rd Party apps
How best to handle user registration and account creation? Whilst offering OpenID there also needs to be a 'local' login to the web application. Having a method on the API that accepts base data types (strings/dates etc...) values and then creates an account is asking for trouble and a red flag to the spammers. Would it be best to handle this exclusively through the web site employing visual CAPTCHA checks? How does the Facebook mobile app handle this registration scenario?
Lots of samples also seem to use small subsets of the default Forms Authentication database for Membership. They then use Entity Framework and the Membership, WebSecurity or FormsAuthentication, Roles Provider classes in various different ways depending on use case. Are there any alternatives to this approach to consider for the security backend? Our DB guy is considering rolling our own but then we also need to build our own user management app :(
Once a user is registered and logged in to the web app I can't see any way around continuing to authenticate and authorize each call on the WebAPI. I'm assuming at the moment that the API should just implement OAuth and treat the web app as another client app like the mobile app and 3rd party apps.
I think I've read too much without playing with code to settle this in my head. There are so many approaches.
TIA,
I am developing a web app that will be working with other companies web apps. Part of the desired user experience is that users on our web application will be able to log into our app, and be able to visit our parters' web applications. Accounts will be automatically created for the users on our partners' sites. We'd like them to be able to enter the partner sites already authenticated, without having to log in or authorize anything (like with OpenID or OAuth), similar to the relationship between a bank and a credit card rewards program. Is there an existing standard that covers this?
Single Sign On often used for such functionality.
There are a lot of implementations.
I used in production Jasig CAS