We currently use WIF to secure our application and back end services. I'm trying to determine if we really have a need for WIF in our solution, or if its just an extra layer that consumes resources without providing any benefit.
Our current application is split up into 2 separate web applications, a Client and Admin and several WCF services. Identity is not shared between the two applications(You have different credentials for admin and client). Identity is only ever shared between the client and the WCF services. This occurs between machines, but never across networks or enterprise boundaries.
We use a third party to perform authentication, however the 3rd party is not used as an Identity Provider. That function is performed inside the application itself.
We currently have no future plans to share identity between other applications or services, or to use a 3rd party Identity Provider, etc.
Given the way our application is setup, do we really gain much from using WIF as an additional means of securing our back end services? If WIF was removed what are we losing?
If you remove WIF, you'll have to replace it with something. Unless you decide that you don't need user authentication and authorization at all. Remember that in addition to authentication, WIF gives you the claims-based authorization model.
Another benefit of WIF is that it's becoming a well-known standard way of securing applications, meaning that when you bring on new developers in the future, they'll likely be familiar with your security model. That's a big benefit. Compare that to a custom security model that you'd have to train the new developers on.
Also, WIF is a proven technology with well-known security benefits. If you implement WIF as recommended, your applications are secured. That's not necessarily true of other models, especially a custom-designed security model.
Also, you say that you currently have no future plans to use the more advanced features of WIF. There's a big difference between not currently having plans and never ever going to do it. With your current WIF implementation, you have the flexibility to add those things if plans change in the future. If you replace WIF with something else, you're giving up that flexibility. Or at least making it much more difficult.
Were it my project, the first questions I would ask are:
Does the existing WIF security model work? If no, then fix or replace. If yes, then ...
Is it causing any trouble (materially affect memory usage, application response, or developer productivity)? If not, then leave it alone. If yes, then ...
Are the benefits of replacing it worth the cost and the risk of breaking something or failing to implement some other feature?
If you have something that works and doesn't impede your ability to improve your application, then any time you spend working on that piece is at the cost of some other feature.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Preface: I'm new to developing for secure commercial applications, and I understand that I may be too sensitive.
I'm working with a supervisor as a freelancer on a project that uses very truncated version of Forms Authentication and an SHA1 hash sans salt. The project uses no other security, and I've been explicitly ordered not to use any built in security that would ordinarily come with an MVC application, along with a few of the rendering/scripting libraries and the built in methods for role authentication or data annotation.
To the best of my knowledge, the application will not be interacting with legacy code, and the choice to use these methods does not lie in backwards compatibility with any already existing code bases.
The project uses a home brew method for encryption, roles, and security that uses a version of SHA1 and overrides or does not make use of many of the Forms Authentication methods.
Data stored by the application will include financial and personal records for a variety of entities and individuals ranging from small businesses to government entities.
I have mentioned several times that I am uncomfortable with the fact that the application does not use most MVC security tools, urged my boss to let me use more security, and have documented my issues with the project.
I have also spent hours reading on Asp.Net Identity and other tools in preparation for customizing them according to the project requirements while maintaining things I consider necessary, but was refused permission to do so.
Despite my worries, I want to finish the project if at all possible, preferably in a way that does not expose the users too badly or myself to legal ramifications for the kind of data that could be exposed here.
Given the following conditions, I would like to know if there are any specific ways to increase the security of this project:
Can't use OWIN/OAuth or Asp.Net Identity.
Initial authentication must be performed against the same table where sensitive user and financial information is stored in plain text. All subsequent authentication and roles management is performed against the home brew code, which stores session variables.
No salt may be used with passwords.
Password length is the only requirement for creating passwords, and the required length is very short.
Can't track or limit how many times a user can try to access or log into the system.
Can't use two-factor authentication.
Can't set the authentication ticket or security cookie to expire promptly.
Can't use data annotations for roles, authorization, and to some degree for validation on incoming data (some things have been nixed, others not).
Can't use anyone else's tools for security.
Can't create or limit roles using any of the built in classes/must use home brew method for limiting roles only.
Can't use the User.Identity object or methods.
In general, because of the nature of the data being stored, I am worried that the home brew security, coupled with the absence of current security tools, has created a situation in which it is extraordinarily difficult for sensitive information not to be exposed.
My communication with my supervisor is very poor. I'm hoping that any responses will give me more/better ways to communicate the vulnerabilities I'm seeing. No doubt I'm being annoying to my boss at this point, likely a contributing factor in our communication break down, but I'm very, very worried about all this.
And again, I am prepared to hear I'm being over-sensitive or that I am in the wrong. I am keenly aware that as a new developer, I have yet to develop a full understanding of the field. The vast majority of my experience has been academic, and I know that the classroom is not necessarily a good model for the actual practice of software development.
I'm also prepared to hear I should just finish the project and leave my boss alone.
But to the best of my knowledge, whatever that can be said to be, what I'm creating will be trivially easy to break, and I feel obliged to try and do something to make it a little harder for all the reasons above.
From what you've written here this sounds like the kind of project you would not want to be involved in. The constraints you listed sound like they are building a web app from the 90s. It sounds like they have covered all the bases as far as things you don't want to to if you plan to make you application secure go.
The only thing I can think of to say is that you should make sure they use https. Also, Captchas haven't been listed here explicitly, but they probably fall under 3rd party tools.
You should probably revise the homebrew codebase to see if you can strengthen it?
And you should probably have a long hard think about whether this job is worth the trouble or not...
I've been asked to investigate WCF security and authentication in order to build a set of web services that fit into our business application.
Currently our application is written with ASP.NET with a lot of back-end code written in C#, and some WCF services which rely on forms authentication. Unfortunately, as time has progressed, the code base has become very ad-hoc, therefore there is no real logical separation/layering.
In the grand scheme of things, we want a structured application with a data access layer, business logic layer, data transport layer (WCF) and various presentation layers (of which the ASP.NET website will be one).
I've been told that in future, we may also support presentation layers written using Windows Forms, WPF, Console Applications and even some written in Java (for Linux and Mac users).
I'm relatively new to WCF. I understand the basic principles of it, but when it comes to authentication/security, I'm definitely no expert!
I know there are lots of different strategies for authentication/security in WCF; I'm looking for the most suitable given the range of presentation platforms. So, given the scenario of using ASP.NET, Windows Forms, WPF, Java as the various presentation layers, what is the best strategy for authentication and security in WCF services?
The best strategy for you is going to depend on your security requirements. In other words, there is not a best strategy that applies to all solutions.
I would suggest taking a look at the WCF Security Guide. It will get you up to speed on the basics of security in WCF. It also has sections for common Intranet and Internet scenarios with prescriptive guidance for each. Based on the little bit of information you've provided here, I think you will find one of these scenarios aligns to your needs. The guide is old, but still very relevant.
Later, you may want to look at the benefits of moving to a claims-based security model. This is a huge topic so I'll just point you to this guide for future reference.
What is for sure, the more I read about WIF, the more I get confused about how to do things.
For something that was supposed to ease things, I can't imagine how it would be without. I guess there's too many scenarios and I have hard time to find the one that fits me.
For some (good for my point of view, but maybe bad) reasons, I want to avoid a official STS (ADFS or ACS) and then write my own to keep things simple!
What I'm looking for is being able to deal with Users (that I'll wrap from an AD identity), Groups of users (custom) and Roles that get users/groups assigned to (custom).
I want to decorate my client side methods with the ClaimsPrincipalPermissionAttribute (or a declarative equivalent) to check if the current user has the required role. I want to be able to use that from a Windows Client application or a WCF Service hosted on IIS/WAS (Net.tcp is my preferred choice of binding).
Some guidance will be greatly welcome as I'm tired to read on an on WIF materials without any improvement of how the solution could be shaped.
Thank you !
So first of all - there is no such thing as a simple STS. I hope you realize that an STS is criticial security infrastructure and probably should not be your first WIF project. If you want to have a look at an open source STS to get some ideas have a look here: http://thinktecture.github.com/Thinktecture.IdentityServer.v2/.
Next authZ happens on the server side (client side is usability). Simply roles checks are rather done with PrincipalPermission. ClaimsPrincipalPermission encourages you to separate service and security code - look up ClaimsAuthorizationManager for more information.
Is it wise to build a large application entirely based off SOA? Or just some portions? User account logins, accounting, gis mapping, sales, etc?
In other words, would it be wise to build a GUI to such an application in HTML & Javascript which does all it's exchanges via ajax to .NET web services on the back-end?
I can't see it worth loosing all the .net .aspx functionality such as forms authentication, view state, etc. But my co-worker is saying if we are going to go SOA there is no need for .NET on the front end. But i think there should be some sort of balance. Where do you draw the line? Should all calls to the database go through the web services?
I just want to say that "with SOA we’re building for change, while with Traditional systems engineering, we’re building for stability."
The problem with stability, of course, is, it only takes the business so far — if the organization requires business agility, then they’re much better off implementing SOA.
So, It solely depends on what you want to achieve, you are the one who should draw the boundary.
I read it in article on SOA few days back as I'm too working on SOA.
EDIT:
Meanwhile I came across this article and thought of sharing with you.
The video quite explains the current scenario of SOA and its views by different people.
I'm getting the words of the song 'If I had a hammer' coming to mind. SOA is an architectural approach to develop software as a series of services. In my opinion this is best for systems that have less than immediate latency and limited bandwidth, and high cost in access etc (these are all obviously highly subjective). You don't need full SOA just get loose couping between components which I would argue is a good goal to achieve.
DB calls can go through a service, take ADO.NET data services for example however you really have to weigh up with what the service is to provide. Take caching. A decent approach to SOA will consider that data is may need to be cached to reduce service load. So can your data be stale in the UI? Are you allowing that use case? Is right for login info to be stale (a rough example I know but possibly something that may need to be addressed).
All in all - it depends. I think some things lend themselves to SOA very well. If you take a DDD approach then the services that represent Domains would probably do so. In this way your UI talks to domain services and not rows in table as the DB is abstracted behind domain services.
Don't use one methodology to solve all problems.
See this SO question too
It's a service oriented architecture, not a service exclusive architecture.
Presentation logic and plumbing have to live somewhere; it all depends on where it makes the most sense for it to live.
For example, let's say you have a UI component that relies on a highly chatty but efficient set of calls to a database to generate a complex analysis of something (take your pick). If your web browser is making all those calls, you introduce massive network latency and concurrency issues. If a web service makes all those calls, you are potentially putting presentation logic into it to format that result.
If you are using Session state (or web services period), you are essentially using ASP.Net anyway. Try uninstalling it and see if your web services still run.
If presentation logic needs to live on the server side, it is better for it to live within a framework intended for presentation rather than a web service, IMO. If you haven't looked at MVC 2, do so. It makes it incredibly easy to set up an application that melds browser and server UI support (for example, jQuery validator controls backed by server-side validation).
Conversely, the web browser provides an expressive platform. Assuming browser support and team knowledge, the AJAX/SOA architecture you describe is a good one. I'm using it more and more and trying to make my server pages cleaner and simpler but I have no plans to exclude ASP.Net from my toolkit any time soon.
Client implementation should be completely disconnected from the back end web service in a SOA. The service should be able to be consumed by ANY client. If you are using .NET on the back end and front end because they can be coded to directly communicate, then you are missing the point, because now they are tightly coupled and what you have now is a stove pipe application. The client should have no idea how the server side is implemented -- shouldn't matter if the back-end web service is built using .NET, Java, or whatever.
In a true SOA, you should be able to search for services in the services repository, perhaps tie the outputs in with other services or use XSLT to create alternative outputs that weren't necessarily considered when the original service was built, and consume it in a standard way in any client on the front end.
It sounds like what you're really asking is how to build a single application. The point of a SOA is to provide standard data sets through re-usable interfaces, that have no specific application or implementation in mind. To start out building a single application with the entire back-end comprised of SOA services would be a huge undertaking. In MY mind, each back-end service should be built because of it's intrinsic value all on it's own and be provided to the entire SOA "domain". Then when you or I decide to make a client that does X, Y, and Z, we can just go find those capabilities in the SOA and injest them.
I recently had my mind expanded by a new concept: Web Services for Remote Portlets, or WSRP. I learned of it during a presentation on a Java-based web portal we are considering purchasing at work; we are a .NET shop and WSRP would be the means by which we would extend this portal.
Although I cannot control the end decision as to whether or not we purchase the product, I can provide input as to how difficult it would be to build WSRP-compliant portlets. Unfortunately, my recent queries into the subject have turned up almost nill.
So I ask you, the SO community, the following: what libraries or frameworks are out there for building WSRP-compliant portlets in C#/.NET? What are some of the pros and cons of using WSRP in general?
Because there is no correct answer here, I will make this a community wiki post.
So far, I have only found the following:
WSRP Toolkit for Sharepoint by Microsoft (but requiring Sharepoint).
WSRP Portal and WSRP .NET Framework By NetUnity.
Given that WSRP is on top of SOAP, this seems like a perfect candidate for a WCF binding and channel, and yet I see nothing on the subject, anywhere.
WSRP is very contrarian. By now the world has seen that tight coupling between the data model and the presentation model is suboptimal. The success of RSS, REST, MVC, and web services in general shows this. Despite the WS in the name, WSRP stands against the core principles of Web services. The WSRP spec ignores the sound advice to keep data and presentation separate, and couples them tightly.
WSRP promises integration, at the UI level. This seems like the wrong problem to be solving.
It baffles me that this thing has lived as long as it has.
The problem it attempts to solve is often not the problem that should be solved.
If you read the WSRP spec carefully, you'll find it is a remote version of the Java Portlet Specification (if I'm spelling that right). That means that it's useful for integrating Java Portlets. Anything else will have to look like a Java Portlet, which is not very generic.
I think its popularity / adoption can be inferred by the fact that the last release from NetUnit was "This latest release adds support for Visual Studio 2005 and .NET 2.0."
I would have to agree with Cheeso. Integrating the UI with the Data only serves the portlet consumers and adds a big, unnecessary, risky layer to portlet producers. Our .NET shop has been recently forced to consider WSRP and I have found a lack of support and experience. The best MS-centric approach I have seen discussed is here. But I have not found any specific WCF implementation/support. Any leads greatly appreciated!
WSRP is essentially a portal-to-portlet web service standard. What is the primary data exchanged between portal and portlet? It's markup and largely because most portals use a web UI. This whole idea that it is not pure data versus UI is moot point. It's meant to be a web service for portlet discovery, meta data, markup, interactions, caching, portlet-to-portlet communication, etc. That's what a portal does even if not WSRP. WSRP however is an open, cross platform standard.
What is a portal that only integrates portlets from its own products and/or platform? Got Java-based PeopleSoft HR and would like to provide access to their portlets from SharePoint to your employees? Good luck. Why can't this be an achievable scenario for most enterprise software? And yes, I realize it is integration related to UI. That is one of the primary reason for why I'm using a portal. It's not like I'm expecting to get PeopleSoft integrated with SharePoint at the "pure" data level and somehow an Employee Benefits Web Part magically pops up in SharePoint ready for use. However, that is what I expect if the portlet-to-portlet integration is based on WSRP.
WSRP, although not perfect, is a superior solution in my opinion. Besides easy integration of portlet within a portal, it separates the portal from the application. No deploying of binaries to the portal server or even running on the same server. This makes sense. Never run applications on the same server as the portal server: neither will ever be upgraded. I've come to the conclusion that it's insane to put application binaries on the same server as the portal server. "Please deploy this application to the portal server and have it affect security, stability, performance, and everything in between and I would like create as many dependencies as possible and bring down the whole portal sever whenever I upgrade the application". It's a dependency nightmare. Better get a couple of portal vendor consultants to hold hands with when upgrading and to have someone to blame.
Do you need to load balance an entire portal platform when only a select number of portlets are hit the most? Portal vendors would like you to think so. A lot of the time, the portal is doing nothing more than waiting on portlets to finish processing. With WSRP, you have the flexibility to load balance portlets independently of the portal platform. It always breaks down to a few portlets that are hit the most. Why not load balance just those portlets? So instead of unnecessarily load balancing the portal on 80 CPU, you could load balance those few portlets on 10 CPUs. WSRP is also absolutely perfect for cloud computing.
WSRP is a portal-to-portlet standard. If you want to write a portlet that works in multiple portals and potentially across platforms, WSRP is it. If you are remotely contemplating integrating third party portlets, WSRP is it. It's the only standard. However, it also has some significant benefits over other proprietary local portal-to-portlet interfaces and should be considered for those benefits as well.