I am just getting my feet wet with Angular, and am still struggling to find the best (best for "my" situation) solution for dealing with auth and authz. In terms of auth, I have seen many different examples of how to accomplish this all with the angularjs app. However, even after seeing all of these solutions I am leaning towards breaking things out so that the login page is not part of the SPA. Instead, it would be served up a via server side rendering framework. In my case it would be asp.net mvc but that is irrelevant - the concept is the same regardless of the tech.
So, when the app is first accessed the SPA component would be protected and only after authentication would it be served to the client. I feel like if you are serving up the SPA before auth, it's not truly secure. It also removes some of the complexity from the SPA in terms of login views and logic, etc which I like. In addition, I'm thinking I may even want to handle other non SPA related activities outside of the SPA. Right now I can only see a need for user/auth stuff but at least the door is left open if necessary.
Regarding authz, I really can't escape this in the SPA. Obviously the back end APIs will be secured, but for a better UX I still need some concept of roles in the SPA so I can check routes and also handle the visibility of UI components.
Is this approach one that others have used successfully? I'm interested in hearing any success stories, but also any arguments for why this might not be a good solution. FYI - my background is server side development, with heavy duty security requirements. That background makes the whole SPA concept tricky to swallow ;)
Related
I am creating a new React SPA. Users of a legacy app need be able to use the new app without re-authenticating. So I need to support SSO.
It's important to note that it is also required that users of other (currently unspecified) apps should also be able to use the new app without re-authenticating, so whatever approach I take needs to be sufficiently decoupled to potentially allow this.
The legacy app supports authentication via Shibboleth, the new app currently has no authentication method, but uses JWT for authorisation.
I'm wondering if anyone has any experience of such a scenario? It seems to me that I probably need to be create an OAuth2 authorisation server for the new app to talk to and I need to somehow bring Shibboleth into the mix for the authentication, maybe with the authorisation service acting as a Shibboleth Service Provider. Googling around hasn't revealed much useful info.
Is what I've described along the right lines? I know it's very high level and woolly, but I'm really not sure of the approach to take. Any advice, information or experience in this area would be gratefully received!
GOALS
It's a little bit of a subjective question, but the main goals are usually as follows:
Focus on building your UI and API security in a future facing manner
Also provide good Login Usability
Also deliver on non functional requirements such as availability / reliability
AUTHORIZATION SERVER
On the first point, the modern option is to integrate UIs and APIs with an Authorization Server - perhaps as in My Tutorial. Your architecture is then good, but the migration is not trivial.
FEDERATING TO SHIBBOLETH
The Authorization Server can then redirect to Shibboleth and talk SAML2.0 to achieve Single Sign On, as you suggest. It is a complex solution though, and may be a backwards step in some ways.
AVAILABILITY
This is usually a big concern, and most companies use a cloud provider such as Azure / AWS due to its high availability / low maintenance / low cost. Would this be a better option for you?
I am developing a single page app running in desktop browser, tablet browser and maybe phone browser. I am return only JSON from my backend wether it is ASP.NET MVC or Web API.
When I think of Web API or read about it I always hear the words REST/RESTfull. Independently from what REST is I like some features about Web API which I have not in MVC (by default but maybe it can be implemented somehow but I dont want that extra effort...)
Return HttpStatus codes like 200 for GET or 201 when the Ressource is created. My single page app knows and reacts on this codes.
Return DTOs directly in the controller and c# classes are automatically serialized to json. With MVC this is not a one-liner. Not dealing with ActionResults.
Web API is very much designed about 'cool' urls/routing I will also have deep/complex routing on my client.
My Web API endpoints are just 'ajax callbacks' I do not need REST things like include a self.link in every retrieved ressource etc...
Of course I do not create/modify ressources on a Get request. But I already have been used to this style when I was doing MVC. So I like and will do many REST styles but not because of REST itself rather its common practice.
Should I really design great restfull API`s to use the Web API ? I do not know what is Microsofts recommendation about the Web API or wether they have really a guideline about it...
In my experience Web API has often been a great help, and rarely a hindrance. If you do it "their way," it saves you a lot of ugly work around serialization/routing/binding. If you don't want to do it "their way," you don't have to. You can extend the routing engine. You can implement your own serialization. You can return raw JSON where you see fit. Nothing in Web API forces you to follow the REST concept to a T (trust me I have seen this in action). I haven't heard this complaint before from anyone who has used it - I would suggest you give it a try and see just how far off it really is.
REST is not at all required to use Web API. In fact, it is quite easy to turn on and use session management as well.
In fact, while RESTful approaches have some real advantages, I wouldn't recommend going 100% RESTful. It is simply not possible to make them fully secure without using a third-party authentication provider. We built a fully RESTful prototype and explored many different mechanisms to secure the site. In the end, though, every one had one vulnerability or another (it helps to have a CISSP on staff). So I talked to one of the top security experts at Norton and he agreed that, yes, there is always a way to exploit a fully RESTful, standalone app. Symantec is apparently building a "wrapper" technology that gets around this but it was easier to either go with a third-party authentication provider or just go back to MS-based security using session cookies.
For a new SPA Web App which will initially have very little user interaction and incrementally will have new features which will require lot of user interaction. This app is targeted for mobile devices. I am using this weird combination of technologies.
AngularJS + jQuery Mobile - for Client Side - MVC framework + SPA framework.
ASP.NET MVC - Server side MVC Framework - which seems unnecessary.
WCF REST Services (from 3rd party) - Do not have any control here, just consuming it. These services returns JSON data. All business logic resides here. Application do not have any feature outside of this.
Once application loaded at client side all service calls will happen from AngularJS to REST Services.
The main role of ASP.NET MVC, is just initial request load only. Even user session is handled between AngularJS and REST services.
But I foreseen eventually application will be complex to handle all the stuff at client side. So looking to push some complex processing which is easy and efficient to get done using ASP.NET MVC and .NET Sandbox. I cannot ask REST Service to do this because as i mentioned it is 3rd party.
In dilemma,
1. Should i maintain user session on server side as well?
2. How can i utilize ASP.NET MVC best possible way?
Thanks for any suggestions.
Your dilemma is justified and valid. When I go with angularJs, my big question is , do i need to csthml file or shall i use the html file.
I always go with cshtml, hoping that in future there may be scenario where i may have to leverage the server side capabilities of the mvc.
Currently I am working on the same combination of technologies stated above and with modularity of arranging js codes(angular controllers) i don't see any issues. I am bit curious on what complexities you would be adding to the contoller as you have stated that all your business logic is done by the third partly controller.
If you are looking for security aspect, I would suggest you to write a custom actionfilter which uses httpmodule to do the custom security handling.
With MVC , sessions should be a BIG NO . At lease in my organisation it so.
I've seen several similar scenarios explained here but not my particular one. I wonder if someone could tell me which direction to go in?
I am developing two (and more later) MVC2 apps. There will also be another (thicker) client later on (WPF or Silverlight, TBD).
These all need to share the same authentication. For the MVC2 apps they (preferably) need to be single log on - ie if a user logs in to one MVC2 app, they should be authorised on the other, as long as the cookie hasn't timed out.
Forms authentication is to be used.
All the apps need to use common business functionality and perform db access via a common WCF Service App. It would be nice (I think) if the WCF is not publicly accessible (ie blocked behind FW). The thicker client could use an additional service layer to access the Common WCF App.
What this should look like is:
MVCApp1 -> WCFAppCommon
MVCApp2 -> WCFAppCommon
ThickClient -> WCFApp2 -> WCFAppCommon
Is it possible to carry out all the authentication/authorization in the WCFAppCommon?
Otherwise I think I'll have to repeat all the security logic in the MVCApps and WCFApp2, whereas, to me, it seems to sit naturally in WCFAppCommon. On the otherhand, it seems if I authenticate/authorize in WCFAppCommon, I wouldn't be able to use Forms Authentication.
Where I've seen possible solutions (that I haven't tried yet) they seem much more complex than Forms Authentication and a single DB.
Any help appreciated,
Phil
I thought I should come back to this with what I've learned (and re-learned).
First the re-learned lesson - don't become fixed on an architecture and then try and make everything else fit. I'm fixed on .Net, SQL Server, WCF, MVC2, EF4, and IIS7. Fixing in my mind how I want these to fit together is slighly dumb! Better to go out and look at what guidance exists.
Which brings me to what I learned - here's a link:
http://wcfsecurityguide.codeplex.com/
I discounted this article a couple of times because it's a bit dated. However, I'd say it's actually very relevant and if you're starting a project remotely concerned with securing services go take a look. Part IV had everything I needed.
We are using WCF Web Application hosting Reporting system (we are accessing it from Silverlight) and since it's using same machine keys as our MVC application - we can share cookie authentication as well.
Otherwise, you have to send authentication ticket (custom or not) to your WCF application.
I'm developing a web app. This is more of a line-of-business app rather than a web site. I'm using ASP.NET MVC, SQL Server 2008, and I've purchased LLBLGen. I need to provide an some sort of API to third parties. For instance, if this was a medical app, third parties might need to CRUD patients, retrieve complex reports, engage certain kinds of workflows, etc.
What is the best way to do this with MVC without going to the architecture astronaut route. Do I need a whole "web service" type layer or can I re-use my controllers in MVC? Does it make sense to have this kind of API exposed through MVC? Optimally, I need a solution that involves the least amount of code repitition. I've found some stuff on doing REST with MVC but some of it is rather ambiguous and I'm not sure if it makes sense. I need a reasonable API but I'm not required to follow all the tenets of the REST religion or anything like that. I just need some sort of API in addition to providing the HTML front-end to the site, be it REST, SOAP, whatever.
Also, what are some options for dealing with URLs? Not everything in the app maps to something like site/products/product-id. Some of it involves engaging complex workflows, etc.
If you're going to have a web site and a web service then I would consider separating the data access and entities layers out from the MVC.
That way, your web service can do the same things that your website can. I would have a service layer that they both interact with. After which point the calls then go to the database and return the objects, and neither the web service nor the website should be able to interact with this layer.
This concept is also known as Separation of Concerns.
You can't/shouldn't reuse your MVC controllers in your web service. If they're so alike that they're indistinguishable, then consider writing your website to be a client of the web service, rather than being part of the same solution.