Per request authentication of username/password access

Topics: Web Api
Jan 30, 2011 at 1:27 AM
Edited Jan 30, 2011 at 1:36 AM

A search through all files in the VS2010 solution for current Preview 3 found no sample/scenario/unit test of a convenient client method for authenticating each service request with basic authentication.

Did find things like Authorization in HttpRequestBuilder, also HttpClientCredentialTypeHelper but no set of convenient utilities to simplify username/password authentication with basic auth on each request to the service. There really should be a convenient means of exploiting existing ASP.NET Membership systems with existing databases with username/passwords, etc.

Will these features be added? If not, then what is recommended for use with WCF HTTP APIs? Should I be looking at something like http://custombasicauth.codeplex.com/ ?

Or perhaps just putting the username in the URL and the password in the Authorization via the HttpRequestBuilder? Or maybe it's just easiest to put both username and password in the querystring until the WCF HTTP APIs stabilize more with more samples that demonstrate features?

Nevertheless, this particular feature - per request user authentication - is absolutely critical to any meaningful line-of-business web service built on WCF HTTP REST. So I would argue that the WCF HTTP REST team must prioritize this feature in all ways possible and get it right as soon as possible.

Thanks!

PS: Even if there is eventually something with Windows Identity Foundation, well that's great, but there really should be something relatively simple, independent of other so-called "Foundations", and something self-contained within WCF HTTP REST itself so that it is NOT necessary to have to depend on WIF. Analogous remarks apply to MEF which also might be great to use, but should not be necessary to use. And thus, WCF HTTP REST samples should be simple, straightforward, and not have to depend on some of these other projects whether MEF or WIF. In other words, simple samples that demonstrate the core without the bells and whistles using other foundation projects.

Coordinator
Jan 30, 2011 at 9:51 PM

Thanks

We are currently looking into support for OAuth as I mentioned. As far as basic auth, that should be possible with the client, we agree that supporting a range of authentication schemes is critical for the client.

Thanks

Glenn

Jan 30, 2011 at 11:41 PM
Edited Jan 30, 2011 at 11:42 PM

Glenn,

As you know, it's possible to find plenty of posts in forums and blogs complaining loudly about the sad and sorry history of WCF and especially the various fitful forays and abandonments of RESTful Starter Kits, Canonical REST Web Apps, or whatever for some kind of RESTful framework using WCF.

In many ways, Microsoft has really missed the boat on REST and has a lot of catching up to do to restore trust and confidence....  so much of this is a result of the fallacy of OVERengineering. How much of WCF has been so much OVERengineering that has caused so much wasted time and money for many developers trying to get it to work?

So be very careful to AVOID repeating the same mistake again of OVERengineering the WCF HTTP REST API.  Sure, definitely, a range of authentication schemes would be great. Yes, OAuth and WIF and whatever else would be great, but not if the most fundamental authentication scheme - http basic authentication -- is missing and/or delayed into some unknown future that then becomes dependent on who knows how many other projects. 

I will look for clear samples demonstrating simple convenience methods for handling http basic authentication with username/password in the next Preview. I saw from the MEF project that there were 9 previews. If it is going to be the same here for WCF HTTP REST, then at 1-2 months per preview times 6 more previews we're talking another half year to year before release?!? If so then please add http basic auth to the next Preview 4 and if you want to worry about adding OAuth or WIF then do so for a later Preview like 7, 8 or 9.

Meanwhile, some simple samples like Ron Jacobs Canonical REST Service but re-implemented with the WCF HTTP REST API, and especially some blog posts describing features in development (similar to the Scott Guthrie style or Scott Hanselman style done for ASP.NET MVC features under development prior to release of MVC 2 and MVC 3) would do a lot to restore confidence and overcome some of the bad taste that some of us still have in our mouths from the past history of WCF.

Remember that you asked repeatedly for feedback so I've attempted to offer my candid opinions. In essence, there's a lot that can and should be done now, rather than repeatedly asking for patience and always referring to future developments that you're considering. The point is that Microsoft is already way behind the curve when it comes to REST...  and OVERengineering is not going to help Microsoft catch up in providing a dedicated RESTful web service framework.

Meanwhile, I agree with those who have commented that it's more productive now just to build our own personal custom REST libs on top of ASP.NET MVC 3.

Carl

Coordinator
Jan 31, 2011 at 12:28 AM
Edited Jan 31, 2011 at 12:30 AM

Carl

I appreciate the feedback, but honestly I think your comments are a bit unfair. I understand you feel burned by previous efforts.

We are very early in the development of our new bits. From the get go we have been very clear about our intent and we have openly involved the community in the work we are doing. We have also a core set of folks from the community and who are established experts in the realm of building HTTP/Restful systems that are deeply involved and ensuring that we're not over engineering. Less is more has been a core principle for us.

We're sharing our bits early, that sets the expectation that not everything works. The whole reason we are shipping early is to get feedback.

The bits on Codeplex at this point are mostly a prototype with an illustration of what is to come. As far as security, that is a work in progress but the story will get more solid as time progresses. I can't commit to that being in the next preview, but it is something we're working on.

As far as samples, yes we are planning to have more of those however at this point the API is still evolving, so it is too early.

Yes we asked for feedback and we do appreciate that you are giving it. We are listening to the feedback and it is incorporated as part of our backlog, that does not mean we will act on every single piece of feedback, and even if we do, it may not happen over night, as that is the reality of building software.

As far as using MVC for building RESTful systems, we're not telling people they should abandon MVC for REST. Since .NET 3.5 (pre MVC) we have released functionality for exposing services over HTTP which .NET developers have been using. With this effort we are making significant investments to make that story better. When we do, some folks who did not use in the past (like folks being RESTful services on MVC) may decide to switch to our offering, or not, which is fine. Our interest is to provide a more well suited story for folks who either already use WCF or who are interested in using it. We also care greatly about folks that want to use MVC and WCF side by side, which is why we invested in 4.0 in ServiceRoute and why we are planning additional investments.

Regards

Glenn

 

Jan 31, 2011 at 2:22 AM

Carl,

The prototype HTTPClient used to have a Credentials.CreateBasic(), unfortunately it didn't make it into this first version of the new HTTPClient.  Here is what you need,

        public static AuthenticationHeaderValue CreateBasic(string userName, string password) {
            var byteArray = Encoding.ASCII.GetBytes(userName + ":" + password);
            return new AuthenticationHeaderValue("Basic",Convert.ToBase64String(byteArray));
        }

Then you can simply do

client.DefaultRequestHeaders.Authorization = CreateBasic("joe","password");
 I'll make sure that it gets included somewhere in the WCFHTTPContrib project.

Now, with regards to your criticism of the overall process I have to take exception.  I do believe the original WCF was not the right way to do HTTP based distributed applications.  Microsoft's first foray into REST libraries was seriously constrained by the underlying infrastructure.  I know this well because I started using it just days after it was released back in May 2007 and I have been doing REST based work on the Microsoft stack ever since.  

Microsoft learned this quickly and the REST starter kit was a prototype effort to try and resolve some of these issues.  The REST starter kit was absolutely not abandoned. The server capabilities introduced in RSK were incorporated into .NET 4.  The HTTPClient unfortunately did not make it into .Net 4 but it has not been forgotten either, you can see the fruits of that labour in this project.

Maybe you haven't seen some of the architectural overviews of the new WCF HTTP stack that Glenn has provided, but I certainly don't consider it over-engineered.  There is a certain amount of flexibility built into the stack but that was done, to a large extent, in reaction to the requests from the advisory group.   Early on in the project there was consensus within the advisory group that the objective should be to build a really awesome HTTP stack that REST frameworks (note the plural) could be built on top. REST is an architectural style, not a prescriptive architecture and Glenn assembled group of advisors with a wide range of experience and a wide range of views on how REST frameworks should look.  Opinionated REST frameworks will come later.  Step one is a solid HTTP platform.

I understand the frustration that Microsoft does not have a fabulous REST framework that makes everything easy to do, today.  However, that will never happen if customers jump up and down and demand that they want it now.  There is also the risk that Microsoft will become more reluctant to release early previews to the community, for fear of exposing themselves to more criticism.  That would be a step backwards.

Finally, it is really unfair to apply past criticisms of the WCF architectural model to this project.  The original WCF concept was to abstract away the underlying protocols. This project takes a completely different perspective that embraces HTTP.  This changes everything. 

If you need to start writing a production application today then you have numerous options.  OpenRasta is very strong. If you know what you are doing, you can bend ASP MVC 3 to your will, or you can build on top of HttpListener.  Just make sure you keep watching this project so you can provide feedback so when it finally is ready it will be the project we all want it to be.     

 

Jan 31, 2011 at 8:20 AM
Edited Jan 31, 2011 at 8:21 AM

I wasn't sure whether to start a new thread for my question on authentication, but this one seems to be in the right area. The architecture diagram for the web apis on this site says that authentication will be handled in the channel stack, below the dispatcher level. Does this mean that the same authentication applies to all calls? Some REST apis have both "public" calls that do not require authentication, and "private" ones that do need it. This makes the WcfRestContrib approach of attributing each method with [OperationAuthentication] quite appealing. What is the intention regarding granularity of authentication for the WCF Web Apis?

Jan 31, 2011 at 6:46 PM

To both Glen and Darrel,

Why would anybody bother to offer you feedback with constructive criticism (and yes my criticism was constructive because I identified both what I considered a problem and what I considered a solution) if then your response is that the feedback/criticism is "unfair"?  I could then argue that it is "unfair" for you to exhort us to offer feedback and criticism ("to make sure that you're headed in the right direction" or whatever your phrasing was) and then label our feedback and criticism as "unfair".

So take it from a "grizzled old goat chewing on a rusty old can": if you wish to promote a project and exhort others to participate in the project and eventually have them adopt the project for real-world use, then it is not realistic to assume that your project exists in a vacuum. You do have a PR and advertising job to do, and that PR job has been impacted - whether you like it or not and whether you think it's fair or not - by any bad reputation from the context of WCF that precedes any derivative of WCF including your WCF HTTP REST.

I also have every right to maintain my opinion to argue that Microsoft is way behind the curve on REST and should have had a decent REST framework a long time ago, and then to argue that Microsoft needs to play catch up and the way for Microsoft to play catch up is to prevent "perfection from being the enemy of good enough" and to avoid "overengineering" by delaying and delaying until there's every kind of security mechanism possible while not offering the simplest basic authentication from the begining or at least as soon as possible.

I also have every right to maintain my opinion that software development from the very beginning of any project should have the right use case scenarios, sample demos and unit tests all packaged up from the beginning to drive that software development. To argue that those drivers (use cases, sample demos, unit tests, or whatever) should not be present from the beginning because it's "too early in the development process" just does not, and never will, make sense to me. And I have every right to maintain my opinion that there are critically important use cases and sample demos that are missing now but should NOT be missing now.

And, finally, I have every right to maintain my opinion about how best a project should be promoted throughout development to better build "trust and confidence" not only in the software project itself but also in the people behind the software project, and to express my opinion about that process in terms of what I think should be done with blog posts, documentation, samples or whatever, especially in the context of the history of Microsoft repeatedly abandoning all prior attempts to do some kind of REST in WCF.

You may choose to disagree with my opinions. You may find a logical flaw in a logical argument if it exists. But you cannot exhort us to give you what are fundamentally subjective personal opinions and then dismiss them as "unfair".

From the "grizzled old goat chewing on a rusty old can"

Coordinator
Jan 31, 2011 at 9:54 PM
Edited Jan 31, 2011 at 10:17 PM

Carl

I was not talking about your arguments of being behind the curve. I was talking about the comments / insinuations about how we are running this project. You are absolutely entitled to your opinion. I will be happy to chat with you more offline.

Thanks

Glenn

Jan 31, 2011 at 10:02 PM

Nick,

We absolutely want to enable access control based on method and URI (and behaps other things too) so that it is possible to do what you describe. We don't have the exact mechanism for how to do this yet but it is a requirement for our design.

Hope this helps,

Henrik

Jan 31, 2011 at 11:35 PM

Glenn,

There were no "insinuations" ...

merely candid observations and opinions expressed about the current status of the WCF HTTP REST project in the historical context of Microsoft's WCF in relation to third-party REST projects, Microsoft's own repeatedly past abandoned REST projects, and in the comparative context of how Microsoft pursued and promoted it's MVC project which has now gone through the release of MVC 1, MVC 2, and MVC 3.

If I write that http basic authentication is a missing feature/use case/sample demo in the current preview of WCF HTTP REST, then that's very explicit and not an insinuation. If I write that it would be very helpful towards enhancing PR for your project for you to write blog posts in some way similar in nature to the way Scott Guthrie promoted MVC prior to the release of MVC, then that's very explicit and not an insinuation. A similar comment applies to my other remarks including my remarks about overengineering. Nothing was written nor meant as an "insinuation".

I am convinced that there really is a generational gap here and that your use of language is very different from mine, or that your expectations for feedback are very different from what I was led to believe you were requesting.

I encourage you not to ask for feedback and then label it either "unfair" or an "insinuation". It is because of this kind of exchange that I will not participate nor contribute any further. Good luck with your project. I am sure that eventually it will be successful. However, I will not hold my breath waiting for its release.

From the "grizzled old goat chewing on a rusty old can"

Coordinator
Jan 31, 2011 at 11:38 PM
Edited Jan 31, 2011 at 11:41 PM

Carl

With all due respect, you are not giving constructive feedback. Yes security is not there nor did I say that it was. I said we are working on it.

Thanks

Glenn

Coordinator
Jan 31, 2011 at 11:53 PM
Edited Jan 31, 2011 at 11:54 PM

Carl

I think we got off on the wrong foot here, and I apologize for that.

We absolutely do appreciate your feedback. I can't speak for the past, what I can say is we are doing our best to be very forthright about our plans now. We are using Codeplex as a vehicle to get our bits down early and often so that folks such as yourself can look at what we are doing and weigh in. As we move forward we are also looking very hard at the feedback customers have given us in the past about what they liked, what they didn't like (lack of testability, too complex, etc) and what was difficult. Simplification is a key goal here. We've made some signficant decisions to help that along, for example we're being very opinionated around HTTP and not trying to solve every problem under the sun.

I am not sure that answer is satisfactory, but it is the best and most real I can give.

Regards

Glenn

 

Feb 1, 2011 at 2:19 AM

Carl,

I would normally avoid responding to such blatant trolling, but I am concerned that some Microsoft employees may feel that your opinion is representative of other customers.  

Your "constructive criticism" so far has amounted to an eloquent version of "just show me the codes".  Your specific complaint about missing support for Basic authentication amounts to, as you describe it, a convenience method for constructing the authentication header.  

I find it quite incredible that you have the audacity to criticize Glenn for the way he has promoted this project.   Without Glenn's intense community involvement, this project would not have had a tiny fraction of the external input that it has had so far.  If only more projects at Microsoft had such a committed and visible PM.  If Microsoft's willingness to listen to input is delaying your delivery schedule then that's unfortunate for you, but I'm prepared to wait and I want them to continue listening.

You claim that it is unreasonable to label your comparison of the original WCF implementation and the new one as unfair.  But then go on to say that we should expect the name to be tarnished by previous efforts.  Of course we expect the name to be tarnished, but that is a completely different thing than assuming the new implementation is being over-engineered because they share the name and it is not meeting your schedule.

As far as your opinion that Microsoft is "way behind the curve on REST", my opinion is that you are mis-informed.  So far IBM have borrowed Microsoft's OData protocol and have worked on enhancing WSDL to support REST (talk about clueless).  To my knowledge Oracle have done nothing with REST.  JBoss has this http://www.jboss.org/reststar ridiculous attempt to squeeze their middleware into a REST approach.  Sure there a number of reasonably successful open source REST frameworks but they all still have a lot of room for improvement.  I'm not sure which vendors you perceive are way ahead on REST but I would love to hear more about them.  On the .Net platform the most mature REST framework is OpenRasta and if you want to know what Sebastian Lambla thinks of this project then go listen to the latest HerdingCode podcast.

From what I can tell you are disappointed by the current state of this project because you came into it with the wrong expectations.  As a software developer you should realize that it takes time to get things right.  As a community we have two choices, we can let Microsoft do the work behind closed doors and hope that they do the right thing, or we can ask them if we can look through the window while they are working on it and hopefully push them in the right direction.  If we ask for the later then we MUST accept that we are going to see it in an unfinished state.  

On numerous occasions, Glenn cautiously asked the advisory group if we thought it would be a good idea to publish code on Codeplex for people to see.  We said yes.  I think it was the right thing to do.  I guess you would have preferred if it had remained hidden until all the bells and whistles were ready.

C'est la vie.  Now, can we get back to focusing on specific technical issues that will move the project forward.

Feb 1, 2011 at 7:51 AM

Henrik,

Thanks for your reply - that sounds perfect. There is some great stuff in this project, and I look forward to using it in my code.

Nick

Feb 2, 2011 at 5:59 AM
ctaswell wrote:

I will look for clear samples demonstrating simple convenience methods for handling http basic authentication with username/password in the next Preview. I saw from the MEF project that there were 9 previews. If it is going to be the same here for WCF HTTP REST, then at 1-2 months per preview times 6 more previews we're talking another half year to year before release?!? If so then please add http basic auth to the next Preview 4 and if you want to worry about adding OAuth or WIF then do so for a later Preview like 7, 8 or 9.

Meanwhile, some simple samples like Ron Jacobs Canonical REST Service but re-implemented with the WCF HTTP REST API, and especially some blog posts describing features in development (similar to the Scott Guthrie style or Scott Hanselman style done for ASP.NET MVC features under development prior to release of MVC 2 and MVC 3) would do a lot to restore confidence and overcome some of the bad taste that some of us still have in our mouths from the past history of WCF.

Remember that you asked repeatedly for feedback so I've attempted to offer my candid opinions. In essence, there's a lot that can and should be done now, rather than repeatedly asking for patience and always referring to future developments that you're considering. The point is that Microsoft is already way behind the curve when it comes to REST...  and OVERengineering is not going to help Microsoft catch up in providing a dedicated RESTful web service framework.

Carl

Carl,

The miscommunication clearly stems from these paragraphs. Re-reading the thread, you are not offering opinions but making demands. It's hard to read these as anything else.

At the same time, you have indeed offered some valuable opinions. I'm glad that the team is listening, and I'm looking forward to seeing some of these things myself. One question I have for you is why you aren't offering to work on some of these things. Basic Auth should be a rather trivial contribution. I have looked into it myself, but without the channel stack on the server side, I'm not ready to work on it. No biggie. I'm still excited about the progress being made and the direction that the project is taking. I also think that everyone on the team would 100% agree with your comment about over-engineering, and I don't think this project would fall into that category. I also fail to see how you could say that if you've looked through the code, but everyone is entitled to their opinion. (I'd be curious to know what you think of the ASP.NET MVC code, by the way.)

Is it frustrating we don't have this yet? Absolutely. Do I want MS to stop working on it b/c they didn't do it right the first time? Not hardly. I'm still using .NET and want the best tools possible. This thing isn't going to be built in a day, and I really appreciate all the work the team is doing to make this a top notch product. In the end, the WCF Web APIs will be the simplest and most composable way to build web applications. I'm a fan of that.

Ryan

Feb 2, 2011 at 6:07 AM
ctaswell wrote:

I also have every right to maintain my opinion ...

You may choose to disagree with my opinions. You may find a logical flaw in a logical argument if it exists. But you cannot exhort us to give you what are fundamentally subjective personal opinions and then dismiss them as "unfair".

From the "grizzled old goat chewing on a rusty old can"

Yes, you have every right. However, to say that MS "cannot ... dismiss them as 'unfair'" is equally ridiculous. Of course they can. That's their opinion. They didn't give up their opinion by asking for yours. And when you offer opinions that don't make sense, it's rational to ask why (or judge them unfair). Of course, if we want to through logic to the wind, then I'm a toucan. Eating salami.

But of course that's nonsense. You appear to be incensed that you were challenged on your opinions. Not all opinions are helpful. No one can do anything about your past opinions about WCF or your demands that the team must do something NOW to resolve them. That's silly. You have to accept that they are trying and working hard to produce something that we'll all enjoy later. If later doesn't work for you, all well and good. Go with MVC 3. No one is stopping you. However, that doesn't equate to this project failing to meet its objectives, as your opinions seem to indicate. It just means the project might not fit your needs at this time. Simple as that.

Mar 2, 2011 at 2:17 PM

I tried something using Forms Authentication:

http://blog.alexonasp.net/post/2011/03/02/WCF-Web-APIs-WCF-Http-mit-ASPNET-Forms-Authentication-verwenden.aspx

Coordinator
Mar 2, 2011 at 3:26 PM
Any chance of getting English versions? I really would love to read these as I am sure would other English speakers!

Sent from my Windows Phone

From: AlexOnAspDotNet
Sent: Wednesday, March 02, 2011 7:17 AM
To: Glenn Block
Subject: Re: Per request authentication of username/password access [wcf:243836]

Mar 2, 2011 at 3:59 PM

I'll write an english post this evening.

Actually you can download the demo from here: http://blog.alexonasp.net/file.axd?file=2011%2f3%2fWcfHttpMvcAuth.zip

You'll have to setup an ASP.NET Membership database named "wcfhttpauth" and add a ASP.NET membership user being in the role "Admins".

Coordinator
Mar 2, 2011 at 4:21 PM

That would be fantastic. I am about to send out my next "Web API roundup" and would love to include that post.

Cheers

Glenn

Mar 2, 2011 at 7:36 PM

Here we go:

http://blog.alexonasp.net/post/2011/03/02/Using-WCF-Web-APIs-WCF-Http-with-ASPNET-Forms-Authentication.aspx

Alex

Mar 5, 2011 at 7:11 PM

I also implemented a few channels for supporting basic authentication and claim based authentication with WIF in the current bits.

http://weblogs.asp.net/cibrax/archive/2011/02/04/authenticating-clients-in-the-new-wcf-http-stack.aspx

Thanks

 

 

Mar 19, 2011 at 6:50 PM

Posted an update to my recent WCF posting showing how to use the new HttpClient using ASP.NET Forms Auth with WCF Web APIs:

http://blog.alexonasp.net/post/2011/03/19/Using-the-new-WCF-Web-APIs-HttpClient-with-ASPNET-Forms-Authentication.aspx

Alex