I am new to Single Sign On concept and I am trying to implement SSO for wcf service web applications using OpenSSO with SAML protocol. I couldn't get the clear idea from the internet sources that how i should proceed/start. Can u guys help me out.
If new to SSO and WCF, you're probably not going to like the answer: write your own Binding.
WCF is awesome because Microsoft built the whole thing extensibly. So in theory you can do exactly what they did with netTcpBinding or wsHttpBinding. Say you have a VAX mainframe sitting around - you could theoretically write a Binding for it. Same with "Protocol XYZ" and OpenSSO. Since I don't see an OpenSsoBinding available out there, I conclude you'll have to whip up your own.
Implementation details are beyond my knowledge and the scope of the OP, but you can get the starting guidance here: https://msdn.microsoft.com/en-us/library/ms730305(v=vs.110).aspx
HTH!
Related
I'm looking for a WCF implementation of U-Prove that was formerly on the Microsoft connect website for test and experimentation purposes.
I've seen several videos that mention U-Prove in conjunction with WCF/Cardspace, but it seems that all of those plugins have been removed and not replaced.
I would like to see those samples just to I can understand
If the WCF binding was "upgraded" to support UProve for authentication
If WCF was used to issue and renew a UProve token
How and where the serialization was done (was it a custom binding or a simple service)
Any other WCF-specific technology that may have been improved with UProve
Ultimately I want to take the "outdated" WCF examples and modernise it so a JSON token will have the same affect as what I assume the binary-based Cardspace demo used to do.
Any archived link to the outdated Microsoft Connect project, or a FOSS replacement would be a great help.
Although this isn't the implementation per-se, it is a document that describes the implementation
http://research.microsoft.com/apps/pubs/default.aspx?id=166974
What is the difference between WCF Services and Web Services in .netWhen should I use WCF and when to use Web Services.Is REST and WCF service the same? Thanks
Web Service is an abstract term encompassing a large variety of data providers for distributed systems. Perhaps you are referring to ASMX web services, which can still be found in the wild but aren't really widely used in new development these days.
WCF Service is Microsoft's implementation of SOAP. There are others implementations or you could roll your own (not recommended).
SOAP is a kind of stateful, session-based, message-based web service. It's good if your service is designed as a set of complex actions.
REST is a stateless, sessionless, resource-based web service. It's good if your service is designed to access data and perform simple CRUD operations on it. SOAP and REST are mutually exclusive. A service cannot be both. There are ways to manipulate vanilla WCF to make is RESTful but these techniques are becoming deprecated. If you want to implement a RESTful web service there are two main choices in the Microsoft world: WCF Data Services and ASP.NET Web API.
REST is an architecture
WCF is a API in .NET Framework to build connected service oriented application.
In olden days a functionality developed as Web Service was accessible via internet and the same to be available on local network was available via Remoting.
Using WCF we don't need to develop different code for it to be accessible over internet and on local network. Just configuring it with bindings would be enough.
That is a very wide question...I am going to just give a brief high-level answer and suggest that you do some more searching as there are is already a lot written on each subject. But, hopefully this should give you a push in the right direction.
First, typically when people refer to WCF Services and Web Services, they are referring to the newer WCF conventions that make service calls fairly generic (they can be SOAP, REST, etc) and the old .asmx SOAP method of Web Services. So, along these lines, I would suggest looking more into WCF and SOAP/.ASMX for the difference of WCF and older Web Services.
As to WCF and REST, they are not the same. REST is more of an architecture, whereas WCF is a framework. As I already mentioned, WCF can be used to make SOAP calls or REST calls. I am not sure I can add much more without going into greater detail.
I will see if I can find some good articles on REST and WCF a little later, though. Personally, I do not see a reason to even pursue very far into the older way of calling web services (.ASMX pages) as WCF has pretty much made that obsolete. However, learning many different ways to skin a cat can be useful in an endeavor to find what fits you best.
Again, this is VERY high level, but these are very general topics with a lot surrounding each, so hopefully a high level overview will help direct you in studying deeper on each subject.
Some people mean "ASMX" when they say "Web Services".
Others just use "Web Services" to mean the generic technology, and consider WCF to be the current way to create Web Services on the .NET platform. The other kind are "ASMX Web Services", as distinguished from "WCF Web Services".
The "other kind" are a legacy technology, supported only for backwards compatibility. They should not be used for new development, so there's no point in you learning about them.
As others have stated, "REST" is an architecture style, not a technology.
WCF is multifaceted, so I'm going to speak of it with respect to its most common usage. The general difference between WCF and REST services is centered around the content. A REST call is usually more message/document/entity centered (With customer entities, find those starting with M; With order entities, get order 12 and is tied to the HTTP protocol. WCF tends to be more operation centered (Invoke find operation with params, Invoke get operation with parameters). WCF also isn't tied to HTTP.
FYI, there are extensions to create REST based services using WCF (WebInvoke, WebGet attributes).
Wcf:wcf is a technology as part of .net framework which provides environment to work with different distributed technologies an by following unified programming model.
wcf create a proxy.
wcf support data contract serializer.
records shown xml format.
**Rest:**Rest is an architectural style.which says use the existing features of the web in more effective,efficiency and simple manner.verbs like insert,update and delete.
Rest cannot create a proxy.
rest records shown jason format.
Web Service:a service which is hosted on website is called as webservice.
web service support xmlserializer
I see this is quite an old thread, but I have asked a similar question recently.
The answers given have all similar relevance, but in my opinion Ray was the closest to what was actually asked.
When designing or refactoring a web based solution, you always get the question should we go with SOAP or REST. The answer lies in the complexity of the business logic required behind the service. REST is good for simplistic API calls that usually contains small sets of requested data or over night processing with large sets, but mainly for data requests. SOAP is more of an interactive day to day service with business logic as well. For example many methods with plenty of parameters.
What we do as part of our web based solution, is to try and make use of both. For internal methods and primary functionalities we use SOAP, but for exposed APIs we prefer REST.
Framework related, definitely WCF as preferred choice, irrespective if SOAP or REST.
There a lot of different ways a Silverlight application can connect back to it’ server. Including
WCF - Windows Communication Foundation
REST (see also)
ADO.NET Data Services (or is this just REST?)
POX - Plain Old XML (E.g basic xml)
RIA services
For each of these please say what it’s for and when you would or wouldn’t use it. I am not looking for a great level of details just a set of “rules of thumb” for choosing between them.
(The problem is when designing your first Silverlight application knowing what to use when you don’t have time to learn all of them.)
If I was to replace Silverlight with WPF in this question what effect would it have on your answers? (I am assuming with WPF that due to firewalls and admin policies a direct connect to the database is not an option.)
My two (euro) cents:
WCF seems best suited when the service can be viewed as the business layer of the application, that is, when your service has "intelligent" operations like "CalculateDiscountForClient".
ADO.NET Data Services (indeed, just a REST implementation) seems appropriate when your application is basically data-centric and the service is simply a front-end for the database. That is, all your service methods are of type GetCustomers, CreateInvoice, etc.
RIA services is a very new technology that I haven't experimented with yet, but it seems to be useful to create applications in which the Silverlight part and the service are very tightly coupled: you define your service classes and methods in the service project, and they are automatically replicated to the Silverlight project in design time. Also, you can define both WCF-style "action" methods and ADO.NET Data Services-style "data" methods. Looks promising.
Use POX if there is a chance that you change the client part from Silverlight to any other technology (for example HTML+AJAX) in the future, since it is the most interoperable option.
About differences for WPF, the only I can think of, is that for data access, whenever possible I would use direct ADO.NET data connections (properly embedded in a data access layer, LINQ to SQL or the like) instead of ADO.NET Data Services, since it is way more flexible. I must say anyway that I have never developed anything in WPF.
We use RIA, and that's the only one of the options that I know, but I do know it, so here's some of my thoughts.
RIA isn't finished yet. It is being worked on. If you are planning to be finished soon, and you're worried about having to support something that has a potential to change quite a bit, then you might want to consider other options. If this is a new project, and you're going to be supporting it for a long time, RIA will probably get easier to use.
Having said that, I kind of think that there won't be many changes in the way the July Preview of RIA works and the way that a finished version will work. Also the level of support seems to suggest that this will become "The Way" to talk to a server in Silverlight.
Just cause it's worth mentioning, have some links:
http://blogs.msdn.com/brada/ Brad Abrams has an example that he is continually updating.
http://forums.silverlight.net/forums/53.aspx this is where you go to ask questions.
http://www.riaservicesblog.com/Blog/ Colin Blair knows his stuff, and he is very helpful.
I think I would not go POX ever again. If you write WCF so that the service itself is independent of the binding and binding is done in configuration files, then WCF is pretty much agnostic about transport and protocol. It can do SOAP, JSON, REST, or its own form of binary serialization. All of this is in the binding. Internally, WCF only specifies what gets exposed in terms of operation and data contracts (all defined by class, method, and property attributes). WCF gives you tremendous flexibility in this regard, with more to come in 2010.
From the Silverlight side, WCF requires that you write some plumbing code. The .NET frameowrk has the tools to build the proxy in your Silverlight project, but you must be prepared to handle all WCF responses asynchronously, and the proxy cannot catch exceptions thrown by the service.
.NET RIA Services hides all this. It uses WCF under the covers, but that is completely hidden. You don't have to write asynchronous code. You define validation once, mostly declaratively, and it works both server-side and client-side. Release 1 will be targeted for Silverlight, so you don't get the versatility to use the service elsewhere. That scope is supposed to be broadened in later releases.
I don't know enough about ADO.NET Data Services to compare. I suspect the answer would depend on whether you want to expose your data to more than just Silverlight usage.
.NET RIA Services looks like the direction I'd want to go (looking at these issues myself, with a large application in mind). The big issues for me will be implementing a very large collection of functionality in the service layer, and not being able to code directly to the data access layer (we have to be able to run on either SQL Server or Oracle).
Using WPF instead of Silverlight changes everything, depending on where your data resides. It's like the old question of Winforms vs. ASP.NET. With WPF, you're building a Windows client app, and you don't need to use any form of service-based data interface at all, unless your data access forces you into it. You'll still want to separate data and business from presentation code, using MVVM, MVC, or MVP. Other than that, you have the option to treat data access as a layer, rather than a wholy independent tier.
WCF is Microsoft's standard for service communication. I would strongly advise anyone to create a service layer using WCF Web APIs (uses WCF, but tailored specifically for REST), which is coming out this April 2012. WCF Web APIs is currently in preview mode.
Remember these rules of thumb:
- your UI will change faster than your service layer. RESTful services will be around in several years, Silverlight probably won't
- will your services ever be APIs? Well...WCF REST is the way to go
- will you mix JavaScript and Silverlight code? WCF REST will make your life easier
- will you have a mobile component (since Silverlight won't run on iOS or android)...REST is preferred.
Don't tailor to the technology, but the app as a whole.
If you want to create a Silverlight Application and you do not care about other clients, then I would choose RIA Services. It is quite painless to use and you do not need to worry how the connection from the client is made (i.e. no client side configuration necessary). RIA also generates classes for all your entities on the client and you can even share your own "server" code with the client if required (useful for enumerations or extension methods).
Remarks:
I never tried this, but if you really need you can access the RIA Service also with other clients, after all RIA Services are built on top of WCF services.
I do not quite understand Akash Kava's security concerns. You can (and have to) control security on the server-side as you would do with any other service.
For a project I have to implement a communication between a database hosted on a web server and several clients out there in the internet.
After reading a bit and watching a few introductory videos about possible (Microsoft) technologies I figured out that I seem to have (at least) three options:
1) Windows Communication Foundation (WCF)
2) ASP.NET Web services
3) ADO.NET Data services
Because I am not familiar with any of those three technologies I have to learn (hopefully only) one of them in depth - and the question is: Which one?
Or to be more precise: Which one for the following task?
Data need to be uploaded from a client to the server/database and some other data need to be downloaded as well. On client side this will not happen interactively by an user who works in a browser but rather as an automatic process on the client which will run periodicly (every 2 hours for instance).
a) On web server side there will be:
A SQL Server database
.NET Framework 3.5 SP1
A class library representing the database structure and modeled with ADO.NET Entity Framework
(An ASP.NET web application which will present the data in the database in a browser: I put this in brackets here because this web application doesn't really matter since the mentioned data up/download won't be triggered through a browser GUI.)
b) The client side is less clear and must be more flexible. Here I have to distinguish between two requirements:
i) Priority One (in terms of the time I have available for development):
The client side is under my control, it means: I have any Windows OS on the client, I can install .NET Framework and I can decide to develop a Windows service, a Console Application, a Windows Forms application or whatever. And I have knowledge about and access to the class library mentioned above.
ii) Lower Priority, but must be a future option:
I need to expose any kind of interface description which allows other developers to build their own applications to upload/download data.
The clients which others will develop for can be operated with any kind of OS (Windows, UNIX, MacOS and more). Also they shall be as free as possible to select their own prefered programming language.
Due to the last point forcing developers to use the .NET Framework on client side is not an option. The communication on client side must be any kind of "standard" technology accessible from various platforms and languages. I was reading terms like "SOAP", "REST" or "AtomPub" during my little research and these seem to be a kind of standard protocol or communication technology (not a proprietary Microsoft invention). But I am not sure nor do I know which technology is "up to date", has the "best future", is most common and well known, is the most powerful or is the easiest to use (from a viewpoint of those other possible developers! So the question is what I have to support to make most client side developers happy).
One last point: Security is important! Uploading/Downloading data must be restricted to dedicated persons. It should not be possible to use or explore the interface without appropriate credentials.
What technology is the best to use now? (1), (2) or (3)? And why would you recommend it?
Thank you very much in advance for any advice!
Well, no. (2) old-style ASP.NET webservices is on its way out - it's old, no longer being developed - it's been replaced by WCF.
So this leaves options 1 (straight WCF) and 3 (ADO.NET Data Services - renamed WCF Data Services recently).
Both use WCF as their basic technology - so learning and knowing about WCF is a must in both cases.
With straight WCF (Option 1) you have more options - you can self-host, host your service in IIS, use different protocols and bindings and so on. But with choice comes complexity - you need to learn and know all that stuff - at least to some degree. Your client needs to be able to talk SOAP to you - just about any language (.NET of course, Java, Ruby, PHP - you name it) can talk SOAP in one way or another.
If you're mostly interested in exposing data from databases onto outside clients, I think WCF Data Services is indeed quite a good choice. It's based on REST, so you can hit your WCF Data Service with a browser and just see what happens. It's quite powerful, and even offer a LINQ client side support - you formulate a LINQ query and this gets translated into your appropriate REST call to your data service.
With WCF Data Services, your client needs nothing but a HTTP stack - even the iPhone has that :-) But with a .NET client, things are of course nicer and more comfortable and more efficient.
I'd say check out the WCF Data Service first and see if that satisfies your needs - and if not, dig deeper into WCF. Also check out WCF Data Service at a glance for an intro.
UPDATE:
Marc, do I understand you correctly
that WCF on the server fulfils this
requirement? And ADO.NET (WCF) Data
services too?
Absolutely. WCF (plain or with Data Services) on the server side does NOT dictate the client in any way, shape or form. You can hook up an iPhone to a WCF Data Service, if you really feel like it :-) WCF has been designed from the ground up to be very interoperable - actually, it's the one platform out there that implements the most WS-* industry standards for cross-platform communications.
When developing an application wich will be used inside an intranet do you think Silverlight and WCF is a good solution ?
Whould you use WCF Services or WCF Web Services to expose your model to the client ?
When consuming a WCF Service the proxies will be generated under a reference and you can only have 1 service reference per service, How can I have the application domain model created under the same service reference ?
Thanks.
A. Lampard.
Not yet. I had a difficult time getting WCF configured, and Silverlight 2 beta was not well documented.
Silverlight is out of Beta now, and compatibility with WPF has improved. If your skills are generally in .NET and you want a rich web application then Silverlight ought to be a no-brainer, especially on an intranet where you can reasonably guarantee everyone has Silverlight installed. Plus, it runs fine on Macs.
For services, WCF works with Silverlight and there are numerous examples of how they work together. Here's a video from the official site on that very subject:
http://silverlight.net/learn/learnvideo.aspx?video=47177
"Not sure if I understand your second question...not sure why would you want more than 1 reference per service...?"
When you have, for example, a ProductService wich uses the classes Product and Family, if you create the proxies for this service you'll get: ServiceReference1.Family and ServiceReference1.Product. Now supose you create the FamilyService, when consuming this service you'll get the Family proxy created again, but under ServiceReference2 !
Your questions is way too broad. It's really hard to answer these kinds of questions, since, really, "any" technology is good for "any" solution. Otherwise everybody would just use one!
What's your application supposed to do, how soon you need to get it done, is there any existing investment in the same or other technologies...etc.?
Having said that, to answer your question: yes.
Not sure if I understand your second question... not sure why would you want more than one reference per service...?