I've had a look around on this subject most of the afternoon and still haven't seen a standard way of doing this.
I'm literally wanting a WCF service that connects to a .NET Membership system to be readily available to be called by a .NET site (could be more than one, thus the service) - should be easy enough, right? So...
.NET Site ----> WCF Service (Authenticate against .NET Membership) ----> .NET Site
I've set my SSL up on IIS, and I'm fully aware of WCF / .NET Membership, but my issue is linking the WCF service to the client site, how they're actually aware of each other and how the WCF service recognizes the Membership service?
I've looked at:
http://msdn.microsoft.com/en-us/library/bb398990.aspx
Which goes through the process of what I thought I was after - yet no connection strings are really made in that example, or any reference to the actual membership table. Further more, there's no example of how the client site is then authorised by the service.
Thanks in advance!
In case my comment was the answer will post it as an answer.
The Web Site that hosts Service must implement membership services.
Configuring an ASP.NET Application to Use Membership
Related
I have been tasked to set up Single Signon for asp.net application (SAAS) using IIS server with a client who has ADFS3.0 for providing identity credentials. the users authenticated will be allowed to log in to the web application but i have been going through a lot of information as how to set up service provider files as the application is already running.
what settings and where do i need to configure them. any help will be greatly appreciated.
The "modern" way to do this is by using OWIN.
You will have to change your application as per Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS.
Then add your RP to ADFS and you are good to go.
For completeness. the "old" way to do this is to use WIF as in How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF.
I'm having all kinds of trouble understanding this. Every article I read seems to have some unmentioned prerequisite amount of knowledge.
I have written a WCF service that was initially designed to be an intranet service. Now we are moving this service to a cloud hosting solution and it needs to only let authorized users call its methods.
I've since created an ASP.Net MVC 5 website for support purposes. The idea for this is that support staff will login to the mvc site with seeded credentials and add users as they sign up for the service. At the moment, users should not need to enter username or password anywhere. The service client will have username and password knowledge via local settings or configuration file or something and the authorization will be invisible to users. The MVC project seems to be working fine after some changes to the out-of-the-box flow. The database (remote) is created and being populated with new registered user information.
Because the WCF service is in a different project, and to keep a level of portability I have referenced that project in the MVC project. I then added a "wrapper" wcf service to the MVC project that I intend to be the forward facing door to the existing WCF project. In this wrapper wcf service is where the authentication should happen. I don't understand how to tie the ASP.Net Identity authorization used in the new MVC project into the wrapper wcf service. How can I make the wrapping service authorize user credentials against the identity database created and populated using the MVC site?
Thanks,
PS
Transport security is not my issue at the moment so if possible leave those topics out.
I'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
I have a Webpage made with ASP.Net and another set of tools like a WPF, Windows Forms applications. Is mandatory that the ASP.Net webpage and all the set of applications be authenticated against the same ASP.Net membership provider database.
What I want to know is the best way to authenticate using a WCF service that uses ASP.NET membership provider for the authentication. Is anything made out of the box for authenticate a ASP.NET webpage against a WCF authentication service? I have to implement a Custom Provider? Because the Membership in ASP.NET Webpage fill the IPrinciple User property with user information and I want the same behaviour with a WCF service authentication.
a custom membership provider is how i have done this before. it worked pretty well. my group made the mistake of making the wcf service match the interface of the membership provider, which was unnecessary and messy. if you choose to go this route, i'd recommend making your service contract on your own as you want it and implementing your provider to consume that.
if i was doing it again, though, i wouldn't use wcf at all, but rather just use a membership provider (existing or a custom one, depending on your needs) for the asp.net application that talks directly to the database rather than a wcf layer and have a shared assembly the other tools could use that talks directly to the database. even having common code in a wcf service tier. i don't think using a service really provides a whole lot that you couldn't get by just using a common assembly. the asp.net membership provider is going to be something separate anyway.
this is assuming you are within an environment where you can just have the desktop tools connect to the database. if this is an internet deployed scenario, you probably do need to do this through some kind of service, and wcf is a great candidate for that. it's probably a shorter path, though, to use an existing membership provider and build your wcf service on top of the database that goes with that than to build a membership provider that consumes the wcf service. i don't think it would be a bad choice to do the latter, but you'd probably be better off with the former. this, of course, depends on a lot of factors, though.
I need to make a change to an ASP.NET web service written a couple years ago on 2.0. I call this web service from an old 1.1 web site. I need to make some changes to the web service, so am thinking, should I rewrite this into a WCF service and if so, will I still be able to use it from my 1.1 web site?
Yes this will work. Your service will need to be at least .net 3.0, but as long as you use a basicHttpBinding or wsHttpBinding, you can consume it like any other webservice.
You can make a WCF service act and behave just like a traditional 1.1 ASMX web service, but is that what you want?
I think you need to ask yourself what featires of WCF are motivating you to upgrade.
Do you want to also expose the service as a REST-ful service? Do you need to implement message level security?
If it's just to go to the latest technology for the sake of the latest technology, I'd say stick with ASMX web services if your requirements for message and protocol security aren't that high and you're working with mostly microsoft technologies.
Writing a WCF service is regrettably more difficult than a plain-old asmx web service.
yes you can... make sure to choose the correct bindings and authentication methods