I'm interested in building a web application in .NET that is scalable to multiple Clients and each and every Client has users associated with them.
Suppose that my website is xyz.com and I have 3 clients "abc", "klm", "pqr"
and I want to give access to features of xyz.com under the link as follows
www.xyz.com/abc
www.xyz.com/klm
www.xyz.com/pqr
and Client abc has N users and I want to set 3 roles for every client's user role.
Is there any sample application in .NET that support this kind of website access per client having multiple users?
And If I use ASP.NET Membership will that be a suitable membership solution or Do I need to opt for any other type of Membership defined by my own or already available in open source market for .NET.
Edit:
All the clients will have same functionality. I would like to build a generic model for www.xyz.com/{whatever} so that in future if a new client want to register with me he/she just have to give client name and up on adding client name all the features avaiable to exising clients will be applicable.
of course you can have every sub-application it's own ASP.NET membership. or if you want the work out-of-the box solution for cms, you can try dotnetnuke community version and set the sub-website it's own settings
Related
I have to create an Authentication and Authorization environment for my ASP.NET CORE MVC Identity 2.1 application, with an API backend and IdentityServer4 as Authorization Server).
I have administrators
I have Projects.
Every user has to be in at least one project, except administrators.
I would give users a claim like "Role" and store something like "admin"/"user" in it.
Now it gets more complicated.
In every project, users have different roles, and sub roles and once again sub-roles of sub-roles (so, three tiers).
Currently, I solved the problem by using action filters and write them in front of each controller/method (where I see them fit). I also created tables for these three tiers, so that I can store which user is in which tier (and of course they have different access rights depending on that).
I also want the user to be able to have multiple projects open at the same time (in different browser tabs) so that they can switch between these as they desire. I currently solved this by sending the project id on every request in the URI.
I thought about using claims instead of my current action filter solution. I read a lot into that and watched the Microsoft Virtual Academy videos regarding this topic. But I fail to understand how I could use that in this scenario. Should I do claim requirements and copy the code from my action filters in them because claims identity can't handle my case by default?
Am I doing this completely wrong?
I am new to Web-Api, Cloud etc. I have some requirements with my project but as lots of resources are available over internet, I am not able to decide which way should i go.
Requirements:
The user should identify themselves with an authority (i.e facebook/google etc)
The users nameidentifier should be passed to our Web-API and stored in a database
Get the token/key that was given to us when the user authenticated themselves
Send the token in the header of every api-request and verify the users identity
It should run on a mobile client application (Windows phone, Android, iOS).
Question:
1) What is the simplest way to identify a client when using an external authority and then authorise the client when they call our web-api?
2) Is it possible to configure AD to use an external identity provider (i.e facebook, google) or can this only be done using ACS?
3) The only think needed is the nameidentifer (no name or email address, etc).
Relevant Links
Their Asp.Net Identity
Individual Accounts With WebApi-2
And there is something about Active Directory, all are claiming which i need but which one i should go for ? What are pro and cons ?
I have managed to define the Authorize attribute through the suggestions made by the following book: http://www.apress.com/9781430261759
You can download the source code from the above link, and chapter 8 or 9 can give you the solution that you are looking for!
We have a multi-tenant ASP.NET application. So far tenants have been isolated from each other, however now we have Agencies that manage multiple tenants and want to be able to manage all their tenants with a single user account. I'm trying to figure out the best way to accomplish that, hopefully without much change to the existing technologies that we are using.
Relevant technical details:
AspNetSqlMembershipProvider for both membership and roles
C# 4.0 (soon to be 4.5)
Forms Authentication
Both aspx and MVC (v3) pages
Assume 100 or more tenants, so any solution needs to support that
I believe the requirements are very similar to the security model for SQL Server. We have one set of logins which represent all the users that can login to the system. Users should be able to be given roles to one or more databases (tenants). Example: User Bob has admin role in company A, but only user role in company B. We also have a "sysadmin" role for my company's employees which allow us access to any tenant as well as specialized administrative privileges such as create/delete tenants, etc.
I've done a lot of research into various libraries, frameworks, etc, and I haven't found any convincing evidence that some other library or framework will be better than what we currently have. So I'm currently thinking of just figuring out how to make Sql Membership provider do what I want, unless someone can point me in a better direction. I'm also not sure I know the best terms to search for in this.
I've got 2 options I'm considering:
Add only a handful of roles to the membership provider and handle all the questions of "does the current user have this role in this tenant" outside of membership provider. Membership provider would be used to handle basic access to the system.
Add tenant specific roles to membership provider. We would have (# of roles) x (# of tenants) total roles in the system. Each new tenant would add another set of roles to the system, e.g. "Tenant A:Admin", "Tenant A:User", etc. Would need some additional tables to manage the relations as well as probably some custom code to ensure that access is requesting the correct tenant-specific role from the membership provider.
Are either of these options good? Or should I be looking elsewhere for support for this?
I don't think you are going to be able to shoehorn multitenancy into any out of the box role provider, so you might as well keep using SqlMembershipProvider (and SqlRoleProvider). Even the newest Microsoft.AspNet.Identity still assumes a vanilla many-to-many between users and roles. What you really need is to add a 3rd column to the primary key of that many-to-many table, which will id your tenant, i.e.:
user: 6
role: 4
tenant: 17
user: 6
role: 9
tenant: 18 (and so on)
...with this, you are able to have users with different privileges for different tenancies, all using the same set of role names.
If you went with option #2, then your [Authorize] attributes would explode. Imagine this:
[Authorize(Roles = "TenantA:Admin", "TenantB:Admin", ...)]
public ActionResult Post(int id, SomeViewModel model) {}
... all of those attributes would have to be written at compile time unless you went with a custom AuthorizeAttribute, which you could do. But even then you are left creating a new set of roles each time you add a tenant to the system, which should not be necessary.
I work on a big multi-tenancy application. We came to the conclusion that it was easier to maintain separate databases per tenant, and have the web application automatically switch database contexts, rather than try and use an over-complicated database schema to model different tenants.
The benefits
Tenant data is compartmentalized by default into different databases
Tenant data can be exported as a database dump for client MI
Database design is vastly simplified
The drawbacks
You have to manage multiple databases - operations challenge
You have to develop database switching code
Implementation using multiple databases
We used a configuration database that has client settings based on an account code. That account code can come from a login screen or you can map subdomain to client code.
When the app starts you load all tenants into cache (containing connection strings)
On every request you have to determine the client and then switch the db context
I have also developed a multi-tenant application that uses a single database. You quite quickly have problems making sure that you don't cross tenant data. Every query needs to include a tenant id filter. The database queries are therefore always slower as a result, although you can index everything you can to try and improve the situation.
With regards to the Membership question, you can install the membership schema into each tenant database.
What doesn't work
The ideal alternative would be to dynamically switch the ApplicationName, but although it seems to work, ApplicationName is not thread safe, therefore this would not be reliable:
Because a single default membership provider instance is used for all
of the requests served by an HttpApplication object, you can have
multiple requests executing concurrently and attempting to set the
ApplicationName property value. The ApplicationName property is not
thread safe for multiple writes, and changing the ApplicationName
property value can result in unexpected behavior for multiple users of
an application. We recommend that you avoid writing code that allows
users to set the ApplicationName property, unless you must. An example
of an application where setting the ApplicationName property may be
required is an administrative application that manages membership data
for multiple applications. Such an application should be a single-user
application and not a Web application.
Alternative: MembershipReboot
Multi-tenancy is hard in .Net. An open source alternative to using the built in Membership is to use MembershipReboot, written by Brock Allen. It has some excellent features including multi-tenant support out-of-the-box:
single- or multi-tenant account management
flexible account storage design (relational/SQL or object/NoSql), samples using both EF and RavenDB
claims-aware user identities
support for account registration, email verification, password reset, etc.
account lockout for multiple failed login attempts (password guessing)
extensible templating for email notifications
customizable username, password and email validation
notification system for account activity and updates (e.g. for auditing)
account linking with external identity providers (enterprise or social)
supports certificate based authentication
proper password storage (via PBKDF2)
configurable iterations
defaults to OWASP recommendations for iterations (e.g. 64K in year 2012)
two factor authentication support via mobile phone SMS messages or client certificates
The most common use case will be to integrate this into an ASP.NET or
ASP.NET MVC application, though the library can also be used over a
network as a service.
Alternative: ServiceStack REST
Another alternative if you are building modern web applications that heavily use JavaScript MVC frameworks such as AngularJS, EmberJS or BackboneJS is to use ServiceStack REST services. ServiceStack has a long list of Authentication features, and from my experience of SS, I find it has an extremely well thought out API model.
I'm working on a subscription data delivery webservice using C# and WCF. Customers will sign-up to use the service at different usage levels for a monthly fee. The project requirements call for the service to be accessible from a web app hosted on the same server, from a desktop app and Windows service distributed to customers and from a WordPress plugin. In the future, support may be added for other CMS systems and mobile (Apple/Android) apps.
The security requirements include a standard user ID and password authentication for each call to the service to verify subscription status and type and to track user activity. That's easy enough to do but there's more and that's what I'm looking for advice on.
First of all, there's the need to track IP addresses and use this information to control access. One part of this is to restrict the number of different IP addresses the service can be called from within a specific time period per ID and subscription type. The second part is to prevent access to the service from certain countries entirely. I've read some other answers here about how to implement IP address detection/tracking in general but I am more concerned about potential difficulties associated with this that others have encountered. What should we watch out for here?
The second major security requirement is to restrict access to the service to our provided desktop/service applications or from authorized domains using our CMS plugins. I'm not sure how this can be implemented other than using some sort of authentication token which of course could be easily hacked. Perhaps in combination with the login and IP address requirements this will be enough though. Are there any alternative methods that might be a better approach to take?
I'm currently developing a WFC RIA based Silverlight Business Application (intranet use only) for my company. I ran into a couple of problems when trying to authorize users. Here is the situation:
The app is running in our Windows domain and is therefore using Windows Authentication, which already works well. Access to certain domain service operations shall be restricted to members of a certain group (let's say "Admins"). This group is available locally on the server where the app is hosted and is already used to restrict access to the SQL Server instance. It will not be possible to add this group to the domain and make it available globally.
I know that I can restrict access to domain service methods via the RequiresRole[] attribute. The problem is, however, that the local group memberships of a user are not loaded into the user object that is available via WebContext.Current.User and therefore the authorization fails.
Is there any workaround or better way to do this?
Thanks in advance!
Have you tried setting the "PrincipalPermission" attribute on the service method you want to restrict?
[PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
public string GetResult()
{
return "result";
}
Best regards,
Arjen
I solved my issue.
What I did was to copy the AspnetDb database to the SQL Server instance on my server machine. This database is holding all the information about users, roles, etc and is used by the ASP.NET role manager for authorization purposes. This database is usually located in the project folder of your Web project (inside the App_Data directory). To make the new configuration work, you have to change the connection string inside your Web.config
(for more details: http://weblogs.asp.net/scottgu/archive/2005/08/25/423703.aspx).
I manually added new users to the database. The user name you enter there must match the Windows user name (eg. DOMAIN\USER_NAME). Then you can add new roles to the database and give all your users their specific roles.
The ASP.NET role manager automatically loads the roles/users on application startup and you can restrict access to your domain service methods via the RequiresRole[] attribute.
In addition, there is also a way to dynamically show/hide/enable/disable user controls based on role membership, see here: http://blogs.msdn.com/b/kylemc/archive/2010/05/04/authorization-sample-201.aspx