Once upon a time, we had VS 2010 and a tool called FedUtil which could be run many times to change the WIF parameters for different hosts, certificates etc.
Also, FedUtil could be run standalone so you could use it on different boxes when you promoted a build from e.g. Dev to Test.
There was no internal STS so we all used SelfSTS.
Then we had VS 2012, where FedUtil morphed to the "Identity and Access Tool" which added some capability but could no longer be run standalone. The "Identity and Access Tool" could be run many times.
It included an internal STS.
Now we have VS 2013 which has a "Change Authentication" feature invoked when you create a project.
There is no internal STS.
You cannot run it standalone and worse of all you cannot run it after the project has been created.
So what happens when I want to migrate my VS 2012 projects to VS 2013?
This SUCKS massively big time.
Is there anyone at Microsoft that actually uses these tools in the real world. Because if there was they wouldn't introduce such restrictions.
Seriously people, get your stuff together!
If you agree, vote here:
In VS 2013, allow ability to run the "Change Authentication" wizard AFTER project is created
Enjoy!
2 comments:
FedUtil was deprecated because it was a PoS, but I mean that in the nicest possible way. It built with the intention that you'd quite possibly be building a STS, and that even though you were building an STS, you had no idea what you were doing. As such, it turned the whole process into a wizard step-through. It also complicated things because it didn't have the greatest logic -- try running the tool with a single WCF SVC in there. Cleaning up what it leaves behind ain't pretty.
Of course, the realization kicked in that you reeeeeeeally shouldn't be building your own STS, especially if you don't know what you're doing. Or if you're just building an RP, you should already have a working dev/QA/Prod STS in place. So the better option, IMHO, is to force you to look at the config and decide for yourself what needs to change.
I think it's better in the long run that developers be confused by config syntax, but cognizant of its presence, rather than blissfully unaware of it because of a wizard.
The new tooling is useful for creating a basic authn rough-in, which it does reasonably well. Doing anything more than that is trouble, IMO.
Agree about FedUtil and WCF - I blogged a few times about it.
But consider e.g. having a VS 2012 project and wanting to upgrade to VS 2013 and use AAD instead of ADFS.
Not a new project so can't use the "Change Authentication" wizard. Never used AAD before so no idea what the WIF constructs are!
What then?
Post a Comment