WSFederationConstants internal in 4.5???

Question

Does anyone know why the class System.IdentityModel.WSFederationConstants is internal in WIF 4.5?

It's 3.5 class (Microsoft.IdentityModel.Protocols.WSFederation.WSFederationConstants) is public.

Is there any accessor class for it?

Answer 1

I don't have an answer for you but I just ran into that today while upgrading an application. Seems rather ridiculous that now I have to duplicate those constants in my own project.

Answer 2

im guessing at the rationale - its a signal that you and me (vs MSFT) are not supposed to be building ws-fedp handlers using the foundation classes. I.e. we are only supposed to be using ADFS or ACS or Azure AD, etc.

Now what I didn't know is that they those definitions do still exist, as internal classes.

Does this mean (again at the CIO signaling level) that there is SOME IDP-making toolkit we are SUPPOSED to be using, going forward? It may not be suitable to put into an ASP.NET pipeline (since that pipeline doesn't make for a good "IDP-class" handler. But, it may well be suitable for supporting a Restful implementation standalone (like the selfSTS...).

Shame Im reduced to reading the tea leaves, for this kind of thing. Ive found it absolutely critical to align oneself with these signals, lest suddenly support disappear, APIs change, products disappear etc.

Answer 3

A somewhat educated guess here:

WIF and related were designed to abstract as much of the protocols out as possible so that you weren't writing code specifically for a given protocol. In theory, anyway.

As the code was rolled into the BCL a lot of internally-used-but-publically-accessible classes were interned because they were useful-but-still-internal-use-only. The BCL teams didn't want to expose such constants because they may change in the future as the protocols change. That's why (IMO) a lot of stuff in WCF is internal too.

---

Developer Security MVP | www.syfuhs.net

Answer 4

A somewhat educated guess here:

WIF and related were designed to abstract as much of the protocols out as possible so that you weren't writing code specifically for a given protocol. In theory, anyway.

As the code was rolled into the BCL a lot of internally-used-but-publically-accessible classes were interned because they were useful-but-still-internal-use-only. The BCL teams didn't want to expose such constants because they may change in the future as the protocols change. That's why (IMO) a lot of stuff in WCF is internal too.

---

Developer Security MVP | www.syfuhs.net

If you look at the ASP.NET integration with openauth libraries, this is exactly what folks did. Plugins to the  framework handle OAUTH vs OAUTH2 protocol details for example. The typical SP simply specifies which "protocol drivers" to load.

If you care, you can write your own driver. This allowed me to write a ws-fedp SP endpoint (which now talks to ACS, and thus to Azure-AD). The code for the driver was 90% from some WIF Sample - originally focused on being an ASP.NET page (an IIS handler, that is).

Now, is evident that the driver writing framework only intended for MSFT or friends to write such drivers (to the mainstream IDPs). It took me QUITE some effort to compile such a driver in my and own library, importing just the non-internal classes. While I could have gone and rebuilt and extend the open source library (and added my own driver there), this didn't seem appropriate. In any case, the discipline forced me to only use the correct code patterns (and not cheat by using internal classes). Presumably, this will benefit me, long term. Furthermore, the implementation of the API did some (good) things under the hood - like checking how many times a API callback method is used, for a given instance of state.

Now, I WISH I COULD TELL A SIMILAR STORY for making an IDP.

Perhaps when the dotnet4.5 era SDK is release, we will Hear the IDP story. I suspect it will be: use ADFS, which is about as convincing a storyline as "go extend AD schema" was in Win2k, 10 years ago.

Hopefully, just as AD-LDS (ldap) came along for third-parties to EFFECTIVELY run a (non-enterprise-model. non-windowsidentity/tcb/CCevaluated) directory service, so there might be an ADFS-light - into which one plugs in "IDP drivers". Now, in that I could believe (assuming Im not in la-la land)

Answer 5

Does anyone know why the class System.IdentityModel.WSFederationConstants is internal in WIF 4.5?

It's 3.5 class (Microsoft.IdentityModel.Protocols.WSFederation.WSFederationConstants) is public.

Is there any accessor class for it?

Yet another perplexing breaking change from Msft.    Many of the WIF 3.51 samples / blog posts used these and now they mysteriously disappear (along with WSTrustServiceHostFactory and others). 

If your app can't do without these, just decompile them and make them public.   Not a great solution but it works.

Answer 6

you have the right argument here. It is worrying that the "knowhow" taught in WIF 3.5 era is apparently being repudiated. This goes to the heart of what MSDN is about - leading one to adopt coding practice that CARRY FORWARD (in the general sense of support, of supportability, of engineering)

This happens in a world in which there yet is STILL NO dotNET 4 SDK for WIF (missing in action), which thus fails to teaches "the new math".

Moreover, the very methods and proofs of "old math" used in dot NET 3.5 just cannot work, when logic is limited to dotNet 4.0's axioms.

Its clear that the current mess was induced by the decision to introduce the "architectural shift" of azure AD - a design element that comes post WIF 3.0 era thinking.

Its also apparent (to me) that there was some kind of internal schism, between the WIFfies and the ASP.NET team - over OAUTH/OPENID etc. The (strategic) mess of signals was the result.

This seems to be being harmonized in the engineering of platforms sense, somewhat, with the run up to an entire indoctrination campaign over "openid connect". But now I have morbid sense about it... and am tempted to WAIT 3-5 YEARS (like I waited for the multiple-round of crap in WCF's token-centric security model to settle down, to WIF)

Venting, a little

Answer 7

A large organization changing direction on a product without informing customers or providing a clear timeline for it's future. Say it isn't so!

(Sadly) Having no private knowledge of whats going on internally, I can only say what I think is happening, which is a fundamental shift toward a consumer-driven framework, instead of a server-driven framework. 

There is also a major shift towards changes in the authorization mechanisms we use nowadays. There is  shift towards client authorization instead of just user authorization now.

---

Developer Security MVP | www.syfuhs.net

Answer 8

You are on the right track. These constants were made internal to reduce the public surface area. .NET has specific criteria on this and WIFv1.0 was exposing too much of these types. So we had to make them internal.