Should I access the asp.net membership class from the controller and pass the results to the service layer, or access it directly from the service layer?
I'm torn because on one hand this seems like business logic that should be handled in the service layer, but I don't want to tie the service layer to the web namespace as this might become an windows app down the road.
the answer, use IoC to create a membership interface that the service layer uses. the website's implementation can use the web namespace. And the windows app can have a different implementation. and since you can inject that dependency, your service layer doesn't have to change :-)
ASP.NET Membership is Web-specific, so that should be accessed in the Controller. MHO is that the service layer should not be hard-wired to the web. So for adding/removing users, do that via the Controller.
OTOH, in the service layer, you can read Thread.CurrentPrincipal.Identity, which is non-web-specific, but happens to be entirely compatible with ASP.NET Membership. So if you only need to get the current user you can do that without voilating separation of concerns.
Is it really a problem to use System.Web? It's no different than tying it to System.Configuration, or System.IO. Any application can make use of it, whether it's "offline" or not.
I routinely tie my web apps to assemblies that are more classically though of as "winforms" assemblies, to get access to useful collection objects and such.
Related
We are planning to use EXTJS framework for presentation layer which would be calling WCF based Rest Service or WebAPI Service(Http services) . My requirement is to have 3 tier architecture (physical separation) so my understanding is that we need to put Service layer on another server and host services on IIS there to be consumed by presentation layer hosted on different IIS server.
I am getting few doubts regarding this architecture.
Should we use Webform approach to host EXTS libraries as in this case ASP.Net MVC would be irrelevant considering that all the rendering logic is done by EXTJS.
If we host services on another server which service authentication should be used .In this case I think we can’t use Form Authentication as the web and service are hosted separately.
Is it really required to host Service layer on another server to make it three tier ,considering the third tier is the Database server. Isn’t browser a tier considering EXTJS library directly renders on the browser.
Since no body answered i will try to answer myself based on my research and response i got from another forum.
We can use MVC approach as well, the Controller method can be used to return JSON result for the EXTJS API to consume. But the downside is with this approach we cannot use strongly typed model in views along with other features like use of Html helper and automatic validation based on the models.
With this approach we can still use MVC routing or can go entirely with a Single View and ExtJs Routing.
Place the services your Ext.js needs on the web tier, where your Webforms/MVC application also runs. Separate your business logic/data logic via other services on another server if needed (second tier). Don't call these directly from your Ext.js. Keep presentation in the first/Web tier.We can use Form Authentication to call service in web-tier and Windows authentication to call the service from Webtier to second tier.
From the server side perspective a browser's not really considered a tier.However with modern approaches it's debatable.
Hi created my service using http://ntieref.codeplex.com/ n-tier entity framework.
The service the generator created uses wcf and wsHttpBinding. It uses windows authentication and the program created works fine when the user is logged in the Domain (as it should).
My problem is when I am trying to connect from "outside". I could not find a way to pass
something like this:
client.ClientCredentials.UserName.UserName = "SomeUserName";
client.ClientCredentials.UserName.Password = "WrongPassword";
thats why my call fails with the user not validated.
My question is specific to n-tier entity framework (http://ntieref.codeplex.com/) with the default generated. That's why I am not posting configs. If some one has experience on this framework please help.
I would like to also expose some functions of my own written on the server to the clients (beyond the entity generated functionality) (e.g. a login function that will return some custom class after validation) without breaking the existing functionality.
Where should I write my code ?
WCF Endpoint Configuration
The n-tier entity framework generates plain vanilla WCF services which can be exposed through any WCF endpoints. All you need to do is setting-up corresponding endpoint configurations in your config.
Custom Service Methods
Both, service contracts and implementation are generated as partial interfaces and classes. This allows to add additional custom services methods as required.
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.
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.