I need to be able to tighten my business layer - access to particular data.
The UI can make a call to the business layer and receive a userdetail. The UI can then call .Save() on a user and the business layer will call the data access layer to save the user.
Although, the problem here is that I don't just want any user to be able to receive a userdetail and call save - only authenticated users with that role of "admin". How would I go about this authentication/authorisation in my business layer/UI so I can achieve this?
I am using ASP.NET for my UI, and I've read into membership/role providers, but this just seems to be for the actual UI. I need to secure it at my business layer because in the future there could be a couple of different UI's. e.g. windows forms and Asp.net.
Thoughts and suggestions are appreciated.
Thanks.
Another approach you might want to research (if developing in .NET 3.5 / 4.0) is using Windows Identity Foundation.
If you are insterested in keeping your authorization logic outside your web site (which I assume you would if you are expecting to use your business layer from more than 1 front-end) I would definitely recommend yaking a look at WIF. You can also integrate with Active Directory using ADFS v2.0 (which is a server role in Windows Server 2008 R2).
Patterns & Practices has released a guide which can be quite useful for digging into the subject.
The ASP.NET Role / Membership providers include storage and code level components you can re-use - they aren't just the UI.
For fine-grained access control (for example to specific functionality on a page) you can use the Enterprise Libraries. You'll be able to re-use code to protect functionality both at the BL layer and in the UI layer.
The link you most want is this one: Determining Whether a User Is Authorized to Perform a Task
Also see:
What Does the Security Application Block Do?
DotNetJohn - Enterprise Library Security Block...
Rule Based Security using Microsoft Enterprise Library and CAS
During earlier releases of the EntLibs, the Authorization Manager was a key component, but in more recent versions it's not a firm requirement, instead you can use an AuthorizationRuleProvider.
see: Developing Applications Using Windows Authorization Manager.
Filtering data is a bit more problematic depending on the complexity of your data, the amount of it and performance needs.
One strategy is to have a simple DAL that returns everything, and prune out data the current user isn't allowed to see in the BL.
Design a DAL that has some knowlegde of the roles your application uses:
DAL.GetCustomersForAdmin() and DAL.GetCustomersForMember() But this is a bit dangerous as you'll be tied to using those roles.
Have a database / DAL that is security aware, and always returns only the data the user is permitted to see, via the same methods: DAL.GetCustomers()
Related
I'm building a core mvc application to support several sub applications so they can run on several IIS servers
I don't like using EF much due to the complications of the migration especially in production, therefore I need to write my own User handling mechanism and I'd like to know what are my best options if I need to have a massive role or authorization checks that might reach to thousands of roles. I need to secure stuff like:
APIs
Controllers
Clients or Whole MVC/JS Web Apps and Mobile Devices Clients
User Specific access (ex: User can access his own division data, some with read some with write)
.. and lots of lots of authorization scenarios that will work with (User.IsInRole method or the Authorize Attribute) across this multi-server/domain solution.
I need your guidance on how to achieve this following the best practices.
Regarding not using EF. All the "stores" in IDS4 are abstractions so you can implement your own for each IDS4 entity (rather than using the EF bolt on) and likewise you can implement your own IProfileService and IClaimsService to use whatever backend you'd like.
We are currently building a RESTful API(.Net Core, IdentityServer 4, EF6). We have released an MVP version of it.
It also references a WCF service. This WCF service orchestrates all other calls to other internal (Legacy systems) and other integration components.
(Possibly wrong) Overview diagram of the implementation is as follows:
One of the main things we are stuck with is figuring out how to integrate different authentication and authorization systems using Identity Server...
Particularly internal service to service calls. Do we use the same IdentityServer to perform multiple functions?(public consumer authorisation & authentication AND internal service-to-service authorisation).
Traditionally we have used different WCF security configurations (Transport, TransportWithMessageCredentials...and so on), adding Forms, AD, ADFS and Service Accounts. We need to be sure we are making the right calls for making a reusable IdentiyServer implementation.
In short, Our challenge is how do you perform internal service authorization?
Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?
Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?
Or do we even go further as to split and create a different identity server for each application use case?
Here are my thoughts on a solid implementation plan.
Is it good practice to have a central Identity Server implementation that handles both public facing requests and internal (multihop)service-to-service authorization?
Reasons to have shared implementation:
Simpler Solution
Reasons to have separate implementation:
Different security requirements for external vs. internal users/clients
External Outage wouldn't impact internal users/clients
Recommendation:
In the short term use an implementation that will service both with the goal
to split them out into External and Internal focus areas.
Do you recommend splitting and having separate identity servers for internal service-to-service authorization from those that handle public-facing API requests?
Recommendation:
Long term yes. See above as to why.
Or do we even go further as to split and create a different identity server for each application use case?
Recommendation:
No, creating an separate identity server for each client/use case would be harder to manage in the long term. You would create separate clients for each application/scenario. (i.e. Mobile Client, MVC web site, Internal Server to Internal Server, External API/Service to Internal API/Service [Think of B2B interfaces])
You will want to learn about the client types and how to allow extension grants, which is when a clients credentials to be used when a direct API call needs to call a secondary API as the user.
First off I would say you are going to have to bang your head on the wall a lot.
I think an ideal situation is where you only support one Identity Provider such as Active Directory. Microsoft would have you believe their solution is easy but it is not. That is why if you have to support a legacy Identity provider as well as a new system in parallel you will suffer more.
A secondary solution would be to keep the legacy Identity Provider system and implement the new API through it. I guess it must be a custom solution that is hosted on your own resources. That has the disadvantage to come with no built in capabilities and every new need must be built from scratch.
Honestly if you can isolate the legacy (or remove it) from your new system you will get huge benefits long term for maintenance and malleability.
I would look at code samples before making a decision. Better know deal breakers before spending weeks in any direction.
Here's my point of view for above problem
A Separate Identity Server for internal service
There are more pros in separation of identity server for internal service i.e.
Outage & Configuration changes in future won't affect consumers.
For Testing Purpose, a separate identity server is best if you are trying to support legacy applications
New Server has long term benefits & Security Enhancements.
I am building a plugin for multiple .NET based solutions. The application it self will connect to a database that holds user data and user group data, as well as some configuration files that users create for them selves. The configurations may also be shared between users (the owner can share his configurations with another user), and administrators will be able to edit all permissions on all files(my guess is via some web interface).
The applications that will have access to the functionality of this plugin are using the .NET platform but after that the projects diverge. One is using old win forms, the other WPF for desktop and another is web based using a JavaScript library. All the aforementioned applications are just interfaces for a shared lib that contains actual business logic.
My plugin will be implemented within the shared business logic library. The app will support both username and password authentication as well as windows authentication(if win auth fails the all will ask for username and password to try to access data that way).
My options regarding membership and authentication/authorization are plentiful and I'm not sure of my choice. I can use the Membership library or the new Identity library. I am also sure there are 3rd party libs that are quite good at this stuff but I have yet to hear of them.
is there a preferred lib to use or is the choice trivial and i should just start from somewhere?
This is a great place to start: http://brockallen.com/category/membershipreboot/
I would like to know if it’s possible to do use authentication in Silverlight 5 without having to use RIA Services. I am using Entity Framework to connect to my database. I am also using the Business Application template. I have created a custom membership provider through which I am able to validate user credentials and can add new users. However, if I want to restrict content on the app based on which user is logged on, I have no way of doing. I believe that if I create a RIA Services Domain Context I can potentially check user information via WebContext.Current.User. Is there a way to get this type of information without RIA? Perhaps a WCF service of some sort?
Once I wrote a tutorial on how to share forms authentication between your web app and a silverlight app. This works without ria, uses guarded wcf. You can even fine tune the access to individual roles.
http://netpl.blogspot.com/2010/04/aspnet-forms-authentication-sharing-for.html
I am currently working with an enterprise application in a .NET environment (n-layered) and I would like to know the best way to manage authentication / authorization + data filtering in my BussinessLayer (BL). We will use that BL from several interfaces (ASP.NET applications and WebServices) and I think that my ServiceLayer should do the job but I just can't find the best way.
I suppose it could be something like this:
(1) User gets authenticated (ASP.NET web client), perhaps using FormsAuthentication.
(2) ASP .NET code (Controller / CodeBehind) instanciate a Service to get some user case done, passing somehow the 'User'.
(3) Service method checks if 'User' exists (authentication) and his roles (authorization) to verify that he can call that method. If not authenticated or authorized an exception is thrown.
(4) Service uses repositories + other services + whatever it needs to get the job done. If some kind of fine-grain filtering is required (for example the User only has permissions over some projects) the service applies it automatically.
What I want is to get a ServiceLayer isolated from 'the web stuff' (not accesing session...) but who knows the User calling its methods to act correctly. Also I don't know how to match that work with ASP .NET authentication in a good manner...
I am thinking in suministrating the 'User' in the Service ctor, so that its methods have the 'context' they need, could that work?... I would appreciate some indications or existing code snippets on that.
Thank you for your help...
First of all, Authentication and Authorization are two separate things. Your question implies that you already know this, but I just wanted to be explicit about it.
Authentication should happen at the application boundary (e.g. Forms Authentication in a web application).
The default approach is that the Authentication module sets Thread.CurrentPrincipal upon successful authentication.
In general, IPrincipal is the standard basis for modeling user context in .NET. For example, HttpContext.User is an IPrincipal.
In your Domain Model and Data Access modules, you can use Thread.CurrentPrincipal to implement Authorization logic. This allows you to vary Authentication and Authorization independently of each other.
For me, I think it is both simpler, and more extensible if you let the client layers (your website/services) do the authentication and leave the BL to contain just the business logic.
If you need a reference to the current user in the BL, you could consider an interface to 'wrap' some of the user identity information and this could be passed from the various UI layers.