Azure AD
First, due to area restrictions, we are not using Azure AD B2C. We tested this option in the end of the last year but it was not stable. Azure AD B2B looks more stable, but we still have some beta API’s, like the invitation one.
The invitation procedure is working fine, but we could not customize the language. This would be helpful. We could customize the screen as we click in Get Started. However, when the user is already a member, we could not customize the login screen. We tried to do so, but unfortunately, it did not work, as you can see on the pictures.
Another point that I would like to comment is the process to transit between one Web App to another (we have five web apps using the same AD authentication process). The time to transit is too slow sometimes. I do not know if there is a different way to configure it.
Entity Framework Core
For basic use, EF Core is working fine, with a good performance.
However, we have difficulties regarding using EF Core for a multi-tenant scenario. In our scenario, a single user (owner of a supermarket, for example) can have access to different databases (stores). The solution we worked together with Felipe and Waldemir was setting up different schemas to different customers and stores. Therefore, we have to change the schema we are using online. We could handle it using EF Core, but it was not a simple task.
Talking about simple tasks in EF Core, we discovered that WITH NO LOCK and some Group By statements do not create a good SQL command. Our decision to this scenario is to work with some Stored Procedures. Maybe we are creating the lambda statement in a wrong way, but we need some documentation to do so.
Related
I'm evaluating the above three identity management technologies and wanted to try to find out the advantages/disadvantages and get a sense for when I should be using IdentityServer3 over the other technologies. I have three scenarios:
Internal MVC Client to Web API
External Phone Client to Web API
Internal Web API to Web API
Brock Allen's Comments:
According Brock Allen, the creator of IdentityServer:
Well, the main thing that differentiates IdentityServer is the ability
to customize the entire token service and have control of the user
data. SaaS products are very limited in customization because for the
most part they don't let you upload arbitrary code to alter or change
behavior and they often encapsulate the database of users. On the
other hand, this means you have to host IdSvr (which can be cloud
hosted) and you need to build a database for your users. So if you
need the control, IdSvr is a good choice.
Also, I should note that very often IdSvr is used in conjunction with
other identity providers (like ADFS or AAD). IdSvr is deployed in
between the apps and the ultimate IdPs, again, usually to allow the
customization that the apps need, yet still centralized and
consolidated.
Source
My Own Findings
Disclaimer: I looked into this for use by the company I work for, who had existing infrastructure I had to cater to, so the solution I chose is skewed in that direction. Even so I've tried to give an impartial summary of my own thoughts during my research.
Azure Active Directory
Azure Active Directory is a hosted identity solution, so there is far less setup (especially if like me, you discover that you are already using it for Office 365). Out of the box, it provides some very nice features that can get you started very quickly.
The premium version has monitoring and reporting capabilities (Connect Health) so you can see who is logging into your system, it has two factor authentication, an identity management website and Microsoft is monitoring logins (a bit like cloudflare for identity), so it should in theory provide some added security. However, the customization of the UI is very basic, you have to pay for the premium features and using the Azure Portal to do identity management (if you go with the free version) is kind of a pain.
The documentation is pretty good and there are samples on GitHub with Microsoft devs actively monitoring the issues which was helpful. Some links I found useful:
Documentation Home Page
Documentation for each flow
Samples covering every flow
Introduction Video 1 and Video 2.
Build Videos 1, 2, 3.
IdentityServer
IdentityServer is the Swiss Army knife of Identity management. It can do everything but does require a small amount of setup and a little more knowledge of the identity space. It can do most things that I listed above and a lot more beyond.
It has to be noted that even if you are using Azure Active Directory, there may still be reasons for choosing IdentityServer which I had not initially considered. For example, if you have more than one source of user data e.g. You are using AD and also a SQL database of users, then IdentityServer can be used to point to both of these sources of user information. In theory it should also make it easier to switch from AD to something else entirely as it decouples things.
The project is actively developed, has code samples for all the authentication flows and you can get answers from the community. Some links I found useful:
IdentityServer4 GitHub
Samples covering every flow
IdentityManager (A separate application for handling users, groups and roles).
Introduction Video
Authentication Flows
Fact: Security is hard. There are lots of different ways of doing authentication called flows. I put this link here because I found it very useful for understanding them.
(source: azurecomcdn.net)
Summary
I discounted AWS Directory Services as it's very young even though the company I work for uses AWS. We also use Office 365, so I discovered that we already had an Azure Active Directory linked to an on-premises active directory server. Even so, IdentityServer is still a valid contender for reasons I explained above. We are still trialing both solutions...
What you decide to choose depends entirely on the problem you have. Which should you choose? Well, it depends on the number of developers, time, money and effort you can expend setting this up. There is no one size fits all solution. Really, the differences in the two products above are the differences between a SaaS and PaaS solution.
I recently read into Azure Tables and I the system has an implemented E-tag check for checking concurrent actions. I assume that for Azure Mobile Service, each of the insert and update methods etc. are atomic, however, I have been hard pressed to find any real information on concurrent data access. Should I want such to be implemented, is it up to me to implement it or does Azure Mobile Service implement some kind of concurrency handling system.
A basic use case I am looking into is the most basic
User 1 gets object A
User 2 gets object A
User 2 saves object A
User 1 saves object A -> This should result in a fault
Is it up to me to implement this? And how should I go about it? My first instinct would be to manually add an E-tag field for the object that is checked by a server-side script. Is there a better approach?
My best guess is that because WAMS is using SQL tables that it uses Optimistic Locking. So, I think the E-Tag is the way to go.
The following articles should shed some light on SQL for Azure:
Windows Azure Storage and Concurrent Access
Best Practices for the Design of Large-Scale Services on Windows Azure Cloud Services
How to get most out of Windows Azure Tables
I'm looking to create a database for a CAPA (corrective action/preventive action form). Basically, one person creates the initial report. This is forwarded on to the CAPA manager, who fills out another field on the form. Then it goes to the investigator, who fills out some information. Then it goes back to the CAPA manager and so forth.
My instinct is to create an Access frontend with a SQL Server backend. I'd need to kick off an e-mail at each step of the process. I'd also need to send reminder e-mails if it gets stale for X days at any of the stages.
I know I could really accomplish this with most databases out there, but my main question is, is there any database or third party product out there that would make the process of setting up that routing workflow easier? I have other projects where the routing would be similar to the one above or an approval workflow.
Based on your description it is absolutely possible to implement this project with proposed technologies.
If your company already has adopted SharePoint 2010 it can be also good option for implementing collaborative work flows.
Also from my experience MS Access works best if connection to server is stable like intranet.
We have a BI team that have created a wonderful data warehouse that works fine for the internal staff using it through Excel on the internal network. They use windows authentication through the domain controller, and everything works fine, including restricting the access to users and AD Groups.
The issue is that we now want to provide the same access to a wider audience that is not part of our Windows Domain. This is further complicated by the fact that the information on the users that need access to the system is already stored in another location (an application with a SQL database).
The goal is to make it so that they connect (probably using HTTPS) to the cube (using Excel Analysis services integration), and be authenticated using the Username/Password that they had in the main application.
The main application has a WCF Service interface for user authentication, and session management, so all I really need is a way to provide authentication in front of the MSMDpump.dll against that WebService. We can also add in a Role Mapping so that we can define the SSAS roles against the users in the application.
I was thinking that I could create a dll that has the same interface as the MSMDPUMP.dll, and have that translate calls between the client and the main dll, but this seems a bit of overkill.
Are there any pre-built tools to do this? (and yes I know that Sharepoint can do something like this, but that's not an option so please don't suggest it). Does anybody know of any blogs detailing how to do it?
Any pointers in where to start with creating an interface between the 2?
The question is similar to How to secure MS SSAS 2005 for HTTP remote access via Internet? however, I'm looking at providing the authentication mechanism from another datasource, and providing the Roles to SSAS, not the users. We don't want to have to setup a new user in SSAS for every user that is setup in the external application.
UPDATE: To be clear, they external users need to connect to the cube using Excel, and the data returned needs to be filtered by the role they're in and the security applied in the Cube.
We are able to cahnge the cube to use Dynamic Dimension Security and use CustomData attributes if that helps.
The eventual solution ended up being a combination of a Third Party Control and Dynamic Dimension Security.
We found that it's not possible to easily apply a MembershipProvider interface to the MSMDPUMP interface without significant effort, so our solution gave them a Web Interface to use instead.
The Control we used was by DevExpress and is their "PivotGrid" control. It's not free, but is significantly less than the development resource costs of implementing any other custom solution.
Along with the control, we've applied Dynamic Dimension Security to the Cube so each user of the Site will have a dedicated connectionString to the cube with "CustomData" appended to the connectionstring. This allows us to delegate Data Segregation tasks to the Cube and BI team, and let the Web Developers concentrate on the display of the controls.
The solution is working quite well, and doesn't involve heavy weight applications like Sharepoint/Excel Services. It can built directly into your site and branded as you need, providing a sales tool as well as a useful functional tool.
Can you create a limited-access user on the cube db (read-only, only for the relevant cube, etc.) and hard-code that user/password into a connection string on the app db?
I'm wondering what the basic protocol is for storing users in a database, creating accounts, and authenticating them - with ASP.NET MVC 3 framework (using C#), and Azure SQL.
More specifically:
1.) Where in an ASP.NET C# MVC3 Visual Studio project do I write code that only runs on the back-end? Such as logging into my database as an admin, so I can write to and read from the database.
2.) Where should I make database calls from using MVC framework? Do I call a back-end function (e.g. - to create a new account in the database) from the controller?
Thanks for any help!
I'm not 100% sure whether you are talking about SQL Users or Application users.
However, generally, what ASP.Net MVC applications do is:
they use one or two defined users to connect to the database (e.g. they might define a read-write and a readonly connection for different types of queries)
they use the ASP.Net Membership API for application-level user accounts
they use an ORM framework like NHibernate or Entity Framework for other database access
There are lots of tutorials and articles for this sort of information out there - one place to look might be Scott Hanselman's blog - see:
a tutorial on using ASP.Net Membership with SQL Azure
the Mix11 tools walkthrough - including Code First Entity Framework
1) You could use Membership (which I used to use) or simply write your own Authentication code. There are 2 drawbacks with Membership. First, there are a ton of tables and stored procedures that are installed but worse, there's no way to change a user name via the Membership API. Try telling a customer that they cannot change their username (which is usually their email address) and they'll give you weird looks.
2) Forget EF and use your own repository, which simply harnesses SPROCs. Go ahead, make a ton of changes to your EF design canvas, change the db schema, and I can guarantee you will run into issues with the "behind the scene" files at one point or another.