does anybody knows about Java/C# database independent authorization library. This library should support read, write, delete, insert actions across company organizational structure.
Something like this:
- user can see all documents
- user can enter new document assigned to his unit
- user can change all documents assigned to his unit and all subordinate units.
- user can delete documents that are assigned to him
I should also be able to create custom actions (besides read, write,...) connect them to certain class and assign that "security token" to user (e.g. document.expire).
If there aren't any either free or commercial libraries, is there a book that could be useful in implementing this functionality?
Thanks.
I, too, am surprised at the lack of security frameworks.
There is Rhino Security. Ayende has a handful of blog posts about it.
Another blog has a couple of articles on it, too.
It is possible to use it with S#arp Architecture as well.
Can't say I've implemented it in a project, just read up on it a while back. It was the only implementation of its sort that I could find.
I found one library that has functionality similar to my needs:
http://www.codeproject.com/KB/database/AFCAS.aspx
It is strange that there aren't any more of it on web since this is a problem that every serious application faces. As for documentation/example, the best I found are authorization modules of CRM systems like:
- Siebel - Siebel security guide - Chapter 10.Access Control
- Sugar CRM - http://www.sugarcrm.com/crm/products/capabilities/administration/access.html
- Microsoft CRM - http://msdn.microsoft.com/en-us/library/ms955698.aspx
That is a kind of functionality I need. I guess it will be DIY task.
The problem with implementing your security solution in your client library is that it is only effective with the client tool. That sounds pretty DUH on it's own, but you leave open the huge security hole that is the database itself. So if a user connects directly to a database (for example using an Access ADP to SQL Server) they have full control to whatever their user role is. Which they would need full access to everything in the database, if you are doing your restrictions in the client library.
The only case where this wouldn't be as big an issue would be with web applications and web services. If your web service did the security and hid it behind the web service interface (so there was no direct access to the database), then it would be safe. This may be what you're talking about, but didn't specify in your question.
If you are using a fat client, is there a reason why wouldn't want to put the security logic in the database side? You mentioned database independent, but nothing you specified would be difficult to provide in each platform. You basically are describing pre-/post- triggers that check if a user has rights to edit a record. A full RLS would also restrict the user's rights to view and make things slightly more difficult depending on platform.
Related
Basically, I have a new desktop application my team and I are working on that will run on Windows 7 desktops on our manufacturing floor. This program will be used fairly heavily as it gets introduced and will need to interact with our manufacturing database. I would estimate there will (eventually) be around 100 - 200 machines running this application at the same time.
We're lucky here, we get to do everything from scratch, so we define the database, any web services, the program design, and any interaction between the aforementioned.
As it is right now, our legacy applications just have direct access to a database, which is icky. We want to not do that with the new application.
So my question is, how do I do this? Vague, I know, but basically I have a lot at my disposal here, and I'm not entirely sure what the right direction to go is.
My initial thought, based on what I've perceived others doing, is to basically wall off the database by using webservices. i.e. all database interactions from the floor MUST occur through the webservices, providing a layer of security by doing much of the database logic behind closed doors. Webservice calls are then secured to individual users via Active Directory.
As I've found though, that has some implications of its own... We have to abstract the data before it reaches the application. There's still potential for malicious abuse by using webservice calls repeatedly to ruin or spam data. We've looked at Entity Framework and really like what it provides, but as best I can tell, that's going to be unavailable by the time we're at the application level in this instance.
It just seems like I can't come to a conclusion on what is "right". So, what is right?
WebServices sounds like a right approach. Implementing a SOA-oriented layer on the webservices layer gives you a lot of control over what happens to the data at the database server.
I don't quite share your doubts about repeated calls doing any damage - first you can have an audit log of every single call so that detecting possible misuses is obvious. But you also could implement a role based security so that web service methods are exposed to users in roles, which means that not everyone will be able to call just any method.
You could even secure your webservices with forms authentication so that authentication is done against any datasource, not only the active directory.
And last thing, the application itself could be published as a ClickOnce application so that it is downloaded and executed from the web page and it automatically updates itself just as you publish new versions.
If you need some technical guidance, I've blogged on that years ago:
http://netpl.blogspot.com/2008/02/clickonce-webservice-and-shared-forms.html
My suggestion since you are greenfield is to use an API wrapper approach with Servicestack.
Check out: http://www.servicestack.net/ServiceStack.Northwind/
Doing that you can use servicestack authentication, abstract away your db layer (because you could move to a different DB provider, change its location, provide queues for work items etc...) and in time perhaps move your whole infrastructure to an internal intranet app.
Plus Servicestack is incredibly fast, interoperable with almost any protocol you through at it, and provides for running it through MONO, so you are not stuck with a MS backend that could be very expensive.
My two cents. :)
First of all this question is not appropiate for StackOverflow, you might get close-votes really quickly.
Second, You may want to have a look at WCF RIA Services for this.
These will allow you to create basic CRUD operations for all your entities, and stuff like that.
I never used this myself, no I'm not sure what the potential issues might be.
Otherwise, Just do what we did:
Create generic (<T>) interfaces and services and contracts and everything. This will allow you to adapt your CRUD functionality in your Services, DAOs, ViewModels and such to any entity type.
I'm trying to secure certain information in MS-CRM. What is the best approach to restrict a user from reading everybody's e-mails or reading certain contacts?
Is this done on the UI or by .NET code. I've researched the security model MS-CRM but cant find a decent example or small walk-through to get started.
Any help is appreciated. Thanks.
EDIT:
I've been interacting very litlle with MSCRM, mainly thru code, using SDK. It may be my unexperience with the UI and the system in general.
We need to secure thousands of emails from users accounts and a few contacts. There seems to be many ways to implement the security, such as for example the 2 links below.
http://dynamics2011.blogspot.com/2012/04/crm-2011-utilizing-role-based-security.html
-CRM 2011 using roles, teams, and business units seems "easier" than below
http://www.powerobjects.com/blog/2012/07/27/making-crm-records-private/
-CRM 2011 using roles, teams, and business units (this has 2 options)
Any idea on which would be a better?, or maybe someone has another idea. I'm looking for something simple.
With respect hagensoft, (and don't take this as harshly as it may sound) I'm not sure how you can be confused over whether security is implemented via UI or .Net code if you've researched the chapter you link to (It's via UI). I say this, as I'm not sure what can be told to you, that isn't already behind that link (or linked directly from it).
Users have roles. The sum of roles determines a user's permissions and access rights. Roles can restrict access to records either wholesale or depending on the ownership of the record to be secured (therefore depending on the highest privilege you have for that record type, a record owned by you, a co-worker in the same business unit, a parent business unit or anywhere in the organisation may be accessible to you).
Perhaps you can describe what you've tried to do and what is specifically causing problems...
In the production process of an internal-use ASP.NET/C# website, are there any advantages to starting with authentication/authorization/login FIRST, and building up from there? Or is it better to just build your site exactly how you want it, with unlimited restrictions and no logins or anything, and then do that at the end of production, before release? That's what I WANT to do --- just work on the functionality of the website, unrestricted, having one less thing to worry about. But I want to make sure that this approach doesn't cause problems later.
When it comes time to implement the ASP.NET authentication, it should just be a matter of running the script to generate the necessary tables and then using WSAT to manage the users and then provide restrictions to the already-existing content...should be...
You need to give your security consideration right up front. Even if you don't develop the final login screens and restrict access as you develop, IMO you should make sure that you can authenticate your users and limit access on at least one screen before going ahead with 'god mode' development. Include:
Authentication - Windows, Forms, etc.
Authorization / Access Control - will Role do or do you need Operation-level checking - e.g. AzMan
If you will be using SiteMap, you will need to look at security trimming to hide functionality to which the user doesn't have access (menus, breadcrumbs etc)
Auditing - e.g. changes to important data
Even though the site is for internal use, users can't be trusted, and you will need to ensure that you are safe from SQL Injection, XSS etc as well.
Definitely yes, that is the practical approach. You, said it, adding security creates no problem at all to an existing project.
Infact, when you come to securing the site there are a number of procedures before creating users. Also you shouldn't rely fully on WAT for user management it is better, I think, to have your own interface as you'll need it after deployment.
Your approach may sound faster but it have architectural drawbacks in following areas:
1- Missing security alignment with per page / per method level invocation.
2- Not clear Use case and work flow in terms of authentication / authorization.
3- Complete lack of security based testing while developing and adding up the new features gradually.
4- Lack of End-to-end dependency- What if security needs to be considered across layers, you will miss the whole vision on modular dependency and end-to-end testing.
Overall, if you do it 1st then you can just have one sample user/pwd/roles established and use that for all the secure areas of site, this will be sufficient to test and develop the application continuously.
Later when your application is ready; it's good to go with large number of user/pwd and associated roles to work with.
Hope this helps.
We are currently building architecture for thin-client bookkeeping application. It should follow two main requirements:
Application should have module design. Each module can have (and they actually do have) own Role system.
Later application should be adapted for running using different databases on different machines.
We think Asp.NET MVC 3 is appropriate platform for this task. For managing application data we chosen latest version of Entity Framework - its batch of Data Providers and Code First feature can save us much time.
The part we are tangled with is user/role management system. We should have some kind of Global Administration section for adding users and giving them access to modules (only global admins can add user to the system, no "guy from street" registration supported) and each module has its own administration section with its own admins and roles. We already have data model to store everything we need in appropriate way but have no idea how to access this data correctly from application.
Currently we see two possible ways to resolve this problem:
To write custom Membership and Role providers based on our DAL. Nobody from our team have done this before so we are not sure if this way worth the trouble. Membership provider cant offer as much flexibility as application needs so some crunches would be needed.
To dig through some obsolete books to find out how web sites administration system was organized before Membership providers where created.
Both this ways are not elegant and not obvious for us and its not an easy question which way to choose. Also we do believe that it can be other solution (of cause architecture can be affected). So, we would be glad to see any suggestion connected to this problem.
I'd personally recommend using the standard membership provider for creating and authenticating users in the first place, and then once you've verified that the user isn't just some "guy from the street," use your own custom architecture to verify that the authenticated user has access to the controller and action that they're trying to access.
The built-in membership provider takes care of a lot of nuances with regard to user authentication, password storage, and such. It uses best practices to avoid brute force attacks, rainbow table attacks, etc. It's tried and true.
But it sounds like your per-module permission structure may or may not fit the mold of the ASP.NET Role Providers. If they do, that's all well and good, and it'd be a good idea to implement a custom role provider. But if your needs are "outside the box," you'll probably be better off just manually checking rights at the point that's most appropriate for you (controller, action, request filter, etc.).
I would encourage you to use a custom membership provider. Why? Cause its the standard way and will save you tons of works. It's not as hard as I might see and there are tons of resources like this one.
To write custom Membership and Role providers based on our DAL.
Nobody from our team have done this before so we are not sure if this
way worth the trouble. Membership provider cant offer as much
flexibility as application needs so some crunches would be needed.
It is very much worth the trouble, if the default ones do not provide the functionality you need. If you already have a complex user system in your database, a custom membership provider is probably a good idea.
It will add valuable experience to your team, and you should be able to reuse much of the code in your next project. As #Randolf mentioned, there are loads of good resources for building a customer Membership provider, and I speak from some experience when I say that it is not really all that difficult. Everything is there, you just need to implement some methods.
Well, finally we decided write all from scratch and it was easier that it seemed to be
Add own IPrincipal implementation. Additional fields and completely different logic for IsInRole() method to avoid writing own attributes.
Assigning our IPrincipal in Global.ajax event to User.
It wasn`t hard at all. Now we have all the flexibility we wanted. No providers involved.
I'm currently building an ASP.NET MVC web application. My site security is (currently) built atop an extension of the System.Web.Security Membership model where I've extended:
AuthorizeAttribute
MembershipProvider
RoleProvider
This has sufficed for the security mechanism - although it has complicated a lot of things I could probably have done more simply. However, it's done and it was a very useful learning experience. Although at a later point, I may still rip it all out and replace it with a model that is more specific to the site - I'd like to keep all my user profile information in a single table indexed and built specifically for the site.
Now I've moved onto development of the user personal profiles. I need to store a lot more user information than for the basic user log-in system. I've checked out the ProfileProvider which seems like it's a whole different can of worms. I like that it's flexible enough that I can configure user profiles right from the web.config without having to rebuild my objects and the ProfileProvider handles the rest. What horrifies me though is the PITA this causes to run queries or reporting on my database. This fact is probably clouding my judgment against the ProfileProvider. Is the ProfileProvider even the right model to be using for this?
Should I go down the same road I did with the customization of the existing system or custom build my own system?
On one side, it going down the customization of the ProfileProvider could be a useful learning experience but on the other hand, I can see this rapidly becoming a reporting and querying nightmare. But coding my own is going to make querying/reporting very simple but I'm not going to learn much less.
If anyone has any experience with use of or customization of the ProfileProvider model (if that indeed is what I should be using) and can either point me in the direction of useful reading material or can steer me in a more useful direction I would really appreciate it.
Thanks in advance.
I read in some books and many blogs that the way to go was to implement your own MembershipProvider, RoleProvider and ProfileProvider based on the base class that Microsoft provides, and that's what I did. But at the end, I ended up changing all that code to my own custom-based security schema, which gives me all the flexibility I require.
The problem is that those providers make a lot of assumptions that might not accommodate to your system. For example, the create method of the MembershipProvider requires question and answer as parameters (which I didn't require) or if you need another attribute, it starts becoming cumbersome to code and maintain.. And let's not talk about testing it...
Like you said, the learning experience is always good, but the amount of code that I had to maintain to make it fit my needs was not worth it.
As for the AuthorizeAttributte, what I did was I created my own filters that fit my own security schema.
My advise? If your requirements fit what Microsoft thinks a ProfileProvider should look like, go for it. If not, build your own. You can copy some of the practices they execute, but it gives you the freedom to change wherever you have to.
I use tables in the database to implement security. A table-based approach is simple to implement, easy to understand, and provides for security trimming by simply joining the table to the table of items to be trimmed. Reporting is straightforward, and table-based security can be used for roles as well.
I just found the existing security model in ASP.NET MVC to be cumbersome, and it didn't do some of the things I needed it to do. In particular, it's difficult to apply attributes on things like document records that require access to an ID from the database, because you wind up looking the record up twice; once in the attribute class, and once in the repository for the controller method.
All other things being equal, I would rather maintain one security system than two. So I use the built-in security to authenticate the users, but after that I switch to table-based security.