I have a complete working application that is Web based on AspNetCore.
I used the Identity.EntityFramworkCore to provide all the login and user registration on a central SQL database.
Everything is fine and working great.
But now the quandary starts. I am progressing onto the development of supporting apps for android, ios etc.
I am developing these apps using Microsofts Maui.
My thoughts are to write all the http CRUD API’s in the main ASPCore web application.
Then the Maui apps will call these API CRUD operations.
But my quandary arises with user management.
What the best way forward to have for a common User Authorisation access across all solutions. Bearing in mind the current web based Asp EF solution is there and working?
I’ve researched but can’t decide the best solution going forward: -
Using the existing SQL database & provide Authorisation through API’s on web asp application.
Using Active Directory of Azure.
Transferring everything to 3rd party provider such as “okta, OneLogin, etc”
What’s your thoughts for best practice going forward?
I am currently on the same path. Take a look at
TokenServerAuthenticationStateProvider in MAUI app
Basically I added an API controller (UserController) to my Server app that checks for username and password in SQL database and generates JWT token that I use for MAUI app login and also for authentication on Server APIs.
I use claims in token to pass User variables that I use in MAUI to display or hide some forms or controls. Like Roles but much more flexible.
For me it was the best path as I didn't have to change anything in my working web project.
Related
My .Net MAUI/.NET 7 app runs on company iOS/iPad devices, via VPN back to the company, and talks to on-prem SharePoint's API. SharePoint requires authentication.
The only way I know how to do this is to collect a user's Active Directory username and password into a NetworkCredential and attach that to HttpClient. Our internal security group demands that we stop using username/password.
It seems like Apple's Kerberos SSO Extension, and maybe Microsoft's Enterprise SSO plug-in are the correct replacement.
There are scant resources out there that show how to use these components in .Net, let alone Maui or Xamarin.
I know I'll need to ask my company to deploy both components to our MDM. What is it exactly that I need to tell them? Secondly, what do I add to my Maui app to enable it to work? Such as a device certificate, how does Maui know about it? Or Authentication endpoints (the example uses http), and how does Maui know about them? What kind of person do I look for in my (very large) company that knows the configuration values?
Sorry if every developer except me already is already fluent in all aspects of authentication.
I want to develop backend server for mobile apps(android,iOS and windows) with azure mobile service(.net). I am looking for a sample project which has repository pattern and unit of work pattern implemented in mobile service.
Till now I have not seen any sample which explains this possibility. If any one has come across then please share a link with me.
I want to implement an enterprise level application architecture with azure mobile service(something like onion architecture) where I can isolated each layer from other. Also wanted to know whether it is possible with mobile service .net back end or not?
If any one has any good link or sample project or suggestions then please share it.
Thanks
A repository pattern is just a fancy way of saying "I want to work with complex views of the database and/or abstract the database away from the user". similarly, a unit of work pattern is just a fancy way of saying "I want to work with transactions". The Onion Architecture is just a fancy way of saying "Separation of concerns". So, basically, you want an enterprise application (probably mobile) where the user doesn't see the implementation of the database, data layer is separated from business logic and presentation logic and you can support transactions?
Azure Mobile Services and it's successor, Azure App Service Mobile Apps provide a great way of getting at views of the data - you just set up a view within your database and then Entity Framework can expose that view for you. it is generally used to expose database tables and there are plenty of examples in the Azure Samples - including the FieldEngineer demo, which provides a concrete example of an enterprise-level mobile application.
You have not provided any details of your application which would indicate design decisions. Azure App Service and Mobile Apps, at the end of the day, are just APIs on the wire. They provide a consistent identity and data access layer for the data stored in Azure services.
I'm writing a mobile application, and this mobile application will be talking to a server in Azure to get data, and possibly push some too.
Now, I always had it in mind that I was going to write a simple RESTful web service that was going to deal with all this, and host it on Azure in a website - however, I've since discovered their Mobile Services, and I'm not entirely sure I understand what it's for.
Looking at it, it seems that it's about extracting away the code running on the server from you, and what you push to it, is what you get back? So it wouldn't be much use for me, as my web service is going to be returning data dependant on logic etc. However the ability for the Mobile Services to deal with push notifications directly is nice (how hard is it to use Azure Websites to send push notifications through mobile services?)
However, I wonder if I'm missing something? I'd rather not have to go re-invent the wheel as such, is Mobile Services will do what I need, especially as I'll be using Xamarin and there is a nice component to talk to Mobile Services...
Thanks
I am facing the same question: Should I use Azure Mobile Services or roll my own REST service. Below are some discoveries I have made so far.
With Azure Mobile Services there is a backend running a set of assemblies, which your code ultimately depends on. This is fine until you start using versions of other assemblies, which are not compatible with the versions Microsoft hosts. To me this is a major pain. This problem alone makes me question whether I want to use Azure Mobile Services. If you make your own REST service, I do not expect you to face these problems. See this link for details.
You should note that an Azure Mobile Services is tied to a single Azure region: If your Azure region fails, you need to manually migrate to another Azure region. This might not be a problem for your project. If you want to run in more than one region, I think it will be easier to roll your own REST service.
Regarding push notification, you could do that without using Mobile Service. See these links:
http://msdn.microsoft.com/library/azure/jj927170.aspx
http://weblogs.asp.net/scottgu/broadcast-push-notifications-to-millions-of-mobile-devices-using-windows-azure-notification-hubs
Auto-scaling is supported out-of-the-box in Azure Mobile Services. You would need to make your own scaling logic if you make your own REST service. You can scale VMs using Azure’s REST API, but it will be more work than using Mobile Services.
Authentication is supported in Azure Mobile Services. You would need to look into a separate framework to do this if you make your own REST service.
If you use Mobile Services you will probably create ASP.NET Web APIs through the Visual Studio wizards. There are examples and tutorials, which is great. However, even if you roll your own service, you could build on other frameworks. One example is ServiceStack, which I would strongly consider if you want to make your own REST service. I think ServiceStack could also help with authentication.
If you use Mobile Services you will tie yourself stronger to Azure. By rolling your own REST service it will probably be easier to move to another infrastructure later.
I've used MongoDB before, but never with ASP.NET MVC.
Currently, I'm stuck trying to implement authentication for system which is going to use exclusively MongoDB (so, I don't have the option of leaving the users table to a SQL database).
Now, I figured a solution would be implementing my own Membership provider. However, that requires quite a lot of code. And, since it is related to security, it is not wise to reivent the wheel if I can avoid it.
Coming from Rails, it would be rather simple to just add something like Devise, set it up to use MongoDB and call it a day. I couldn't find anything similar for ASP.NET MVC - I am not sure if it is an uncommon use case, or if my Google-Fu is inadequate.
I don't need anything fancy -just the ability to create users, check their credentials and protect controllers from being called from unauthenticated users. Are there any packages that could solve my problem?
https://github.com/osuritz/MongoDB.Web
A collection of ASP.NET providers (caching, membership, profiles, roles, session state, web events) for MongoDB.
I would suggest to use https://extmongomembership.codeplex.com/ as this is newer provider that was presented in ASP.NET MVC4. And it contin eve more features (for instance permissions system if need)
My team has a rather large web application that was built with the Zend Framework, which has become mission-critical to our organization in the past year. It was built as part of an existing ZF corporate web site that no longer meets our needs.
The ZF app has its own users table in a database. It also uses Zend_Acl, and some database tables, to control access to modules, and to individual records. The records largely pertain to people in the system.
Thanks to new business needs, we're now faced with building a new public web site in Joomla. So, we need: (1) to keep running the old system, in some capacity, and (2) a shiny new Joomla site, (3) integration between the two.
-We can't move custody of the users away from our legacy system, because the people those users represent are elemental to the legacy system's purpose.
-We need the usernames and passwords to be the same, and work the same (we have a 60 day reset policy, our usernames aren't fixed values / are a bit convoluted)
-I looked at Zend_Ldap hoping I could expose our users to Joomla that way, but it seems to be just an LDAP client, and I'm not sure implementing an Ldap server in Zend that uses our existing tables is a good use of time. An extension that replaces Joomla's authentication would probably be wiser.
-Can our ACL control Joomla or should we have two ACLs exist in parallel.
-Do we write SOAP services in the Zend app to expose the data to the extension, or do we just give database credentials to the Joomla extensions directly.
A pretty broad question, I know, but I am only looking for broad answers: how would you tackle this?
Thanks!
The first step sounds like integrating the Auth system across Joomla! and your ZF app from there you can direct link to the ZF App's pages for logged in users. I would recommend the use of JFusion to integrate the Joomla! authorisation process and match the ACL groups across the two systems. You will have to write your own plugin for JFusion but that will be very simple compared to porting your entire app to a Joomla! extension. JFusion's GitHub repo is here.
Given the data provided you will need to run the ZF App as the master for authentication and sync user data to Joomla! via your custom plugin.
Once you have your plugin doing the authentication you can use JFusion's direct link mode to link to the ZF App as user that login to Joomla! will be automatically logged into the ZF app (and vice versa).