I assume you're referring to [the newly released] ADFS v2?
Yes, ADFS v2 supports WS-Trust (and WS-Federation) and SAML2 passive, and WIF only supports WS-Trust (and WS-Federation) and not SAML2 (neither passive nor active).
WS-Federation uses WS-Trust to perform [browser based] passive federation, and is in many ways similar to SAML2 passive - and in many ways not. A significant difference between WS-Federation and SAML2 passive is that WS-Federation v1.1 (the new version supported by ADFS v2) supports automatic metadata discovery. You only need to provide a metadata endpoint (an URL) in WS-Federation, whereas in SAML you have to exchange metadata documents by some chose method (usb stick, mail, etc.).
I don't know of any actual security vulnerabilities in either protocol, but the approach to metadata exchange can be debated forever. The WS-Federation approach makes many things much easier, such as certificate roll-over, automatic updates, "for-free" automatic provisioning of new members in a federation, etc. However, the "manual" exchange procedure in SAML2 can at least in theory be made more secure.
As to why SAML support is not included in WIF, I can only speculate. A decent guess could be that someone wants sites using WIF to federate with an ADFS, and not directly with some other [third party] IdP :-)
Best Answer
Original OpenID 2.0 vs SAML
They are two different protocols of authentication and they differ at the technical level.
From a distance, differences start when users initiate the authentication. With OpenID, a user login is usually an HTTP address of the resource which is responsible for the authentication. On the other hand, SAML is based on an explicit trust between your site and the identity provider so it's rather uncommon to accept credentials from an unknown site.
OpenID identities are easy to get around the net. As a developer you could then just accept users coming from very different OpenID providers. On the other hand, a SAML provider usually has to be coded in advance and you federate your application with only selected identity providers. It is possible to narrow the list of accepted OpenID identity providers but I think this would be against the general OpenID concept.
With OpenID you accept identities coming from arbitrary servers. Someone claims to be
http://someopenid.provider.com/john.smith. How you are going to match this with a user in your database? Somehow, for example by storing this information with a new account and recognizing this when user visits your site again. Note that any other information about the user (including his name or email) cannot be trusted!On the other hand, if there's an explicit trust between your application and the SAML Id Provider, you can get full information about the user including the name and email and this information can be trusted, just because of the trust relation. It means that you tend to believe that the Id Provider somehow validated all the information and you can trust it at the application level. If users come with SAML tokens issued by an unknown provider, your application just refuses the authentication.
OpenID Connect vs SAML
(section added 07-2017, expanded 08-2018)
This answer dates 2011 and at that time OpenID stood for OpenID 2.0. Later on, somewhere at 2012, OAuth2.0 has been published and in 2014, OpenID Connect (a more detailed timeline here).
To anyone reading this nowadays - OpenID Connect is not the same OpenID the original answer refers to, rather it's a set of extensions to OAuth2.0.
While this answer can shed some light from the conceptual viewpoint, a very concise version for someone coming with OAuth2.0 background is that OpenID Connect is in fact OAuth2.0 but it adds a standard way of querying the user info, after the access token is available.
Referring to the original question - what is the main difference between OpenID Connect (OAuth2.0) and SAML is how the trust relation is built between the application and the identity provider:
SAML builds the trust relation on a digital signature, SAML tokens issued by the identity provider are signed XMLs, the application validates the signature itself and the certificate it presents. The user information is included in a SAML token, among other information.
OAuth2 builds the trust relation on a direct HTTPs call from the application to the identity. The request contains the access token (obtained by the application during the protocol flow) and the response contains the information about the user.
OpenID Connect further expands this to make it possible to obtain the identity without this extra step involving the call from the application to the identity provider. The idea is based on the fact that OpenID Connect providers in fact issue two tokens, the
access_token, the very same one OAuth2.0 issues and the new one, theid_tokenwhich is a JWT token, signed by the identity provider. The application can use theid_tokento establish a local session, based on claims included in the JWT token but theid_tokencannot be used to further query other services, such calls to third party services should still use theaccess_token. You can think of the OpenID Connect then as a hybrid between the SAML2 (signed token) and OAuth2 (access token), as OpenID Connect just involves both.