I am using MVC 4 Razor engine and selected the project template as Intranet. So it uses Windows Authentication. Currently I have designed a Database with Tables to maintain the users and the role that they belong to. I would like to show specific screens alone to specific users bases on the roles.
For Example: Add User, Create Role Screens to Admins alone. And the rest of the screens to Users of Non Admin Role & Admin Role.
Basically, I would like to Authorize the users based on the Roles as per the Database Table. How can I achieve this? Please let me know if there are any articles for this.
Thanks in Advance.
You talk in the title about Windows Authentication, which implies an Active Directory, and then you say you want to authenticate users against a database (forms authentication), please, correct your question.
Here is a full tutorial about forms authentication in mvc 4
https://msdn.microsoft.com/en-us/library/ff398049%28v=vs.100%29.aspx
Related
Suppose that I have a web application. Consider it like a Black-Box for now. I want to use a backend system to limit what a user can view/do on the app.
i.e. Sample users can only do three functions, Premium users can do 10 functions and see more pictures.
What is the best way to do it?
I'm trying to using WSO2 Identity Server, but it doesn't offer this functionality. So I've thought that maybe I can integrate it with the WSO2 API Manager and make an API that limits users' access to a certain resource. But really I cannot find if it's possible do it. Anyone know it?
Please refer to : https://docs.wso2.com/display/IS530/Access+Control+Concepts
1) WSO2IS can act as a coarse grained access manager. Your application will act as a fine grained access mnager.
It means that roles can be defined in WSO2IS, managed and assigned to user. From there Roles assigned to one user can be provided as clains with the identity token generated by WSO2IS and sent to the application.
The application, on the other side, will manage roles to permissions links.
Access control is then done at each request by the application, based on the roles presented in the Identity Token by the user and the Permissions grid based on roles in the application.
2) The access control at the application is a business logic you must implement (or at least configure if it a COTS). It is possible to outsource this logic to WSO2IS as policies on attribute (with Workflows).
Please look at : https://docs.wso2.com/display/IS530/XACML+Architecture
Jeff
I am using Piranha CMS , and i want to create multiple users in different group, i tried to do so but its not allowing me to login those users,even i have to implement that logged in user should only edit few pages which is permitted to that user. How can i restrict user to do so
The group permission system in Piranha CMS is hierarchical, this means that all users that should be able to log in to the manager should derive from the group admin.
When you have that set up you can take a look at the different permissions in the manager interface and assign these to different groups.
There are however no support to allow users to only edit certain pages, if you want that kind of behavior you'll have to implement it yourself in the available manager hooks.
Regards
I have an existing MVC project (purpose built customer portal) that I am integrating into Orchard CMS as a module.
The customer portal module has its own database containing user information, which I need to use for customer authentication.
However, I also want to retain Orchards user authentication for admin authentication to Orchard.
So essentially, I require two authentication schemes with two different login pages for this. One for customers and one for admins.
How could I implement this?
One solution might be to cancel the idea of having 2 differnt login pages and moving your users to Orchards user table.
Then link these users to a specific role named like My existing MVC users and grant permissions to this role accordingly.
If you take this route some of the benefits would be
bound to Orchards user database and therefore existing authentication handling
existing permission stuff can be used / extended out of the box
user management in one place
extensible by using own parts (e.g. AddressPart, ContactPart, ...)
Another solution would be to replace the existing authentication by implementing IAuthenticationService. But this seems rather complex.
Suppose I started with an ASP.NET5 MVC6 webapp based on a default Visual Studio 2015 web application template with individual user accounts and Google+ (FB, LI) authentication enabled.
Then I created two signup pages, one for consumer users and one for professionals. I want the application to create consumer user accounts if users came from consumer signup page. And I want the app to create professional user accounts if users came from the professional signup page.
What should I do to customize the default solution?
pass role parameter to /Accounts/ExternalLogin, then somehow preserve it through OAuth process and fix user creation logic?
same but use cookies to pass role info?
or maybe have 2 copies of external login infrastructure - each responsible for its own account type?
Isn't is a common problem - how to pass additional information to the code responsible for account creation?
What should I do to customize the default solution?
Quite good explanation with examples:
ASP.NET 5 Documentation -> Authorization
I want ... create consumer user accounts ... and ... create professional user accounts...
In my opinion you can use (create) one account type for all (in common Db) and then during registration process you can assign additional properties to this account. You can use Roles or Claims, so this allows you to personalise user experience depends on 'account type' (using Authorisation).
If you just want have only customer/professional accounts, probably Role-Based Authorisation will be simpler to use, however Claims-Based Authorisation is little bit more elastic and will be beneficial in the future.
I'm building a couple of ASP.NET MVC websites that will share a database (because they share data under the hood). That said, logins between sites will not be shared at the moment. For reference, I'm using NHibernate for data access with SQL Server under the hood (currently).
As currently laid out, the system has tables for Sites, Roles, Users, and Rights. Sites have sets of users, rights, and roles. Users can be in many roles. Roles have a set of rights. Users will be able to sign in with a username and password, but I don't want to paint myself into a corner - I might want them to be able to use a google or facebook login later.
Now, I'm a little confused as to which path to take with regard to securing the site. I'm not enamored of the old school membership and role providers for several reasons. Chief among these is that I won't be restricting very many things by roles; things will be restricted based on user access rights. I'm looking at the following few scenarios for authentication.
1) I want to be able to specify rights required to use a controller method via an attribute.
2) I want to be able to quickly query and see if a user is in a particular role or has a particular right.
So, I actually have a set of questions, but they are kind of intertangled. First, what should I do? Just a custom authorization attribute? Second, what's the workflow on login and the like? What are the steps required for this to work properly and securely?
I realize these are sort of noobish questions, but in the past I've gotten by with the old provider way of doing things. I don't particularly care for that and would really like some better suggestions. So I guess everything old is new again for me.
I would flee the Membership provider from MS like the pest. It was already badly implemented when it came out with .NET 2.0, and the recent refresh is no better.
Roles, Users, ..that's not bound to the Membership provider, you can use those on your own. Set up Authentification, create a httmodule that handles said Authentification (a simple userId for the Context.User.Identity suffices)
All you need is a User that derives from IIdentity and in your httmodule
string[] roles = new[] {"Admin", "CoolDude"};
HttpContext.Current.User = new System.Security.Principal.GenericPrincipal(user, roles);
..and now in your mvc controller simply add the necessary authentication attributes, game played !
Make custom roles, custom mvc attributes, or query if a user is in a specific role directly
if (HttpContext.Current.User.IsInRole("Admin")) { ...