We have a well established .NET framework based SAAS web application which supports Oauth2 to multiple providers, and we want to implement the same with SAML/SAML2. The current implementation of Oauth2 does all the necessary steps using resful http get and post calls plus the one redirect.
Looking at existing libraries, they all seem to want changes in "startup.cs" or wherever your startup code is and they add code to web.config. So they are building themselves into the core of your project. We don't like libraries that do that, we don't want to run code that isn't needed and our code has to pass some pretty deep auditing for defense apps, so we'd prefer not to use external libraries from nuget, although we would be prepared to include some libraries from MS if they do not interfere with the app infrastructure (startup and web.config).
Only a small minority of our customers will use SAML since most will use direct logins or Oauth2 providers.
So how can we add SAML with pure restful calls / redirects and not using third party libraries ? I hoped we could find examples where you build up a piece of XML and send it via http post or via a querystring, but after several hours I am not finding this.
TIA
SAML can actually be quite complicated to implement properly: you WILL want library support for this. Even more, I see this:
we don't want to run code that isn't needed [because] our code has to pass some pretty deep auditing for defense apps
Mostly, this is the right attitude from a security standpoint. There are too many examples now of a threat actor getting malicious code into upstream libraries... thankfully not as much in the .Net ecosystem, but enough generally to be a legitimate security concern. But for authentication specifically avoiding libraries is exactly the wrong approach. It's actually significantly worse for security to try to do this on your own.
In fact, using a library for authentication should make security auditors happier, because it's just so easy to implement authentication code that seems to work correctly — passes all your unit and integration tests and looks like it's working — where in fact you have subtle bugs that result in finding out a year later you were hacked six months ago. Using a purpose-built, battle-tested library helps you avoid that scenario.
I've been saying this since at least 2010. The idea is when a flaw is discovered (because they always exist) it's found on someone else's product first. But because they're using the same library a patch is created, distributed, and applied before your own product ever has a chance to be breached. Unfortunately, the reality is these audits are often as much about ticking the box as cheaply and painlessly as possible as they are about actually improving things, so I understand where it can be hard to get this through.
Personally, I have successfully implemented SAML authentication using the ITfoxtec library for two different apps. However, it's not something I work on often enough to have broad experience to comment on the relative quality of this option vs alternatives other than to say I was able to make it work.
The main thing for this library is the source code is available, and fairly easy to browse and understand, which should further make auditors happy. Moreover, because the source is available with a very permissive license you can fork the project and include the code directly as part of the main build. This should further make it easier to audit.
Just to add to what Joel said, I think you'll find it's more cost effective to use a 3rd party library (either open source or our commercial library) rather than implementing something yourself. Also, security is important, obviously, so it's much safer to use a battle-hardened, proven implementation that's been used in production by many others for many years.
I'm not sure about other libraries, but our SAML library for ASP.NET doesn't require any code in the start-up class or changes to web.config. Perhaps you're referring to .NET 6 etc where's it's common practice to hook into the dependency injection system in the start-up code. In our library, the SAML code is executed only when required as part of a SAML SSO flow so there's no additional overhead for non-SAML authentication.
The SAML protocol is more involved than OAuth2. I suggest taking a look at the SAML v2.0 specification documents to get a feel for the effort involved.
Just wondering of what people think of using MonoTorrent and the torrent protocol as the core part of an installer....
Essentially I am creating an installer which has the following requirements:
Access through Firewalls/Proxies
Runs over SSL
Authenticated access to the installer/files
Background download
Handel bad connections (i.e. if a disconnect occurs, pickup downloads that were halfway through a file)
Validate integrity of downloaded content
Download Throttling
So given all of this, I thought that embedding MonoTorrent in the installer package, running a private tracker and having the clients download (no seeding only leaching) from the server would be a good idea.
This also has the side benefit of being able to bring extra servers online or offline depending on load.
What do you guys think? Can I get this functionality from MonoTorrent and how hard is it to setup? Is there a better alternative that will meet these requirements?
I can't comment specifically on MonoTorrent, but large software companies have indeed used the torrent protocol to distribute patchers and installers (see Blizzard Entertainment, for example).
I believe this would be relatively impractical because of the need of seeders (so a big user-base)
You would have to rely on having more people installing your software at the same time, which, unless you are an uber-corp or something else would not be so feasible.
This makes sense in the case of blizzard an highly addictive MMORPG game, with frequent and big patches and millions of p(l)ayers scattered around the world.
Monotorrent seems to be dead... howerver it seems also to work (I'm fighting with it at the moment).
Given that you are not allowing seeders the major torrent benefit is not used, so in my opinion you are asking for a load balanced download system based on https, basic authorization, and SVF-aided file consistency checking.
does anybody knows about Java/C# database independent authorization library. This library should support read, write, delete, insert actions across company organizational structure.
Something like this:
- user can see all documents
- user can enter new document assigned to his unit
- user can change all documents assigned to his unit and all subordinate units.
- user can delete documents that are assigned to him
I should also be able to create custom actions (besides read, write,...) connect them to certain class and assign that "security token" to user (e.g. document.expire).
If there aren't any either free or commercial libraries, is there a book that could be useful in implementing this functionality?
Thanks.
I, too, am surprised at the lack of security frameworks.
There is Rhino Security. Ayende has a handful of blog posts about it.
Another blog has a couple of articles on it, too.
It is possible to use it with S#arp Architecture as well.
Can't say I've implemented it in a project, just read up on it a while back. It was the only implementation of its sort that I could find.
I found one library that has functionality similar to my needs:
http://www.codeproject.com/KB/database/AFCAS.aspx
It is strange that there aren't any more of it on web since this is a problem that every serious application faces. As for documentation/example, the best I found are authorization modules of CRM systems like:
- Siebel - Siebel security guide - Chapter 10.Access Control
- Sugar CRM - http://www.sugarcrm.com/crm/products/capabilities/administration/access.html
- Microsoft CRM - http://msdn.microsoft.com/en-us/library/ms955698.aspx
That is a kind of functionality I need. I guess it will be DIY task.
The problem with implementing your security solution in your client library is that it is only effective with the client tool. That sounds pretty DUH on it's own, but you leave open the huge security hole that is the database itself. So if a user connects directly to a database (for example using an Access ADP to SQL Server) they have full control to whatever their user role is. Which they would need full access to everything in the database, if you are doing your restrictions in the client library.
The only case where this wouldn't be as big an issue would be with web applications and web services. If your web service did the security and hid it behind the web service interface (so there was no direct access to the database), then it would be safe. This may be what you're talking about, but didn't specify in your question.
If you are using a fat client, is there a reason why wouldn't want to put the security logic in the database side? You mentioned database independent, but nothing you specified would be difficult to provide in each platform. You basically are describing pre-/post- triggers that check if a user has rights to edit a record. A full RLS would also restrict the user's rights to view and make things slightly more difficult depending on platform.
I have already designed an applications that is nothing more than a simple WinForm with one or two classes to handle data and collection.
Fairly often I find myself refactoring parts of it or adding new features to it, not huge features but small additions to its functionality.
The question I have is what would be the best way to provide an updated program to the user after they have initially downloaded it.
I have thought of a few different options already:
Upload a new version with improvements on CodePlex
Host the application on my personal website but change the file with the latest version
Implement some sort of system that will work in a way similar to add-ons to add the functionality.
Is there a way to provide an updated application without the user having to essentially replace their current version by deleting it and replacing it with a newly downloaded one? Although the CodePlex idea seems worthwhile I wasn't sure if there was a better or easier way.
Thank you for your time.
This is what ClickOnce was designed for.
I've used it regularly in a corporate setting,but it would also be appropriate for an Internet deployment scenario. You may want to invest in a certificate so you can sign your code if this is a commercial product.
Added
Here's a shorter article with a lot of screen shots.
http://www.15seconds.com/issue/041229.htm
(Still looking for more good links).
Added - final addition
Wikipedia sums it up succinctly.
http://en.wikipedia.org/wiki/ClickOnce
We are starting a new project and I'm trying to decide which of the Wpf-esque develop/deploy strategies we should go with. In our case we are looking at quite a complex business app that will be used by 100s (not 1000s) of people, So I'm leaning towards a click-once app. My boss likes the idea of a Silverlight app as it means easier deployment. So which way should we jump?
The answer is, of course, "it depends".
So what are the pros and cons of each?
I'll start the ball rolling (Edit Added in some answers from artur carvalho):
Silverlight
Pros
Cross browser
Doesn't require full framework.
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
Cons
Can't interact with client's file system etc
Has less functionality compared with full Wpf (anyone got a good resource that documents differences?)
Single window
Single version
Wpf Web App (xbap)
Pros
Full Wpf.
Cons
Single browser
Requires full framework
Can't interact with client's file system etc
Single window
Single version
Wpf Click once
Pros
Full Wpf
Can work offline
Multiple windows
Multiple versions (con?)
Better access to low level parts of the computer
No downtime for maintenance
Cons
Single browser
Requires full framework
Slightly(?) harder to install.
First, I would evaluate whether a web client (ideally MVC+jQuery) can't do the job...
Assuming a full client is warranted:
If it is a business app that demands a client, I would tend to go with the full framework and ClickOnce; the main difference here (re deployment) is that the client must have the framework installed - but past that, ClickOnce deployment is very pain free. Actually, building a ClickOnce manifest is much easier than Silverlight etc, since the IDE will do almost all of it for you; you just have to host the files somewhere (could be a web URL; could be a network UNC).
This gives you much more control (and power) at the client, as well as a far greater range of existing resources to use (for example, if you need, you can use some legacy winform code on the WPF surface). The "requires full framework" is also one of the largest benefits: "has full framework".
You should also perhaps consider the 3.5 "client profile" setup; not sure how wide-spread this is in reality... but worth knowing about.
You didn't say if this is a company only application or a public facing one. That alone will decide it for you.
If company only, I would go with full WPF click once. This will give you everything.
Full framework should not be an issue. It's a one time install running in the background so it's not something that your decision should depend on. Cons: it runs in Windows only but if your company is Windows only, this should not be an issue.
However WPF apps could be resource hungry so you need to know if all your client machines are capable of running WPF apps smoothly.
If it's an Internet app, go for Silverlight: it runs under different operating systems.
PROs vs. ASP.NET Web Forms
No ViewState or "surprise crap"
o This applies to Silverlight as well. Silverlight brings the "desktop" experience to the end user and there is no ViewState that is used in Silverlight.
Faster server-side & client-side
o Silverlight is faster on the client/server side depending on how you look at it. Silverlight is compiled in a .NET subsystem of Silverlight. You have access to multithreading, LINQ, complex data structures, etc. The performance vs. an ASP.NET or AJAX/JavaScript application is it magnitudes times better because of the client execution and some of the items that normally are handled in a server BLL can be brought down to the client
Simplified model for multiple related views
o Silverlight supports the complete seperation of the data and the UI. Taking this further by just creating seperate views for say another consumer of Silverlight is pretty powerful. You can apply the same MVC/MVP pattern inside Silverlight and attain this level of abstraction. Jason mentions an example of being able to create a seperate view for an iPhone and only the View component has to change. This applies to Silverlight as well for different things. For example, I have large sized Silverlight app I want to port to SharePoint. I can create a "Smaller View" for SharePoint so it fits nicer into the UI. Furthermore, Silverlight Mobile is being private tested now. I would assume that same very powerful level of abstraction applies as well to create a "Mobile view" for your Silverlight application.
Unit Testable
o Silverlight includes a Unit Test framework as well. It can be downloaded here: http://code.msdn.microsoft.com/silverlightut/
Challenges if you are not running IIS 7
o Silverlight does NOT care if you are not running on IIS 6 or IIS 7 or Apache for that matter. This is one feature where Silverlight has an advantage over ASP.NET MVC.
Client Caching
o In ASP.NET Web Forms or MVC, you are caching on the server. Silverlight allows you to cache on the client via Isolated Storage (which can be increased to hundreds of megs if necessary). This allows applications to perform ultra fast without bogging down the hosting server.
CONs vs. ASP.NET Web Forms
Difficult to convert existing code
o Silverlight is a completely different programming platform than either ASP.NET WebForms or MVC. Not only will a lot of the code not convert, you also have to think about the client layer and in most cases a complete re-architecture is needed if you are replacing large modules inside your existing ASP.NET site.
NOT the best SEO out of the box
o Google several months ago started spidering SWF files and adding them to the search engine. I think Silverlight is probably still a ways away here. What you can do for Silverlight SEO is the basic tricks to describe the meta data tags really well around the plug in.
Data access
o Data access in Silverlight is limited to Web Services/WCF/ADO.NET Data Services. You cannot make direct calls via ADO.NET or stored procedures to a database.
Security
o Silverlight runs on the client. A lot of your bits are then roaming in the wild on the internet. Furthermore, some of the data access techniques do not support full WS* standard security. Therefore, beyond certificate based transport security, you are either writing a lot of your own plumbing code or waiting for the next rev. The XAML code is pretty much insecure; not many applications have their Intellectual Property in their UI. In Silverlight, that can be very easily reverse engineered using Silverlight Spy for example. Silverlight, just by nature, is a little less secure than an ASP.NET MVC application. Obviously, you would want to encrypt/obfuscate your Silverlight assemblies before letting them off in the wild.
1. Silverlight can access the DOM from the hosting page and
2. the hosting page can access the Silverlight part.
That's a big + for Silverlight
But all other limitations cry for WPF/Windows-Forms with Clickonce
file access, right mouse click, ease of db access
The pros
The Silverlight plug-in means developers can target a single, consistent runtime for browser-based applications, rather than dealing with the complexity of multiple browsers in different versions. You also get video and multimedia effects that are hard or impossible with pure HTML and JavaScript, though Adobe Systems' Flash has the same advantages.
Execute .NET code without deploying the .NET runtime. The Silverlight plug-in does include a cut-down .NET runtime, but instead of dealing with a large download and the complexities of the Windows installer, the user has a small download of about 4MB, all handled within the browser. In my experience so far, installation is smooth and easy.
Performance is promising. Silverlight comes out well in this prime number calculator, thanks no doubt to JIT compilation to native code, though it may not compare so well for rendering graphics.
Support for Moonlight means there will be an official open source implementation of Silverlight, mitigating the proprietary aspect.
Silverlight interprets XAML directly, whereas Adobe’s XML GUI language, MXML, gets converted to SWF at compiling time. In fact, XAML pages are included as resources in the compiled .XAP binary used for deploying Silverlight applications. A .XAP file is just a ZIP with a different extension. This also means that search engines can potentially index text within a Silverlight application, just as they can with Flash.
Third-party component vendors are already well on with Silverlight add-ons. For example, Infragistics, ComponentOne and DevExpress.
Take your .NET code cross-platform. With Macs popping up everywhere, the ability to migrate Visual Basic or C# code to a cross-platform, browser-based Silverlight client will be increasingly useful. Clearly this only applies to existing .NET developers - I guess this is the main market for Silverlight, but it is a large one. The same applies to the next point:
Uses Visual Studio. Microsoft’s IDE is a mature and well-liked development environment, and since it is also the tool for ASP.NET you can use it for server-side code, as well as for the Silverlight client. For those who don’t get on with Visual Studio, the Silverlight SDK also supports command-line compilation.
Choose your language. Support for multiple languages has been part of .NET since its beginning, and having the .NET runtime in Silverlight 2.0 means you can code your client-side logic in C#, Visual Basic, or thanks to the Dynamic Language Runtime (DLR) Iron Ruby or Iron Python.
Isolated storage gives Silverlight applications local file access, but only in a protected location specific to the application, providing a relatively secure way to get this benefit.
The cons
If Apple won’t even allow Flash on the iPhone, what chance is there for Silverlight?
Silverlight is late to the game. Flash is mature, well trusted and ubiquitous. Silverlight 2 only comes out of beta in the Autumn (we hope). It is the version we care about - the one that includes the .NET runtime - and will still lack support on mobile devices, even Windows Mobile, though this is promised at some unspecified later date.
The design tools are Expression Blend and Expression Design - but who uses them? The design world uses Adobe PhotoShop.
While having solution compatibility between Expression Blend and Visual Studio sounds good, it’s actually a hassle having to use two separate tools, especially when there are niggling incompatibilities, as in the current beta.
No support for the popular H.264 video codec. Instead hi-def video for Silverlight must be in VC-1, which is less common.
It’s another effort to promote proprietary technology rather than open standards.
Yes Linux will be supported via Moonlight, but when? It seems likely that the Linux implementation will always lag behind the Windows and Mac releases.
Silverlight supports SOAP web services, or REST provided you don’t use PUT or DELETE, but doesn’t have an optimized binary protocol like Adobe’s ActionScript Message Format (AMF), which likely means slower performance in some scenarios.
Silverlight is a browser-only solution, whereas Flash can be deployed for the desktop using Adobe Integrated Runtime (AIR). Having said that, yes I have seen this.
You have to develop on Windows. This is particularly a problem for the Expression design tools, since designers have a disproportionately high number of Macs.
You can add to the pros and cons of the usual stuff of the online vs offline debate. Some items:
Pros
wpf(offline):
better access to low level parts of the computer.
cpu usage is local, so you rarely have cpu load issues.
not dependent of the net.
no downtime for maintenance.
silverlight(online):
Better control of users. If your users login, you dont have to worry with activation keys or similar stuff.
It works on Windows and Mac.
You can update all your users apps easily.
I simplified it a bit, there are gray areas in the list. I only tinkered with XBAP, so that one I'll leave out. The Cons are not hard to figure out after looking to the pros.
HTH
I would consider WPF ClickOnce with sync framework support (www.msdn.com/sync). This would allow you to support limited functionality when the user is not connected to the corporate network (which will eliminate any browser-based deployment scenarios, such as Silverlight and XBAP).
If you don't need all WPF I would try do it in Silvelight first Then you can switch to WPF more easily if you need it later.
Here I think it applies the “less is more” principle: it’s true that with WPF you have much more options and can access to the user computer, but that can finally be more a problem than a help as the times go. Think for example in how many changes you can need to change from Windows XP to Vista in an application that uses a lot of the “user computer” resources!
Mark, what do you mean when saying 'single browser' for XBAP? XBAP does work with Firefox for example. It indeed requires .NET Framework and it is unlikely that we will have WPF in Mono anywhere soon (if ever) so you are stuck with Windows, that's right.
Isn't click once available on firefox these days, via this addon: https://addons.mozilla.org/en-US/firefox/addon/1608