However it’s defined, a WPF application can rely on panels for basic layout. Each panel typically contains controls , and those provided by WPF include Button, TextBox, ComboBox, Menu, and many more. How those controls are positioned depends on what type of panel is chosen. A Grid, for instance , allows positioning controls on a specified grid, while a Canvas lets the developer place controls anywhere within its boundaries. And as usual in a GUI, events generated by the user are caught and handled by the various controls and other classes in the application. It’s also possible to apply styles and templates to groups of controls, which makes it easier for applications to have a uniform look.
WPF supports much more than these basic user interface functions, including the following:
Documents: A WPF application can display XPS documents using XAML’s FixedDocument tag. An application can also display flow documents using the FlowDocument tag. A flow document can behave like a traditional on-screen document, allowing the user to scroll through its contents. By setting various attributes on this tag, however, a developer can make the document more adaptive to its surroundings. A document can display a page at a time, for example, freeing its reader from the need to scroll back and forth. The goal is to allow on-screen documents to be as readable as possible.
Graphics: WPF includes support for creating two-dimensional and three-dimensional vector graphics. For 2D work, WPF provides standard abstractions such as shapes , brushes, and pens, while 3D graphics allowing defining a model that can be assigned lighting and camera position information. Unlike earlier technologies such as Windows Forms, which relies on GDI+ for graphics, WPF graphics aren’t cabined off using a separate set of concepts that developers must understand. Instead, the XAML elements used for graphics can be combined naturally with those used for anything else in a user interface.
Images: Using XAML’s Image tag, a WPF application can display images in various formats, including JPEG, GIF, and others.
Media: A WPF application can use the MediaElement tag to display video and audio in various formats, including WMV, AVI, and MPEG.
Animation: WPF provides built-in support for animating most parts of a user interface. A circle can grow and shrink, for example, or a button can smoothly change size. Applications can also define storyboards containing timelines , allowing coordinated sequences of animations to occur.
Data Binding: Because many WPF applications display data, it’s useful to have automatic support for mapping data to user interface elements. WPF provides this kind of data binding for information contained in objects and other sources.
Applying Windows Presentation Foundation
of deploying these clients , standalone WPF applications can be deployed using ClickOnce. A technology that first appeared in the .NET Framework 2.0, ClickOnce lets Internet Explorer users select an application via the Web, then have it automatically installed on their local machine. Once installed, the application can also be automatically updated when a new version is made available. The goal is to combine the simplicity and inexpensive deployment of a Web client with the power and functionality of a standalone WPF application.
Especially when they’re deployed using ClickOnce, standalone WPF applications are a good choice in many situations. Alternatively, a user can download an XBAP directly into her browser. This application can then present the user with a WPF-based user interface. To protect the user from malicious developers, all XBAPs downloaded from the Internet run in a partially trusted sandbox. Based on the code access security provided by the .NET Framework, this sandbox limits what XBAPs can do. Yet despite the restrictions imposed by the sandbox, an XBAP can still use a large fraction of WPF functionality, including 2D and 3D graphics, animations , on-screen documents, images, video, and more.
As described earlier, WPF lets applications display adaptive documents using XAML’s FlowDocument element. Documents whose appearance changes based on how they’re displayed aren’t always the best solution, though. Fixed-format documents, which always look the same on a screen and a printer, are sometimes a better choice. WPF’s XPS documents address this problem. Defined using a subset of XAML, XPS documents can be read on any system that provides an XPS reader. They also provide a new print format for Windows, allowing complex graphics to be printed with more fidelity.
Tools for Windows Presentation Foundation
Using this tool , a developer can graphically create the user interface she wishes to see, then let the tool generate the code for this interface.
Yet developers often aren’t the best people to define user interfaces. Designers are usually much better at this kind of work, since they specialize in communicating with people. Most designers don’t write code, though, and so the WPF designer isn’t an effective tool for this group. To let designers work effectively in the WPF world, Microsoft has instead created Expression Blend. The figure below shows how these tools relate to one another.
As the figure illustrates, a designer can use Expression Blend to define the look and feel of an interface, specify animations, and more, then let the tool generate a XAML version of what he’s created. A developer can import this XAML into Visual Studio and add code for things such as handling events. Because both Visual Studio and Expression Blend use the same build system, it’s possible for developers and designers to work on a project iteratively , each using the tool they’re comfortable with. The goal is to help people from the divergent disciplines of design and software engineering work together effectively.
Windows Presentation Foundation and Other Microsoft Technologies
Windows Forms: The .NET Framework’s original approach for creating application GUIs, Windows Forms is used in many current applications. Even with the advent of WPF, Windows Forms is still the right choice for creating some new software, such as line-of-business (LOB) applications. To let these technologies be used together, WPF applications can host Windows Forms controls, while WPF controls can be hosted in Windows Forms applications. For example, a Windows Forms application might host a WPF control that provides three-dimensional data visualization, or a WPF application might use the DataGridView control provided in Windows Forms. While there are some limitations , creating applications that use both technologies is certainly possible.
Silverlight: While XBAPs allow creating WPF-based interfaces that run in browsers, they’re limited to Windows systems that have the .NET Framework installed. Rich internet applications (RIAs) typically need to be accessible from any kind of client. To meet this need, Microsoft provides Silverlight. This freely downloadable technology provides a subset of full WPF functionality, including 2D graphics, animation, and video, and it runs in a variety of browsers on Windows, Macintosh, and (through Novell) Linux systems.
ASP.NET and ASP.NET AJAX: Windows applications can use WPF (or perhaps Windows Forms) for their user interface, while multi-platform RIAs can use Silverlight. One more option is to provide a standards-based Web interface using only what the browser provides—no download is necessary. This is exactly what’s done by ASP.NET and ASP.NET AJAX. This kind of interface isn’t as good at providing some features of an RIA , such as video, but especially with AJAX, it can still offer a responsive and effective user experience.
Windows CardSpace
As described earlier, people most often rely on usernames and passwords to express these digital identities today, with all of the problems this entails. Windows CardSpace, part of the larger identity metasystem, offers an alternative approach to addressing these problems. To get a deeper understanding of how CardSpace does this, the place to start is with the basic concepts of the identity metasystem.
security token . While a simple security token can be just a username and password, a more complex token might include an X.509 certificate or an XML document. However they’re represented, security tokens are today’s typical mechanism for representing digital identities on the network.
While it’s tempting to believe that we’ll all one day adopt a common security token format, the reality is that diverse approaches will continue to be used. Just as we today carry multiple identity cards in our wallet—drivers license, credit card, airline frequent flyer card, and more—we’ll always have diverse digital identities represented by diverse kinds of security tokens. No single identity system can provide a universal answer , and so multiple security tokens will always be necessary.
Yet users still need some way to work consistently with their diverse digital identities. Even though no single identity system will suffice, it’s possible to create a system of identity systems—an identity metasystem—that allows using a myriad of digital identities in a consistent way. Working with others, Microsoft has led the process of defining this metasystem. Based on open Web services technologies, such as WS-Security and WS-Trust, this metasystem defines how digital identities can be acquired and used, regardless of the type of security token they depend on.
The process of issuing, acquiring, and using digital identities can be thought of as requiring three distinct roles. Those roles are the following:
User: More formally known as the subject , the user is the entity that has a digital identity.
Identity provider: An identity provider supplies a digital identity for a user. For the digital identity you use at work , for example, the identity provider is your employer, and your security token is likely issued by a system such as Active Directory. For the digital identity you use with Amazon, the identity provider is effectively you, since you define your own username and password. Digital identities created by different identity providers can carry different information and provide different levels of assurance that the information they contain is accurate.
Relying party: A relying party is an application that in some way relies on a digital identity. A relying party will frequently use an identity (that is, the information contained in this identity’s security token) to authenticate a user, then make an authorization decision, such as allowing this user to access some information. A relying party might also use the identity to get a credit card number, to verify that the same user is accessing it at different times, or for other purposes. Typical examples of relying parties include Internet Web sites, such as banks , online merchants, and auction sites, and any application that accepts requests via Web services.
These three kinds of entities interact in the identity metasystem. The figure below illustrates these interactions, along with where CardSpace fits in.
The process begins when a user accesses a relying party via a CardSpace-aware application. To learn what type of security tokens this relying party will request, the application must get the relying party’s policy (step 1). For a browser accessing a Web site, which is the most common case today, the site’s policy is expressed in HTML and sent back as part of a Web page. For applications accessed via Web services, however, the application instead uses the industry-standard protocol defined by WS-MetadataExchange to ask the relying party for its policy. In this case, the policy is expressed using WS-SecurityPolicy, another industry standard. However the policy information is acquired , it always indicates what kind of security tokens this relying party will accept and what information those tokens must contain.
Once CardSpace knows what kind of security tokens the relying party needs, it displays the identity screen shown earlier. Each digital identity available to this user is represented as an information card on this screen. Cards issued by an external relying party are referred to as managed cards, while those issued by CardSpace’s self-issued provider are known as self-issued cards. Both kinds of cards can be shown on this screen, and the user can potentially select one of either type. To make this decision easier, the screen indicates which identities meet the requirements of the relying party by graying out cards that don’t qualify. The user then selects one of these as the digital identity he wants to use (step 2).
A card doesn’t contain an actual security token, however. Instead, it holds the information necessary to locate a particular identity provider and request a security token for this user. (In fact, each card is originally created by some identity provider.) CardSpace uses the contents of the card selected by the user to request a security token from the identity provider that issued that card (step 3). This request is made using WS-Trust, another industry-standard protocol, and the user authenticates himself to the identity provider using Kerberos, an X.509 certificate and digital signature , or another mechanism. The token is returned in an encrypted form, which also contains a timestamp to prevent this token from being stolen off the wire and reused in the future.
Once the requested security token is returned, it’s sent to the relying party (step 4). How the relying party uses the information in the token can vary. If the token contains an X.509 certificate, for example, and is accompanied by a digital signature, the relying party will likely use the token to authenticate the user. There’s no requirement that tokens be used for authentication or for any other security-related purpose, however. A token might carry information such as proof of a user’s age, eligibility for a discount at an Internet shopping site, or anything else. Authentication is one important use for security tokens, but it’s not the only option.
It’s important to note that CardSpace need not be aware of the format or technology used for the security token. Rather than trying to create a new single source for digital identities or a standard format for security tokens, the goal of the metasystem is to provide a coherent way to use any digital identity based on any kind of security token. By providing a Windows implementation of key parts of the metasystem , CardSpace plays an important role in making this general approach to digital identity a reality.
Fighting Phishing
Yet because they depend on passwords, these simple self-issued identities are targets for attackers , as described earlier. To help reduce these attacks, CardSpace provides an alternative way to create a self-issued identity. This self-issued identity provider runs locally on the user’s Windows system. Rather than relying on a username and password, the security tokens created by the self-issued identity provider are defined using the Security Assertion Markup Language (SAML), an OASIS-defined standard. These tokens rely on public key technology rather than passwords to prove the user’s identity, and if a relying party accepts them, they can play the same role as the traditional username and password. The advantage is that there is no longer a password for phishers to steal. Reducing the use of passwords can make phishing a much less serious problem.
Windows CardSpace and Other Microsoft Technologies
WCF: Because it relies on Web services standards such as WS-Security and WS-Trust, CardSpace uses WCF for communication. In fact, the creator of a WCF application can cause that application to use CardSpace just by specifying a particular binding.
Active Directory: Although it’s not currently possible, Active Directory will eventually be able to act as an identity provider in the metasystem. Once this is possible, expect to see Windows CardSpace used inside enterprises as well as on the Internet.
Windows Live ID: Microsoft’s Live ID identity system is capable today of acting as a managed identity provider for Windows CardSpace. Note that CardSpace isn’t a replacement for Live ID (formerly known as Passport), since the two address quite different problems.
Conclusion
and extending its predecessors , its goal is to support the creation of modern applications. By building its various technologies on a common foundation, Microsoft is striving to make the whole greater than the sum of the parts, letting developers create applications that use the various parts of the .NET Framework 3.5 in a coherent way.
From its first release in 2002, the .NET Framework has matured into the dominant platform for new Windows applications. Used widely today by enterprises, ISVs, and Microsoft itself, the Framework has proved its value. Together with Visual Studio 2008, the .NET Framework 3.5 represents Microsoft’s current state of the art in application development.
About the Author