Integrating CSLA Authorization with DotNetNuke Roles - authentication

I am interested if anyone has experience using DotNetNuke authorization in CSLA.
I would like to be able to use my DotNetNuke roles to be able to assign permissions to my CSLA objects and properties. If I just reference the DNN assemblies won't that create an unwanted dependency in my CSLA business objects?
Would it be easier to build CSLA objects that query the DNN database directly to get role membership?
Thanks...

You definately do not want to create that dependency with your DNN assembly. Your second suggestion is the way to go.
CSLA uses standard IPrincipal/IIdentity authentication. You can create an object that inherits from the CSLA.Security.BusinessPrincipalBase which uses a CSLA object (e.g. User) that grabs their roles from the DNN database directly. Once you have that authentication integrated, you can place your roles inside your business objects by overriding the AddAuthorizationRules method.

Related

What is the best way to implement different User Roles/Permissions depending on "Project"?

Our current API leverages ASP.Net Identity and Policy Based permissions for Authorization. It uses User Roles as claims for this. These claims are intercepted by a ClaimsTransformer class and the user permissions are read from a database containing the user mappings (cached). This all works fine.
The problem I'm having is with the API's scope expanding to include different "Projects", such that for instance, a User can be a Creator in one project but a Consumer in another. Is there a way to reconcile these requirements with .NET Core's Role/Policy based Authorization? Or is the best approach here to query the Database for these permissions upon each request?
Authorization is hard and a good starting point is to watch this video:
Implementing authorization in web applications and APIs.
Then using the policies and requirements is how I would approach this and this resource is a good reference:
Custom authorisation policies and requirements in ASP.NET Core
The picture below shows how the concept of requirements work in ASP.Net Core where you can define a requirement and then have one or many handlers independently "vote" if the user is approved or not.

Custom Role based authentication

I have a very complex requirements to implement the roles and permissions in my asp.net mvc 4 application. I know about ASP.NET Identity authentication but that does not fit into my requirements.
I have 15-20 controllers in my applications which have their respective views, some of views have partial views which are being handled in Jquery code and loaded from there.
Now I have below requirements:
1)Some of controller are accessible to a perticular role(s) only.
1) Some of views in a controller are accessible to a perticular role(s) only.
2) In a view for a Grids only some of columns and actions like Edit/Create/Delete are accessible to a perticular role(s) only.
I am thinking to implement checks on controller , actions and views on the basis of role but that can lead into a problem when I have multiple roles and custom roles in future. What can be best way to implement this kind of solutions. Any suggestions will be appreciated.
Every time you have "complex" authorization requirements, it's a pretty good indication that "identity-centric" access control is not enough. What's identity-centric? Authorization that relies on user metrics (identity, role, group) only.
Also, in your question, you list the fact that you do not know what the future holds. You do not know what other custom roles you need to implement.
All this means you need to extend your existing RBAC implementation with attribute-based access control (abac). ABAC gives you 3 interesting elements which you do not have in RBAC:
A policy language. You can express complex authorization challenges using this policy language (either of xacml or alfa). In particular you can express things like Permit if user department==record department.
An architecture: the architecture identifies key components with specific responsibilities. For instance, you have a Policy Decision Point (PDP) which produces authorization decisions. You have a Policy Enforcement Point (PEP) which is the piece that sits in front of or inside your application. The PEP protects the application.
a Request / Response scheme between the PEP and the PDP. The standard format is a Yes/No question as shown in the diagram below. JSON can be used to encode the requests.
From your point of view, you have two options. Either:
Implement claims-based authorization. This is available OOTB in .NET
Bring in XACML. I'm not sure .NET has any native libraries but there are SDKs out there.

Migrating from ASP.NET WebForms to ASP.NET MVC 4

I'm a student intern and I've been assigned a project where I have to redesign their customer support webpage. I am new to ASP so they asked me to migrate the code to MVC 4 so I'll learn it for future projects.
The webpage has form authentication using custom classes, extending MembershipProvider and RoleProvider and the data is displayed with asp:SqlDataSource queries, defined directly inside .aspx files.
As I've learned, the point of MVC is to separate the front-end (view), controller and back-end (models, db access). I've done some progress towards that, but I have problems at authentication. I've managed to enable login using explicit MembershipProvider and RoleProvider initialization (which should be done automatically as configured in Web.config). With calling the MembershipProvider.ValidateUser() and FormsAuthentication.RedirectFromLoginPage() I verify user details and store their username to preserve it upon navigation.
This works, but removes all the functionality of WebSecurity methods, also the specific authorization, e.g. [Authorize(Roles = "...")], doesn't work as expected, it doesn't authorize any role. The MVC sample project in Visual studio uses SimpleMembershipProvider for user authentication, but I haven't found any projects or tutorials on how to implement custom authentication same way as I did with extending MembershipProvider class and overriding its methods.
The problem is that there is already a T-SQL database with a lot of users, who are linked to other services, so obviously I can't alter it in any way nor can I create new database / tables. The projects I've looked at create databases from scratch, I haven't found any project using custom authentication / authorization using WebSecurity and existing database.
I'd like to ask you for any advices, examples or links to projects or tutorials where I could see how to implement WebSecurity instead of FormsAuthentication. As I've mentioned, I already have a fully functional MembershipProvider and RoleProvider and I belive that SimpleMembershipProvider and SimpleRoleProvider have similar methods, so it shouldn't be that hard on this part. Also, I don't want to mix Webforms and MVC, I want pure MVC application.
I'm using ASP.NET MVC 4 with C# and Razor engine, T-SQL and LINQ to SQL for database access.
It's been my experience, when migrating old pages from webforms to mvc, that you kind of have to 'forget' that it was ever a webform page to begin with.
to more directly answer your request for help resources, maybe this will be useful: http://kylehodgson.com/2013/01/08/asp-netmvc-web-security-basics-csrf/

Advantages of using Yii rights?

In addition to creating RbAC file, what is the other advantages of Yii Rights module? What the Yii rights module does that Yii RbAC doesn't support?
Allows to manage access in backend: create roles on the fly and attache it to user.
Role access has weak binding with code because is based on module-controller-action-oriented permissions that you can give to user. That all can be managed with backend interface on the fly.
Has task (not role) oriented access - when you can create custom task (text editing for example) and base your logic on permissions to tasks instead of roles
You can find answers to all of those questions here: http://www.yiiframework.com/extension/rights/
Basically, everything you can do with Rights, you can do with RbAC, but Rights makes it all easier to manage.

Where should I put CAS session checking code in a CakePHP application?

I work for a department of a university that uses CAS to provide single-sign-on authentication, and am writing a CakePHP application that needs to use this CAS service. I need to write code that:
Checks with the CAS server to see if the user is logged in
Pulls some credentials from the server if so
Checks the credentials against an internal ACL, as the set of people who can access the application is a subset of the set that can log into the CAS service.
Provides some mechanism for admin users, either by creating special admin users outside the CAS system (with all the headaches that would entail) or by promoting certain CAS users (with the different headaches that would entail).
As a relative newcomer to CakePHP, I frequently struggle with where to stick code that "doesn't belong". The best I can figure is that this code ought to go in the beforeFilter method of the App Controller, but I wonder, is this the best place for it? Also, is it too low in the stack to take advantage of admin routing?
Lastly, I know that CakePHP provides both Auth and ACL components, but when I looked into using them they did not appear amenable to interfacing with outside authentication services. Am I wrong, and would either of these be a good fit for what I need to do?
Thanks!
If you take a look at the Cake's core components you can see that your CAS requirement fits with the type of things components are typically used for (ie. auth/session).
I would recommend creating a CasAuthComponent. There is some information on extending AuthComponent, in a previous answer of mine, which may prove useful if you wish to build on top of the existing core AuthComponent.
A component (essentially reusable controller code) can interact with models, use other components (such as Session) and control user flow (redirects for example)
Note that, the core AuthComponent actually retrieves information from a model (the User model by default), so you could do something similar.
The CasAuthComponent you create could $use an external user model (CasUser maybe) which is responsible for CRUD operations on the data (retrieving users mainly).
You could take this one step further and abstract CAS interactions into a datasource used by this model, but it isn't strictly neccessary if you don't plan on reusing the code in other models.
The end result could be packaged into a plugin:
CasAuthComponent (app/plugins/cas/controllers/components/cas_auth.php)
CasUser (app/plugins/cas/models/cas_user.php)
CasSource (app/plugins/cas/models/datasources/cas_source.php) [optional]
And used in your application by putting the following in your app_controller:
public $components = array('Cas.CasAuthComponent');
If you wish to be able to administer the users from Cake, you can also include a controller and views in your plugin, which allow the user to interact with the CasUser model (ie. $this->CasUser->save()).