I have a web application into which I would like to utilize asp.net identity. The setup itself within my asp.net MVC project with the provided templates is rather straightforward. However it uses EF in the web "tier". Our company requires us to use a "n" tier architecture approach whereby all data access and business logic is physically separated onto a separate server and all logic is exposed via REST apis. I want to utilize the .net identity framework as it has everything I need but how can i extend it to access the database via a REST api? It appears to be very tightly coupled and I dont see how to separate it out. I have seen similiar questions asked but they lead no where and with no resolution. Any samples or guidance is appreciated.
This is an opinion, but you have three basic sets of functionality in your description.
UI (MVC, Angular, React)
Data Tier (Web API)
Authentication/Authorization (IdentityServer)
Your front-end (1) authenticates with the id tier (3) and gets back a token with your user claims (Authorization). Front end (1) passes token with request to data tier (2) which checks with id server (3) to make sure token is valid and then services the request.
Edit: EF would go in the Data tier, just to be Cap'n Obvious.
Related
I need the opinion of the person who has used/uses 'Restier' in the production.
I see some issues - security is disabled by default - all data can be read by the user who is not even authorized on site. Even if we plan to restrict some data - you can not remove one column from the table - only all columns will be visible to the client.
And the last - all business-logic moved to browser javascript - which is not good. If we need to perform a complex operation (which must be in a single transaction) - it is not possible.
My opinion - 'Restier' is designed for very simple RESTful projects - such as the address book, todo list etc. If you develop the big commercial application - that operate complex data scheme and operate money transactions - you should avoid using 'Restier' in a project.
Any thoughts appreciated.
REST is an arquitectural style for Web Services.
OData is a standard that describes a good technology independent implementation of REST.
RESTier is a library that implements OData V4.
The complexity of your domain must be in your Domain and Application Layer.
You can use RESTier to expose your domain functionality as a WebService the way you like. You could expose your entities only for Read operations and expose your use cases (Application Layer) as OData Actions and Functions which can the be consumed by any kind of client (iOS, Android, Web Client such as Asp.Net Mvc, Wpf , any JavaScript Frontend etc.)
If you have a complex domain I would suggest you to investigate Domain Driven Design.
Now to your questions...
Regarding security you can implement all the goodness of Asp.Net in Restier.
Regarding data shaping you never expose your domain entities directly through the Web Service. I would suggest to implement factories that convert back and forth between for example Customer (domain entity which represents the business logic) and CustomerDto (simple Data Transfer Object) . With this you can shape your data to be exposed the way you require.
Having the business logic in the Front End (UI Layer), as you mentioned, is considered an anti pattern (smart UI anti pattern) if you have big domain complexity. (For simple CRUD apps is ok). Restier does not push you in this direction. It is a matter of how you architect your solution.
Hope this helps you.
My company has a 3rd party web service we are designing a front end for. The "objects" used by this web service are very large (and variable depending on the number of sub-entities created). The web service does not expose methods to commit/load sub-entities, only the full object hierarchy.
The UI itself is split into many sub screens, and master/detail views to be able to efficiently/easily edit the large amount of data.
The issue is where to store all the data you aren't currently looking at.
Doing the web service commit takes up to 30 seconds for large records, so it is not feasible to use the web service for the intermittent data storage.
You can consider using .Net's SessionState out of the box, with the SQL persistence mode to cache the web service data, although you do need to ensure that you have a strategy to clear out expired data from the database. All objects stored in SessionState will need to be Serializable.
Also, instead of using the external web service's entity structure (e.g. the serializable proxy entities generated by a .Net added Service Reference), you should also
consider building your own customized class hierarchy for your screens (i.e. custom view models), and then build the bridging to map / project the web service graph to your viewmodel after the initial fetch from the web service, and then back again to the web service entities after the user has finished updating the graph. LINQ is great for this purpose, or possibly AutoMapper, if you haven't deviated from the web service class and property naming standards.
I'm a newbie with ASP.NET Web API and I heard so much about it that, it's the new industry standard and all, I've decided to build a regular hotel management system with it. I created some models and generated controls and created database using code-first migration. It all was tough at the beginning but now I've got hold of the essence. It's Awesome.
Now I'm stuck at the user management level. According to Web API spec there are options to manage access to resources like basic, Forms, integrated Win and OAuth. And also something about 2-legged and 3-legged which I understand are all authentication options which involves another data source or app (may be not the right terms) that will handle the authentication on behalf of the Web API I build.
Since my application is simple (for now), I was thinking is it possible to allow the Web API to include the necessary authentication, for example authenticating (user) and authorizing (role) before giving access to the data, thus seliminating the "LEGGED" dependance but at the same time it is open to allow 2-LEGGED and 3-LEGGED implementation in the future if I wish to.
From what I've seen and read the Web API is not ideal for a system like what I'm developing. Hope I'm wrong coz I find it awesome in terms of a service that can be consumed by other systems.
In my mind the big picture for the system is to allow customersI and third parties to access
hotel information via web and smart phones to check room availability and book rooms
restaurant information ...
hotel events, spa..etc
Please advice, to achieve this, how do I go about implementing authentication and authorization?
Is it efficient using a web service to access database objects?
I'm developing a win phone app and a web app. Both of them will use the same db. Should I create one web service for two apps?
A shared webservice is definitely the right way to go. That's really the point of a service, to be able to access the same business and data logic from multiple places (assuming both places are doing the same thing of course). It also acts as a natural security buffer between your app and database - so your database only needs to accept connections from the service, as opposed to multiple client applications.
As far as the technology, since both of your clients are Microsoft, you can use WCF as your service as opposed to a traditional SOAP service. Or you can go with something more universally accepted, like WebAPI with JSON. Lots of options there.
We’ve got a back office CRM application that exposes some of the data in a public ASP.NET site. Currently the ASP.NET site sits on top of a separate cut down version of the back office database (we call this the web database). Daily synchronisation routines keep the databases up-to-date (hosted in the back office). The problem is that the synchronisation logic is very complex and time consuming to change. I was wondering whether using a SOAP service could simply things? The ASP.NET web pages would call the SOAP service which in tern would do the database calls. There would be no need for a separate web database or synchronisation routines. My main concern with the SOAP approach is security because the SOAP service would be exposed to the internet.
Should we stick with our current architecture? Or would the SOAP approach be an improvement?
The short answer is yes, web service calls would be better and would remove the need for synchronization.
The long answer is that you need to understand the technology available for you in terms of web services. I would highly recommend looking into WCF which will allow you to do exactly what you want to do and also you will be able to only expose your services to the ASP.NET web server and not to the entire internet.
There would be no security problem. Simply use one of the secure bindings, like wsHttpBinding.
I'd look at making the web database build process more maintainable
Since security is obviously a concern, this means you need to add logic to limit the types of data & requests and that logic has to live SOMEWHERE.