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.
Related
I hope its possible someone can point me in the right direction. This is 100% a education issue.
Problem
I need to create a web application at the moment I would like to use with ASP.NET Core MVC or Blazor Server. But I would like to move this to either a Blazor Web Assembly or Angular application in the future.
I am creating what seems to be a very simple web application. Users can sign up and request a licence key. Users can have multiples of these keys. Once a form is filled in this is then awaiting authorization. This part isn't the problem.
I am finding it hard to work out how to and the best way to get this data stored in a database. The licences will be linked to the user stored in the Identity database. I have followed multiple tutorials and tech papers online on how to use authorisation and authentication but none seem to go into details about storing user data. Obviously only the logged in user can view/create their licences and will have no access to anyone else's.
I understand the process will be different for ASP.NET Core MVC/Blazor server and Angular/Blazor WA as these will require an API.
I hope that someone can point me in the right direction as I have been scanning online for 3 days now and kind of need to be put out of my misery.
Thanks in advance.
Below is one of the way to handle.
Create a table with UserId, license, Active, and any other required fields.
Expose a Web API Controller with the Authorize attribute. Only the users with valid JWT tokens will be able to access this Controller.
UserLicensesController will be talking to the table which stores the Licenses.
Use Blazor Web Assembly, OR Angular, OR React JS. Login with valid credentials.
Invoke the Get/Post/Put methods from UI to UserLicensesController Web API, and pass the JWT token.
Please let me know if you need any further assistance.
[19-May-2021] Here is a basic solution.
I have created a basic solution.
UserMgmtStore.sqlproj contains the Database Project.
UserMgmt.API.csproj contains the Web API with JWT authentication.
I am using Auth0 for the authentication and authorization platform.
UserMgmt.Web.csproj contains the Blazor Web Assembly Project.
I have used the Username and Password to retrieve the JWT token from Auth0.
As each individual project with have their own Identity/STS system. I have hard-coded the token just to complete the Proof Of Concept.
I have checked in the POC into my GitHub Repository.
URL: https://github.com/vishipayyallore/mini-projects-2021/tree/master/Projects/UserLicenses
So we are using IdentityServer4 for our web applications, all is good.
We have a new requirement from a client to allow them to perform SSO via their ADFS system using WsFederations, we already provide this for another one of our older web applications that is not tied into IdentityServer4 yet.
Ideally we would like to tie WsFedereration into IdentityServer4 so it is in one place.
Does anyone know if it possible to use IdentityServer4, so we redirect to IdentityServer4, identity that this particular client (possibly via an alternative URL), then IdentityServer4 authenticates against ADFS, collects the claims (probably basic, e.g. email/username/etc) , and we then supplement them with additional claims for access, and pass back to the web application.
What I'm trying to achieve ideally is to not change the existing Web Application, and to sort the plumbing at IdentityServer4, and the Web Application wouldn't know or care if this user was IdentityServer4 only or
IdentityServer4 + WsFederation. This would be useful for other clients across our applications to easily integrate in the future.
Alternatively I could deploy another version of the Web Application that authenticates directly with my clients ADFS system. However this seems a waste of server resources/maintenance for just one small client.
I had a look at the external options (where you click google on or near the IdentityServer4 Login Screen), is there a way to automatically redirect to the ADFS without event seeing the IdentityServer4 implemented Login screen.
Is this possible?
Thanks,
Jon
This was released 2017, see the example at
https://github.com/IdentityServer/IdentityServer4.WsFederation
I am new to windows azure development.
I am developing an application for hosting online tests.
This application needs to have multiple authentication options like Windows live ID, Facebook etc.
It also needs to have default form based authentication fed by the database in back end (simple User name and Password match).
Based on the authentication mechanism different permissions will be available to the user.
Can anyone please suggest how i should proceed on this?
Thanks
Do you really need forms authentication, or do you just need an application specific store where people can use a credential specific to your app?
I'd suggest researching Windows Azure Active Directory and Windows Azure Access Control Services together. You may create either an AD tenant for your application store and use it as an Identity Provider for ACS or you could host your own Secure Token Service and Identity Provider which uses your backend database as the user store also registered with ACS. This means that all of your authentication goes through the same process and allows for you to have your own user store, plus the social Identity Provider capability.
The key here is that you want try to avoid having forms authentication AND Social, but rather a mechanism where multiple Identity Providers can be used, including one of your own.
As Gaurav stated there are a ton of resources out there for this:
Understand the difference between WAAD and ACS.
Provisioning an Azure AD Tenant as a Identity Provider in ACS
Windows Azure Identity
There are also many blogs and MSDN documents talking about how to set these up.
If you start with the default "ASP.net MVC4 Web Application" template in Visual Studio you get a web application mini-sample with an AccountController that supports local and 'social' accounts out of the box. See documentation here. It is based on DotNetOpenAuth (a fantastic lib with terrible documentation) and a Microsoft implementation of an special MembershipProvider which lives in WebMatrix.WebData.
Regarding the Azure Access Control Service 2.0: I have no idea what the status of this service is but it looks to me as if MS itself tries to discourage developers form using this service since it was to deeply hidden somewhere under Windows Azure Active Directory in the documentation.
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.
I'm working on a WCF project that will be our new service layer.
These services will be called by 2 separate clients, the first of which is a WPF application and the other is an ASP.Net web application. The WPF client will be run by internal users and will authenticate with the service via domain authentication and run under the context of that user. The other will be used by external users and needs to authenticate using some separate mechanism then impersonate a "WebUser" account on our domain.
I'm reading a bit about Windows Identity Foundation and it sounds like this might be a good fit. Am I right in thinking I could have 2 token services, one for domain authentication and one for something like ASP.Net membership authentication (Or some similar equivalent) and have each client get it's token from the relevant STS and pass that along to the WCF service?
I'm assuming there is an STS I can use out of the box for domain authentication, but will I have to implement the second one myself to authenticate web users? I can't find a lot of information on this.
Am I thinking along the right lines or should I just be creating duel endpoints for each service each with a different authentication mechanism? Or should I be doing something completely different?
Thanks
The big advantage of using Claims-Based authentication / WIF is that both the task of authenticating the user AND the administration of the user's properties are moved way from the applications to the STS/Identity provider.
You are developing a service layer but the true benefits of using WIF will be for the applications written on top of your layer. The WPF application will no longer need to connect to the AD and fetch the user's groups to figure out what they are allowed to do. The groups will already be visible as claims in the token the user/WIF provides.
The web application (is it just one web application or more?) will no longer need the ASP.Net Membership database with accompanying user administration. This functionality gets moved to the STS.
There is a cost. (There always is, somehow...) Claims-Based authentication has a rather steep learning curve. It takes a while for the quarter to drop for all people involved.
So the answer to your question depends on what kind of users the web application(s?) built upon your service layer have and how many. And how much they wish to know about them. Can you perhaps trust Google / Facebook / Windows Live for authentication? Are the users already in an existing database within your domain? How much work will it take to maintain the user directories? Do your marketing people wish to send them emails regularly? Et cetera.
This is probably not just for the service layer's developers to decide, but something to discuss with people in the rest of your organisation.
If the benefits are not particularly big, the alternative is to simply keep these responsibilities at the web application's server. Each web application will have a good old ASP.Net membership database, it'll authenticate the user all by itself. When asking queries from the service layer, it'll present its web server certificate plus specify the user's name and type.
If the benefits are big enough, you can in principle use ADFS 2.0 for everything. It can also store external users nowadays and it's free if you already have Active Directory. Or the ThinkTecture 2.0 server that Ross recommends. It's easier to customize and perhaps your systems administrators and security folks will not be too enthusiastic about opening the firewall to the ADFS server.
Microsoft has some good reads on WIF, in particular an Overview of Claims-Based Architecture.
You should take a look at identity server as it can indeed handle this scenario.
The person who leads the project above has a great pluralsight video on this exact scenario! You need to sign up to watch it, but they offer a free trial.
Basically you get a token from the identity provider (windows ADFS for the internal client, and what ever you decide for the external users). You will give this token to the federated gateway (identity server probably, but it could be Azure ACS). This will return an authentication token that you can then use with your service.