we would like to use simplemembership provider in our app. However, we feel like validating that a user is in a role should be a part of the business logic. Simplemembership requires a dependency on System.web which we would not like to reference in the business logic.
Is there a way to decouple System.web from simplemembership provider?
I am not sure I agree that validating that a user is in a role should be part of the business logic. I would like to hear more details about this reasoning. But if you are going to put authorization in the business logic here is a method that still decouples the security model from your business model. This article explains how to do it using the new ASP.NET Identity used in MVC 5, but the same concepts will work with SimpleMembership. Dependent upon your reasoning for moving authorization into the business logic, the approach described here may also meet your requirements.
It appears from your comments that you are trying to reuse the authorization logic by placing it in the business logic, therefore not having to rewrite the authorization logic for each type of client that you put it in. But the fact is the logic will be different dependent upon the client. Just take the example of comparing authorization for an MVC View as opposed to a Web API. The MVC framework actually provides two different AuthorizeAttribute for each because you want to behave differently on authorization failure. If authorization fails on a View you want to redirect to the logon page. If authorization fails on a Web API call you want to return an HTTP unauthorized error. Two different behaviors for different types of clients that could access exactly the same business logic.
I think coupling your security logic with the business logic will actually make the business logic less reusable across different implementations. In Microsoft's Business Layer Guidelines they specifically state, "Do not mix authorization code and business processing code in the same components." I would further decouple your security model from the application by using the approach described here. This will allow you to change your security model at run-time instead of having to recompile and redeploy your application. And the security model will change.
Related
I work for a company that supports many applications, but for ease for users has an OAuth OIDC Single-Sign-On (IdentityServer4) so they can log in once and access many applications of ours. I have no problem configuring authorization to this OAuth with the returned JWT/Access Token.
But because our support footprint is so large, we have been told to handle roles, and user permissions at the application level. Here is where I am asking for feedback. I am currently developing a new API in .Net Core 6 (newbie to building APIs), and am wondering best practice for connecting a essentially third party OAuth, but also utilizing roles and permissions specific to the application.
The Identity Server returns a JWT/Access Token that is passed to API in form of bearer, but I need a mapping on the .net core backend to map the User contained in the JWT with a user within the application. Then the application can have separate mappings for roles/permissions, and utilize those roles as restrictions within the API, but I am not sure what best practice would be for this that also maintains the best security, while also achieving best performance. My thought was creating a middleware that creates and overrides userIdentity, but with that happening each call seems like unnecessary overhead. The other option is dual auth with cookie based auth that is set once, but am just unsure of best way, or what others have had success with. I know this must be a common flow that I am overthinking. Any insight is greatly appreciated.
It is common in many mature business systems to integrate identity and business data as you describe. There are two main techniques:
Identity system reaches out to business data at the time of token issuance, to get custom claims to include in access tokens. This Curity article explains the approach.
APIs look up custom claims, eg from a database, when an access token is first received, then cache custom claims for subsequent requests with the same access token. See this .NET code of mine for one way to do this.
In both cases the end result should be that the API business logic gets a useful ClaimsPrincipal that enables the correct authorization, as in this example class.
Finally, from an information disclosure viewpoint, aim to avoid returning detailed claims in JWTs to internet clients. It is common to use opaque access tokens instead, as a privacy preserving pattern.
I have a large enterprise application with specific domain logic and validation with external domain services. Validation layer already implemented in the base system.
My api uses data transfer objects for client-server messaging, but validation in ASP.NET Web Api suggests use Data Annotations attributes or IValidatableObject interface in model classes (or DTO).
How I can integrate my legacy validation system with ASP.NET Web Api validation?
Thanks.
It sounds like your validation layer, being logic that you have around your domain level objects, doesn't necessarily need to be "integrated" with your web api in the interest of keeping these separate.
For the api validation, you're either going to add another level of validation in your api using the Data Annotations/ModelState solution (or manual validation checks in your controllers) or handle the exceptions that bubble up from your domain validation in your service layer, where you can format and respond appropriately to the consumer.
.NET 4.5, MVC 5: ClaimsAuthenticationManager, IAuthenticationFilter, OWIN Forms Authentication, and ClaimsPrincipals are all new since I last touched my site's authentication functions. I've found a lack of clarity in all the docs that say this or that is the right way. I can't even tell which features are mutually exclusive.
This document says the old ASP.NET FormsAuthenticationModule doesn't support Claims, but the new OWIN doesn't support cookieless. Yet, I get the feeling that OWIN is intended to be the go-forward feature?
Does the product roadmap say which method is the go-forward for web-apps?
Is ClaimsAuthenticationManager synonymous with OWIN Forms Authentication for web apps?
Are the ClaimsAuthenticationManager and a global IAuthenticationFilter mutually exclusive?
A push in the right direction would be appreciated, my brain is fried on this.
IAuthenticationFilter
Previously in MVC, IAuthorizationFilter was a common place to perform custom authentication. The reasoning for this filter can be seen in the scenario where an application has two authorization specifications, and only one authentication specification. Two options - adding the authentication specification to a single arbitrary authorization routine, and creating all three of these specifications as distinct IAuthorizationFilter - both mean we don't ensure that authentication occurs first.
IAuthenticationFilter was originally added to the MVC assembly to address this, then relocated for use by WebAPI as well. A good related article can be found here; ASP.NET Web API Security Filters.
Strictly speaking, IAuthenticationFilter and OWIN Authentication are not mutually exclusive, but OWIN Authentication will happen first and can get in the way of any intent to use both.
OWIN Forms Authentication
OWIN forms authentication is a confusing phrase that I got from reading an ill-phrased article (linked above). It represents two non-dependent solution components:
The "Forms" aspect of the solution still operates the same as it did for Forms Authentication previously. It's a consequence of authorization failure (such as that occurring from an [Authorize] attribute or a web.config <authorization> element) paired with a redirect to a logon-handler form. (Your choice of technology will determine where you configure that redirect URL. For OWIN, you'll configure it in CookieAuthenticationOptions.)
The "OWIN" aspect is more relevant to the confusion that prompted my OP. I won't go into much detail on OWIN broadly, as it's meant to do a lot more than authentication; entirely decoupling ASP.NET from IIS (via OWIN), it results in lots of pros and cons, but MVC6 is built exclusively on OWIN so it's here to stay.
Specific to Authentication, current modules like the ASP.NET external authentication providers (Facebook/Google social login) depend on OWIN. If you write ASP.NET web authentication the "normal" way you'll be using OWIN. This is a benefit to authentication via OWIN.
Previously, social login occurred in a more cobbled-together fashion as redirection and a MessageHandler called OAuthWebSecurity. OWIN provides a mechanism both to redirect and process the authentication provider callback; read Creating Custom OAuth Middleware for MVC 5 for more information.
ClaimsAuthenticationManager
ClaimsAuthenticationManager isn't really what it sounds like. It really a tail-end aspect of an authentication process that has already been performed by the Windows Identity Foundation (WIF). It is meant to transform the Claim produced by that process to meet your custom needs. For example, the Claims list may include a username, from which you might look up from a database frequently-accessed roles or rights, and add these to the Claims list for performance reasons.
It is applicable anywhere WIF is used. Relative to current ASP.NET web applications, that will mean OWIN.
Summary
Yeah. You'll probably be using OWIN, WIF, and cookies in your modern ASP.NET web app. Just something to accept if you use the 'boxed materials', along with the death of WebForms and VB.NET in this release.
So, since you'll probably be doing OWIN authentication, here's an excellent series on the topic; What’s this Owin Stuff About?
OWIN is more of a grander scope of minimizing the stack for serving web pages and minimizing the stack is the new wave of the future(ala node.js). "OWIN authenication middleware" is what you are referring to and Brock Allen states it best here:
http://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/
With .NET 4.5.1, for ASP.NET applications, all the underlying code
that handles “Individual User Accounts” (as well as the templates in
Visual Studio 2013) is new. This means for cookie based authentication
we no longer use Forms authentication and for external identity
providers we no longer use DotNetOpenAuth.
The replacement is a framework called OWIN authentication middleware
and it’s targeting the OWIN API. I don’t plan to motivate OWIN here
(this a good article on the subject), but in short it’s an abstraction
API for the web host. Many frameworks such as Web API and SignalR (as
well as other non-Microsoft frameworks) are coded to this abstraction
so they do not require any particular web host (such as IIS).
I am currently working with a liferay portlets. Spring security is used on the Rendering layer( in jsp pages). However, it is not safe, because my dispatch controllers and services do not have any security/authorization checks.
In my application, Spring-MVC controller receives the request, and passes to the Service Layer. Service Layer builds the result and passes it to the JSP pages. In jsp pages we have the security authorization using spring-security taglibs.
I want to know the following:
Best practises regarding implementing authorization for portlets.
Which is better choice to implement security either on Dispatch layer or Service layer?
How to implement security for dispatch layer or service layer?
Please consider that I have security in my application on use-case bases.
Thank you!
My favorite answer matches here: "it depends".
Here's what it depends on:
Liferay defaults to the *LocalService being without any permission checks - e.g. if you have access to the API, you get to do whatever you want. The remote services however are supposed to check permissions before they delegate the actual execution of a service to the local services.
If you want to use Liferay's permissionChecker (which is readily available and runtime-configurable), you should do this in the non-local service methods. I tend to recommend this, as you'll be able to tap into Liferay's permissioning system - and you already have the user identity, roles, memberships etc. managed by Liferay anyway. Create a custom role, grant custom permissions and you have everything configurable at runtime.
Secondly, while you definitely want to check the permissions in the backend services, you'll probably want to do it again on the UI layer: If a user is not allowed to manipulate some object, you don't want to display the button that suggests they can change it, only to get a "permission denied" reply.
That being said, I've never tied spring security (especially the taglibs) to Liferay's permission system.
I have a business logic layer (the "repository") which is exposed as a set of .NET interfaces backed by swappable concrete implementations.
Originally I had this business layer implement authentication and authorization (authn/authz), meaning I had interfaces such as IUserIdentity and IUserRole, and all methods that accessed sensitive data took an IUserIdentity and performed authorization before allowing the action.
The business layer has been very front-end agnostic up to this point... but now when I am trying to integrate into an ASP.NET web site, I realized that ASP.NET itself has a rich authentication/authorization system built into it via the Membership and Role APIs.
So the question is, should I remove all the authn/authz from the business logic layer and rely on the web front end to do this? This would simplify things alot but I don't know whether I will later regret moving it out.
The alternative is to keep the authn/authz in my business logic but integrate it with ASP.NET via custom Membership/Role providers. However this seems real cumbersome... I still need to investigate the cost of doing this.
What would you do (or have done) and why?
I think security is a cross-cutting concern that belongs in aspects. I don't know if .NET has aspects, unless you use Spring.NET.
Keep it. Forms Authentication in ASP.NET is very easy to customize and your business logic layer remains front-end agnostic.
Consider staying away from this approach and instead try Forms Authentication. Basically, you can call your established methods from an Authenticate event of a Login control.
I suggest you keep the existing logic, and write a custom membership/role provider around your existing security classes if you want to use the same directly using asp.net. This should be easier than you think.
http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx
As you already have classes for managing security permissions, this just means wrapping your existing logic.
This will also help you to use your security logic later, let us say, when you create a Winform client that consumes your business logic, or when you expose your business logic as web services
Are you planning to use multiple front-ends (asp.net, winforms, mobile?), or exposing the business layer via (web) services? Then you should probably implement authentication on top of the business layer.
When all you want is to grant / deney access, you could use integrated security on IIS, and never wite custom code for it.
You could also look into the asp.net membership provider.
I believe the Role Based security should be in the Business Layer, which is where CSLA puts it.