I'm trying to get a handle on all the various techniques of implementing custom authorization within a traditional ASP.NET application - it seems that the preferred approach is to use the Membership API by creating a custom provider model.
I'm interested in implementing a custom roles authorization model based on a combination of roles and individual permissions (a role is comprised of permissions and a user can have multiple roles or specific permissions which override whatever permissions the roles might have)
What is the advantage or disadvantage of creating a full-fledged Roles provider vs implementing a custom principal object and implementing all the authorization logic in overloads of the IsInRole method? Are custom principals a deprecated technique stemming back to 1.1? In general, when are you supposed to implement a custom principal?
We are using Active Directory as the user store. A third party consulting firm has implemented a TERRIBLE custom roles-based authorization module that contains authorization logic and rules contained in an XML file and passed around in the Session object for each user and does not tie in whatsoever with the ASP.NET infrastructure for authorization.
I'd like to know what the best practice for this would be
I would advise to stick with the asp.net membership and role provider architecture. It integrates well, and is a good thought out system.
If you need to use another account store then the asp.net membership or active directory you can always implement a custom membership and/or role provider. This is not hard.
It may be possible to wrap the custom third party system in a custom role provider, but i only would go custom if you have special needs that aren't provided in the given classes.
this video may be interesting
Related
I was thinking about ways to handle nicely parts/pages/features of a Blazor WebApp based on which subscription tiers a user belongs.
First that came in mind is the native use of <AuthorizeView> with Roles as the main distinguiscer(so other than the normal "user" role it could be concatenated with "professional", "business" or "enterprise".
But I was wondering: is there any other alternative?
I'd suggest you to use the newer, and recommended, policy-based authorization with Blazor. Role-based authorization had been popular in Asp.Net, and it is becoming obsolete. It is enabled in .NET Core mainly because of compatibility reasons. But even Role-based authorization, in .NET Core, is implemented via claims.
The way to go is policy-based authorization. It is much easier to manage than Role-based authorization... and you can easily integrate it with the AuthorizeView component and the Authorize attribute. There are other issues with the Role-based authorization, which is demanding and requires you to write code, as for instance, Blazor expects to get a list of roles as in the following: Authorize[Roles="role1, role2, role3"], while identity server sends a single claim which is made of three roles. Consequently, you'll need to extract the roles and provide it to Blazor in the form of a list. This requires lots of work, and knowledge. OK..., I won't confuse you any further. Just forget about roles.
I would 100% use roles. You can give a person multiple roles, so you could do tiers, or even component-membership: "Unlock X page, unlock Y feature"
My task is to put an authorization policy to existing / legacy wcf services. Currently there is no authorization in the system. Basichttp based custom binding is being used to handle security. ( The client is sending username / pwd in encrypted form and on the server side, database check is performed upon receiving request. At this point an expirable token is generated in and put to server memory for further security checks) Moral of the story, everything is implemented in a custom way (security features of the framework like STS, certificates and etc. are not utilized) In the service layer no authentication check is done according to client identity. Theoretically, every client can perform every operation as long as he /she has a valid username / pwd pair.
As I said, my task is to implement an authorization policy on this legacy system.
I am relatively new to wcf and my feeling is that authentication and authorization is VERY TIGHTLY COUPLED in wcf.
It seems that there are various alternatives ( http://msdn.microsoft.com/en-us/library/ff648151.aspx ) like :
*Using the ASP.NET Role Manager for role authorization,
*using the SQL Server role provider for role authorization,
and etc.
I feel that custom authorization policy would be the most suitable alternative for me but the custom samples
http://msdn.microsoft.com/en-us/library/ms731774(v=vs.110).aspx also seem to be mixing authentication policy with authorization policy. I could not find a working good sample that implements a custom authorization without any special authentication policy. As you can guess, in the current legacy system security is handled in a custom way and I can not change that i.e I can not use any ws-* bindings.
What I am thinking as a possible solution is:
1) Create a custom attribute that implements ParameterInspector or MessageInspector
2) Decorate all the existing operationcontracts with this new custom attribute
3) In BeforeCall or AfterReceiveRequest methods, apply the custom authentication logic (This custom logic will most likely be associate users with roles and roles with allowed operations).
Rejecting the request will be by throwing an exception and showing the message appropriately in the client side.
My question is, how elegant is this approach? Considering the other restrictions of the legacy system are there more elegant alternatives? Am I missing some parts or are authentication and authorization really very tightly coupled in wcf?
In the old days, basically you could use declarative programming to decorate each operation implementation with PrincipalPermissionAttribute with role name, then in Web.config you plugin ASP.NET MembershipProvider and RoleProvider etc. And if you want more fine grained policy control, you could write a few IAuthorizationPolicy implementations, as you had already found our in those MSDN references in your question.
So you expect more elegant alternatives, even if your purposed designs might be working. Being elegant:
Adequate security
Least codes
Least complexity in application
Easy to evolve
This article "Authentication and Authorization with ASP.NET Identity 2.0 for WCF Services" might give you some light.
And there exists many articles about the reasons why using Identity 2.0.
I would use an external authorization framework altogether and then apply a MessageInspector. The externalized authorization architecture would be as follows:
Externalized authorization management is about decoupling your business logic from your authorization logic. It's great when building new apps efficiently and it's great when updating legacy apps - especially web services where you can easily intercept a flow. Have a look at Gartner's report on externalized authorization.
For your problem more at hand, I recommend you use XACML, the eXtensible Access Control Markup Language. It's an OASIS standard that provides you with:
a policy language to define policy-based access control authorization
a flexible architecture with the notions of:
a policy enforcement point or PEP which intercepts your flow and protects your WCF services. In your case you should use a PEP that implements a MessageInspector
a policy decision point or PDP which receives the requests from the PEP and produces decisions based on the policies it is configured with.
a request/response scheme which defines how the PEP and PDP talk together.
Here's a diagram that sketches out the way you would want your system:
If you need a .NET PDP, you can get one from Axiomatics (disclaimer: this is the company I work for).
HTH
I am building an ASP.NET WCF Restful Service for several colleges. The service allows students to authenticate, therefore I will be leveraging some sort of central authentication at each College. For example one college may require authentication via Open LDAP while another may require Active Directory Authentication.
I need the ability to easily drop code into my project to change the authentication type (Open LDAP, Active Directory, etc..).
My solution is to create an interface and implement it in my Custom Authentication class. I would drop the compiled authentication class into my bin folder and add a key value entry into the web.config file which specifies the Assembly name and Class name. When a user Authenticates I would create the class through reflection and use the interface methods to authenticate the user.
Is the above approach a good approach to handle custom authentication? Has anyone solved this using a different approach?
Thank you for your time.
Victor
You could just use the ASP.NET provider model or use MEF to look through your directories and assemblies to discover implementations of an interface. That way you don't have to write the reflection code yourself, and it will be correctly loaded on application initialization, rather than you creating it on every authentication attempt.
I think you can develop a custom service behavior, and in that behavior you can define your customized authentication ways.
This link (http://www.codeproject.com/KB/WCF/Custom_Authorization_WCF.aspx) may help you.
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.
We use an IBM database known as Universe that holds all of our user id's, passwords, and profile information in a table called USERINFO.
Can I use the Membership Provider to connect to this database and authenticate the user?
The database access is actually through a web service since we don't have a direct connect to the database.
We have a web service method called GetUserInfo which accepts a parameter of username. The method will return the password and profile information.
As mentioned above, you'll need to create a custom membership provider which a fairly straightforward. You'll create a .NET class that inherits from System.Web.Security.MembershipProvider. There are several methods that need to be overriden in your class, but most are not even used by the MVC account controller. The main method you'll want to override is ValidateUser(username, password) which will get a user logged in. After you've implemented your class you'll need to register it in web.config which is easy as well.
You can find a sample for a custom provider here:
http://msdn.microsoft.com/en-us/library/6tc47t75(VS.80).aspx
And a tutorial for the entire process here:
http://www.15seconds.com/issue/050216.htm
Keep in mind that the process for making a custom provider for MVC is the same for a standard ASP.NET web site, however MVC does not fully utilize all methods of the MembershipProvider class so it's much easier to implement.
You'll have to create a custom provider for that. It isn't very hard, as long as you can access the web service without an issue.
Have you investigated the UniObjects interface? It comes with Universe, but needs to be installed. It has complete access to all database functions. Logging in, Selecting files, reading, writing, deleteing, creating new files etc.