I have two separate apps and one Azure Mobile Service. Is there a way to link both apps to use Live Connection through the same Azure Mobile Service. The service allows associating one app to my Azure Mobile Service domain, but when I try to associate another app to the same service, I get an error that it is already in use (which is correct, but intended!).
One Azure Mobile Service
2x Different Client Apps
Live Auth
Is there a way around this or am I forced to create a new mobile service for each app client type I have. This seems silly as they're all using the same back end service.
This is not currently possible. If you look at the Identity settings for a Microsoft Account, one of the requirements is the Client ID which is tied to each individual Windows 8 app ID.
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.
Following situation:
An SAP OnPremise system is connected over cloud connector to SAP HCP
In the cloud version of the SAP mobile plattform (SMP) I configured the system
I have a hybrid app (using SAP Kapsel SDK) and try to connect to
a) SMP itself (registring)
b) also to the real backend sytem with the data needed
User name of SMP and backend system is not the same
Does anyone have a good tutorial / documentation link how to setup this correct?
I found a very good tutorial about the Kapsel plugins:
- https://blogs.sap.com/2016/10/20/getting-started-kapsel-part-1-sp13/
With a trial account and a trial backend account (same user name) it seems somehow working. But in my situation it is more complex.
Problem in other words (Edit)
I am searching for a way to use user & password from OnPremise system to authenticate against HCPms over a Hybrid app.
May I ask why you require two different users at all? From a usability point of view, it is very awkward for a user to give two sets of credentials for an app. I'd typically recommend to either
configure SCIM in Mobile Services. This would allow you to register with Mobile Services using your back-end credentials
configure no-auth in Mobile Services. While users still need to give their credentials for back-end access, they can register with Mobile Services without credentials at all
The rest depends on your back-end configuration. For example, if it requires Basic auth, configure your back-end connection accordingly and leave the user/password fields empty. When you supply those with your client requests, they will be forwarded to your back-end.
Edit: I misread the question and thought you were using "SAP Cloud Platform Mobile Service", the cloud equivalent of the SAP Mobile Platform. The answer basically remains the same, only the terminology changes (italic):
configure HTTP(s)-based Basic Authentication SSO in Mobile Platform. This would allow you to register with Mobile Platform using your back-end credentials.
configure no-auth in Mobile Platform. While users still need to give their credentials for back-end access, they can register with Mobile Platform without credentials at all
Either way, SCIM for Mobile Service is described in the documentation, and so is Basic authentication for Mobile Platform.
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 have a mobile application which relies on a Windows Azure App Services Back-end. I want to tie down some security vulnerabilities. For example, someone can currently access all my records, modify or delete them. Not Ideal...
I only want users to be able to access their own records (data privacy) and I want to ensure that only my application can POST data to the server, i.e. an unofficial potentially corrupted app shouldn't be able to POST data and corrupt my database. Maybe some sort of TLS etc. approach might do this? This restriction (if possible) would likely allow me to implement the access-to-own-records-only logic in the mobile app rather than backend?
How could I ensure only legitimate versions of my app can interact with my back-end?
Azure Mobile Apps (an SDK on top of a standard Node/Express or ASP.NET app that can be deployed to Azure App Service) provides a mechanism that your web or mobile app can access records in a SQL database. The users ID is stored alongside the record on a POST and the users ID is also used as part of the query when returning records.
See https://shellmonger.com/30-days-of-azure-mobile-apps-the-table-of-contents/ - particularly Day 6 (for Node/Express) and 18 (for ASP.NET)
As to your last question - how to ensure only legit versions of the app can interact with your backend - you can't. Trivially, you might think to use a shared secret that needs to be passed IN ADDITION TO other authentication requirements. However, this does not stop someone sniffing the wire and using the same shared secret. There is virtually no way that you can stop a determined player from accessing your backend without using an approved app.
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.