I am starting a new enterprise web application. It will be hosted up on Windows Azure and will be an asp.net MVC application talking to an SQL database.
My question relates to multi-tenancy and the correct way to accomplish it. In the past I've created a multi-tenant application by having a tenant table and than putting a TenantID column in every table. This worked fine (but it was only on a smaller scale so it didn't really exercise it to the nth degree). Looking into the multi-tenant stuff on Azure, it doesn't seem to recommend this way. They talk about subdomain, splitting tenants etc. To me, that just seems like a management nightmare. I would like the user to hit a website, enter their tenant login details and boom they are off.
Is there a simpler way to implement multi-tenancy in Azure that still allows me to use Azure's scalability strengths?
Should I just use the simple TenantID method? Will the Azure framework still scale well to suit?
Should I worry about tenancy at the start or just leave it till the end?
Advice needed.
Thanks
I have done it both ways on Azure. I have done it the way you have done previously where they enter in a tenant code upon logging in and this works fine, I don't see any reason to do differently. You can use SQL Azure federations to manage the tenants so you can have multiple databases easily for scalability.
I have then also used the subdomains approach to identity the tenant, but all it did was map the subdomain to a tenant code. I used this in a system where they didn't have to log on so it was easier for the user.
Worry about it at the start if only to design the database to cope with it.
Related
This is not like other questions you might find similar. My issue is way bigger.
Scenario:
I have 3 websites. All of them have a common database for authentication and stuff.
Problem is that i will need to expand to 2 more sites, which means more maintenance in login screens and so on. So i will dedicate time to make a "central website" to manage users, access, etc.
Also, Need to implement OpenId for Microsoft Works accounts (ie, Azure tenants).
DDBB User Model: (Simplified)
All users are in the same central database. Which does not contains
anything non-user related.
User is personal on all applications.
Users can have different Roles
Each "User-Role" is mapped to an application, a server and a
database.
Problem:
Created a site in AspNet Core, without any authentication done so I can do it myself since I found that mapping Aspnet Identity tables was no-go because of incopatibilities and overriding is way to complicated, specially when dealing with Managers.
So, Tried and got working a simple Authentication page using HttpContext.Authentication.SignInAsync and CookieAuthentication. Which works well and there is no need to use any of the Identity's implementation (which is not compatible with my backend).
But then I added UseOpenIdConnectAuthentication to have the OpenId auth, but I have no idea how to use it since its suposed to work out of the box when using Identity and when checked documentation they use this code in an controller action: signInManager.ConfigureExternalAuthenticationProperties and I do not have any SignInManager since Im not using Aspnet Identity.
Questions:
Is coping the source of ConfigureExternalAuthenticationProperties to make it work in my site an aceptable solution?
Should I continue to override all SignInManager methods and also probably implement other classes to make Aspnet Identity work with my model?
Tried Mapping the properties to my columns just to test it out and it gave me non debuggable errors, which i dont like to even think about the problems this can give me in the future. For example one error was that it coudnt parse byte[] to string.
How can I implement Microsoft Work Accounts authentication and Database authentication in the same AspNet Site?
Bonus topic
Recently I feel like programming is becoming Configuring instead of coding. Is it just me? Are we now Professional Configurers?
Thanks
What are the pros/cons of using .NET Identity 2.1 versus Azure Active Directory (Premium)?
We currently have an MVC 5.x application using Identity 2.1 for registration, sign-in, password resets, etc. A Microsoft consultant is suggesting we should swap to Azure Active Directory to remove the complexity of "maintaining your own security".
What are the reasons to make the swap and why wouldn't you?
I wouldn't say the two are mutually exclusive. Asp Identity has that functionality built in but you don't have to use it. Actually, you could create your own userstores, managers etc. that poll the azure AD for this info. Identity allows you to use it, override it, or skip it entirely.
Why you wouldn't want to do this? Not everyone has AD. Not everyone needs it. The bare-bones approach that the templates use are simply application managed users and claims.
If you are targeting multiple applications and want SSO and have AD then you can take advantage of it. Developing your own at this point is redundant and more work/maintenance as the consultant pointed out.
You will still probably have a Users table and possibly others in your app database because you may have business functions unrelated to AD but boilerplate stuff would all be managed via AD.
Another issue you may run into is the need to authenticate app specific users outside your AD. At that point you may choose to implement a mixed solution. One half polling AD for internal users, and the other falling back on Identity for external users.
Let me start off by saying that I'm not totally sure what I'm looking for. I'm hoping I can explain the situation I'm in, and that someone can point me in the right direction.
So here's what I'm up against. I want to build a ruby on rails application that will be hosted by oranization A on some domain organizationA.com. Then, multiple other organizations (X,Y,Z) will be accessing this tool from other domains (orgx.com, orgy.com, etc.). I do not know at this moment what form of authentication X,Y and Z will use, most likely it will be LDAP or native Windows, but the important thing is that it could be different from organization to organization.
In a situation like this, what is the best way (is there a way?) to allow the users at X,Y and Z to use the application using SSO. Are there any existing tools out there that you would recommend or have worked with? Is there a name for what I'm describing so I can do some better googling?
Any help is much appreciated.
One Possibility
CASino - http://casino.rbcas.com/
Looks like this would be a separate server just for authentication, using the CAS authentication protocol, and could be used for multiple different types of authentication at different organizations. I'll have to check it out.
I'm using CASino for our SSO Solution and it's really cool.
casino and rack-cas provide a good CAS server and client support for ruby based single sign on applications.
You can try rubycas-server and rubycas-client if you are developing RoR applications
Im currently developing a enterprise system using the similar technology, My solution is using rubycas-server to manage user info and logins, and create separate user system base on ssoid of cas-server on each application sever to maintain the access level individually.
I've been research WIF a lot recently and am still quite a bit confused about some of the specifics. I understand that if you're using ADFS that it's great, but that is not my scenario. Within my organization there are at least 3 main security systems. I have tried to get the company to use AD for all internal uses, but it's just not going to happen. In order to create a unified programming model, I've contemplated building add'l STS's for authenticating/authorizing.
Is this really wise? Most of the stuff I've read says just use ADFS. If not, then don't bother. Is it worth using WIF for the unified claims model when the process of creating custom STS's can be difficult?
What do you do in a case where not every user has an AD login to map to. For example, we have many seasonal employees that never actually log in to a machine with a personal account. The machine is logged in in the morning by a supervisor and the employee scans his/her badge and the employee id is used.
We are creating a new application whose code base will be accessed by at least three different sets of users. One group is internal (using AD) the other two would probably use asp.net default membership (okay, so two different sets of user stores). I'd love to be able to use WIF to unify authorization/auth, but with WIF it seems to want to go in the opposite direction. It de-emphasizes authentication and just kind of assumes it's all good when in many case that is the main concern. How could I leverage WIF in this scenario, if at all?
I've tried reading this article:
http://msdn.microsoft.com/en-us/library/ff359105.aspx
and I read up on StarterSTS which I still need to read up on a bit more. I've also watched the videos by the author of StarterSTS. I'm failing to really put everything together. It feels like WIF won't be useful for me, but I feel like it should since all I'm really after is a unified model of authentication and authorization. Thanks
What you want is similar to the Federated Identity model. You can build a Federated STS (like StarterSTS) that would normalize your claims for your application. You can then use something like ACS / AD FS V2 to federate these Identity Providers. Reading the Claims Based Identity Guide is a good start as well. When you Claims enable your application you can add more and more Identity Providers and use the Federation Provider to control the claims and set rules.
We just released a new version of the guide on CodePlex (the docs and code) while it goes through the production process.
I hate to re-invent the wheel so I'm looking for an existing solution to create a simple authentication system for my application. I've experimented for a while with using CardSpace or OpenID inside the application but I can't convince management that these would be working solutions.
Of course, I could just build a simple login dialog where username, domain and (hashed) password is stored inside a database table and I've done such a thing many times already. I hate this solution since I feel it's just a weak option. And I don't want to spend too much time trying to make the whole logon system as secure as possible, especially since I suspect that there should be existing solutions for this.
So, next to OpenID/OpenAuth and CardSpace, are there any other Authentication solutions that can be used from a Delphi/WIN32 application?
Right now, the application will be used by many customers. Most are single-user environments, although it's likely that some of those will start to have two to 5 users once this authentication system is added. But we want to support a customer who needs to allow about 500 different users on the same application. These are spread over about 100 offices but they all connect to the same SQL Server database. (MS Access right now, but we're making it possible for this user to use SQL Server instead.) To make matters even more interesting, the customer uses Citrix to centralize the user systems and the application has straight access to the SQL Server database. It's not an ideal setup but then again, the customer isn't really paying for this. We're just setting up a test environment. A proof-of-concept which the customer will test for us. Flaws will be solved later on. But right now I need quick solutions and one of them is a practical authentication system where I don't have to write a lot of code.
Have you considered using SQL Server authentication and not allowing authentication for those using an Access Database?
If you use the new SQL Server Native Client and SQL Server 2005 you can have passwords expire and change them from your client application. All of the tools to create and manage user accounts are built into SQL Server Management Studio. And if you decide later to support Windows Authentication you just need to modify your connection string.
We have a system where users on the network use Windows Authentication so they don't need to worry about another user name and password. For users that access the system via a VPN and non-domain joined machines they use SQL Authentication.
Here is the MSDN Page that talks about dealing with passwords programmatically in SQL Server 2005
You do need to make sure that SQL Server Native Client is installed, but that is simple compared to the rest of ADO.
I would suggest then
Delphi - since you are using Delphi :)
Open source - since you need to be able to figure out what is wrong if there is a problem, you probably want it cheap.
So, here are some solutions:
http://www.torry.net/pages.php?id=313
CoWindowsAccount v.1.0
SSecurity v.1.2.1.3
http://free-password-manager-plus.software.informer.com/1.6/
It might work for your purposes, but why not ask Windows for the current domain and user name, and use them as unique IDs. Windows has already done the authentication, and it saves the users making up new passwords or anything. I've used this to good effect. I also made it optional to include the machine name in the ID, so that the same user on different computers would also be unique.