“Geneva” Team Blog : "Geneva" Framework

Announcing WIF support for Windows Server 2003 !!

CardSpaceBlog — Fri, 18 Dec 2009 16:48:00 GMT

We are glad to announce that Windows Identity Foundation (WIF) RTW for Windows Server 2003 is available NOW! This release supports both Windows Server 2003 SP2 and Windows Server 2003 R2 platforms and following seven languages: English (en-us), German (de-DE), Spanish (es-ES), French (fr-FR), Italian (it-IT), Dutch (nl-NL), and Japanese (ja-JP).

You can download the language specific WIF RTW packages for Windows Server 2003 from here.

If you are looking WIF packages for following operating systems check out here.

· Windows 7

· Windows Server 2008 R2

· Windows Server 2008 SP2

· Windows Vista SP2

WIF Support for Windows Server 2003

CardSpaceBlog — Tue, 24 Nov 2009 17:45:00 GMT

Windows Identity Foundation support for Windows Server 2003 SP2 is coming in December 2009. This package will be in English (en-US) and six other languages: German (de-DE), Spanish (es-ES), French (fr-FR), Italian (it-IT), Dutch (nl-NL), and Japanese (ja-JP). Stay tuned for further updates!

You can download the WIF packages for these operating systems here:

· Windows 7

· Windows Server 2008 R2

· Windows Server 2008 SP2

· Windows Vista SP2

Using WIF on a WCF Client

CardSpaceBlog — Thu, 19 Nov 2009 22:17:00 GMT

For developers familiar with WCF, a WCF client is already federation aware. By configuring a WCF client with a WSFederationHttpBinding or similar custom binding, it is possible to enable federated authentication to a service.

WCF takes care of obtaining the issued token behind the scenes, and uses this token to authenticate to the service. The primary limitation with this approach is that there is no visibility into the communications with the issuer. Since WCF takes care of the issuer leg behind-the-scenes, the RST to the issuer is automatically generated by WCF based on the issued token parameters on the binding. The limitations in this space include but are not limited to:

a. Not possible to vary the RST parameters per request.

b. Not possible to inspect the RSTR to get information such as display claims, etc.

c. Not easy to cache the token for future use.

As it stands today, the WCF client suffices for basic federation scenarios. However, considering that one of the mainline scenarios introduced by Windows Identity Foundation requires control over the RST at a level WCF does not easily allow, more flexibility is needed. Windows Identity Foundation ships several client side pieces that aim to remove the "magic" of WCF, and give developers complete control over communication with the issuer.

Before we go into the details of the client side pieces, understand that the following federation scenarios are supported by WIF.

1. Using a WCF client without any WIF dependencies to authenticate to a federated service.

2. Augumenting a WCF client with WIF, to insert an ActAs or OnBehalfOf element into the RST to the issuer.

3. Using WIF alone, obtain a token from the issuer. Then, enable a WCF client to authenticate with this token.

The first scenario is self explanatory. Existing WCF clients will continue to work against WIF relying parties and issuers. The remainder of this article will delve deeper into the other two scenarios made possible by WIF.

Augumenting an Existing WCF Client with ActAs / OnBehalfOf

In a typical identity delegation scenario, a client calls a middle tier service who then needs to call a backend service acting as, or acting on behalf of, the client. This information is conveyed to a WS-Trust issuer via the ActAs and OnBehalfOf token elements in the RST.

Developers familiar with WCF will know that WCF exposes an extensibility point on the binding that allows the plumbing of arbitrary XML elements into the RST. However, since this extensibility point is tied to the binding, it means that scenarios which require the RST contents to change per-call will need to recreate the client every call, which is a performance hit. A simple API which allows attaching any token obtained out of band to the RST is needed.

WIF introduces this functionality via extension methods to the ChannelFactory class. The following code snippet demonstrates how easy it is to take some token representing the client (could be X509, Username, Saml), and attach it to the RST sent to the issuer.

IHelloService serviceChannel = channelFactory.CreateChannelActingAs<IHelloService>( clientSamlToken );

serviceChannel.Hello(“Hi!”);

Notice that there are several key benefits that WIF enables:

1. RST can be modified per-channel. This means that middle tier services do not have to re-create the channel factory for each client, a huge performance improvement.

2. Works with existing WCF clients. This allows an easy upgrade path for existing WCF middle tier services that want to enable identity delegation semantics.

Note however, that there is still one drawback. There is still no visibility into the communications leg with the STS. The APIs demonstrated above simply piggyback on WCF's implementation and injects the ActAs or OnBehalfOf token into the RST. For even more fine-grained control, we move on to the third scenario.

Communicating Directly with an Issuer, and Using the Issued Token to Authenticate

For some advanced scenarios, augumenting a WCF client is not sufficient. Developers using just WCF typically resort to using Message In / Message Out contracts and need to handle client-side parsing of the issuer response by hand.

WIF introduces new functionality that significantly improves the client side programming model. The WSTrustChannelFactory and WSTrustChannel in WIF are designed to communicate directly with a WS-Trust issuer. The sample code below demonstrates how the APIs allow for strongly-typed RST / RSTR objects to flow between client and issuer.

WSTrustChannelFactory trustChannelFactory = new WSTrustChannelFactory( stsBinding, stsAddress );

WSTrustChannel channel = (WSTrustChannel) trustChannelFactory.CreateChannel();

RequestSecurityToken rst = new RequestSecurityToken(RequestTypes.Issue);

rst.AppliesTo = new EndpointAddress(serviceAddress);

RequestSecurityTokenResponse rstr = null;

SecurityToken token = channel.Issue(rst, out rstr);

Notice that the out parameter on the Issue() call allows access to the RSTR for client-side inspection.

Keep in mind that so far, all we have seen is how to obtain a token. The token returned from the TrustChannel is a GenericXmlSecurityToken construct that contains all the information required for the next leg: authenticating to a relying party. To use this token:

IHelloService serviceChannel = channelFactory.CreateChannelWithIssuedToken<IHelloService>( token ); serviceChannel.Hello(“Hi!”);

The CreateChannelWithIssuedToken() extension method on the ChannelFactory indicates to WIF that you have obtained a token out-of-band, and to short circuit the normal WCF call to the issuer. This will simply use the token you obtained to authenticate to the relying party.

Again, the several benefits here:

1. Complete control over the token issuance process.

2. ActAs / OnBehalfOf scenarios are supported by directly setting these properties on the outgoing RST.

3. Allows dynamic client-side trust decisions to be made based on RSTR contents.

4. The token returned from the Issue() call is cachable and can be reused.

5. WSTrustChannelFactory and WSTrustChannel constructs allow for control over channel caching, fault, and recovery semantics in line with WCF best practices.

And the only drawback:

1. You have to write more code than using a WCF client.

Summary

With WIF, the WCF client side programming model for communicating with an STS has been extended significantly. Existing code will continue to work, and developers have the option to either augment existing clients, or take complete control over communications with the issuer.

Windows Identity Foundation (WIF) RTM announced !!

CardSpaceBlog — Wed, 18 Nov 2009 18:21:00 GMT

We are very glad to announce that Windows Identity Foundation (WIF) has shipped! The official announcement of WIF RTM is made by Bob Muglia yesterday in his Keynote speech at PDC’09 Conference in Los Angeles. We are very excited to make this announcement at PDC’09 aligning with many other key product announcements made in PDC’09. It is our pleasure to offer you a claims-based identity foundation that is built using standards and that addresses the valuable beta feedback comments that you have provided to us in the past year.

We are happy to announce that in addition to English (en-us) language WIF is also available for six other languages namely, German (de-de), Spanish (es-es), French (fr-fr), Italian (it-it), Dutch (nl-nl), and Japanese (ja-jp).

Start building your production applications with WIF and leverage its extensibility points to achieve following major, but not limited to, value adds:

- standards-based and interoperable identity solution

- single claims-based identity model

- identity flow across on-premise and cloud applications

- federation capability

WIF Setup packages can be downloaded from here.

Watch the Channel-9 video with the core team who were behind the making of WIF and a short video on the impression of WIF RTM from our Director of Program Management, Conrad Bayer.

Check out the following resources to learn more about WIF:

WIF Whitepaper For Developers – by Keith Brown & Sesha Mani
Changes between WIF Beta-2 and RTW – by WIF Team
WIF Product Documentation on MSDN – by WIF User Assistance Team
A guide to claims-based identity – by Patterns & Practices Team (Preliminary draft)
New release of the Identity Developer Training Kit, updated for RTM and containing brand-new labs (WIF and Windows Azure, the new Access Control Service) – by DPE
A new channel9 training course dedicated to Identity developers, containing hosted versions of the labs in the kit and new introductory videos – by DPE
End to end sample FabrikamShipping, updated for the RTM release – by DPE
Sample ASP.NET controls (Claims-Driven Modifier Control and Security Token Visualizer Control) updated for WIF RTM – by DPE
Recordings of the identity sessions at PDC09 – by DPE
Update on Windows Azure + Windows Identity Foundation – by DPE

Claims-based identity is the next wave in identity and get onboard with Windows Identity Foundation (WIF) today!

Announcing Windows Identity Foundation (WIF) Release Candidate

CardSpaceBlog — Fri, 06 Nov 2009 22:32:00 GMT

We are happy to announce that Release Candidate (RC) of Windows Identity Foundation (previously known as Geneva Framework) is available NOW!

It comes with lots of great new features and with comprehensive set of samples in the WIF SDK.

This release contains major updates and new features such as:

· Refactored WSTrustClient as WSTrustChannelFactory and WSTrustChannel

· Extended tracing functionality for better diagnosibility

· Unifying SAML end points through WrappedTokenAuthenticator

· Crypto agility

· Bootstrap tokens availability through ClaimsIdentity

· Security token cache updates to support session mode for ASP.NET cookies

· FedUtil leveraged for control-based applications

We have heard your valuable feedback and have made changes to some of the features existed in Beta-2. Refer to the Changes Between Beta-2 and RC whitepaper for the list of major changes made in this RC. Also, the updated WIF Whitepaper provides you a conceptual overview on WIF features and scenarios.

You can get the WIF RC Setup packages here.

This RC is targeted for Win7, W2K8 R2, W2K8, and Vista platforms for both 32-bit and 64-bit architecture. Note that this release does not have W2K3 platform support, which will come later.

Move onto WIF RC and extend the great new WIF features!

Official Name for "Geneva"

CardSpaceBlog — Wed, 22 Jul 2009 02:55:00 GMT

This Monday, Microsoft made several announcements at the Worldwide Partner Conference in New Orleans. Among these announcements were the official names for the Geneva products currently in Beta.

The three components of Microsoft “Geneva” have the following names:

· Active Directory Federation Services – formerly known as “Geneva” Server. Active Directory Federation Services (AD FS) enables Active Directory to be an identity provider in the claims based access platform. AD FS provides end users a single sign-on experience across applications, platforms and organizations and simplifies identity management for IT Pros by reducing duplicate accounts.

· Windows Identity Foundation – formerly known as “Geneva” Framework. Windows Identity Foundation (WIF) offers sets of APIs for ASP.NET and WCF developers to build claims-aware applications and make them federation capable. This API set covers both building relying party applications and federation services that can issue security tokens.

· Windows CardSpace – same as current version. Windows CardSpace enables managed and native applications to participate in the claims-based access platform. Windows CardSpace empowers end-users to have better control of their identity and allows administrators to setup streamlined single sign-on access.

This news is part of our Business Ready Security strategy to help both partners and customers 1) protect everywhere and access anywhere, 2) integrate and extend security across the enterprise, and 3) simplify the security experience and manage compliance.

For more information about these announcements and others that were made, check out the Microsoft Forefront Team Blog.

What’s New in Geneva Beta 2

CardSpaceBlog — Tue, 12 May 2009 02:52:00 GMT

As announced at TechEd, Geneva has just released its Beta 2 bits! These are now available for download from here.

There is a lot that is new and updated in Beta 2! Here is a list of some of the things that you will be able to try out and give us feedback on. For additional details on each of these and more, see the release notes included with the Beta 2 package.

“Geneva” Server

· New rules engine for authoring claims transformation policies

· Ability to read attributes from AD, AD LDS, and SQL out of the box, plus pluggable provider model to enable access to other attributes stores

· Group policy-based Information Card provisioning for CardSpace “Geneva” clients

· Support for SAML 2.0 SP-Lite

· Proxy to enable authentication for users on the Internet when Geneva Server is on the intranet

· Scale out via farm and load balancer topology

· Powershell commandlets

· Support for AD RMS

· Utility for federating with the Microsoft Federation Gateway

“Geneva” Framework – IDFX

· Enhanced FedUtil Tool with local STS for easy offline development

· New Visual Studio templates for building claims-aware web applications, web services, and security token services

· Support for SharePoint 2007

· Revised token handlers

· Revised federation authentication module

· New Claims Authorization Manager API

· Updated config support

CardSpace

· Support for Group Policy-based Information Card provisioning.

· Updated management UI

· Updated card tile

· Group Policy-based way for administrator to make card selection decisions for specific sites

Improved provisioning of X509-backed cards
Compatible with most existing managed cards

We are very excited to be able to deliver these bits to you, and to hear your feedback. Please send any technical questions about Geneva to the product team via our forum or support email address. We will continue to announce updates to Geneva on our website and here on our team blog.

Using the CardTile with “Geneva” Framework

CardSpaceBlog — Sat, 22 Nov 2008 04:42:00 GMT

In an earlier posts, Colin described how to handcraft a web page to implement the new CardTile feature of CardSpace “Geneva” and Oren points out a way to require user interaction during authentication. This post will now explain how the “Geneva” Framework makes implementing these features quick and easy.

The InformationCard Control

As mentioned in the introduction to the “Geneva” Framework, one of the biggest goals of the framework is to give developers the ability to build secure Relying Party (RP) websites with ease and still give them flexibility in website design. One way that we do this is with the InformationCard control. This new control allows developers to leverage the security of InformationCards on their web site with minimal effort while being able to customize its behavior and appearance so that it fits naturally into the site’s layout.

This post is going to focus on how to use the new CardSpace CardTile and how to require user interaction during authentication using the InformationCard control. We’ll go into greater detail on how to secure your site using this new control in a future post.

As a side note, implementing the CardTile with the InformationCard control will prevent card selectors that don’t support CardTile, such as previous versions of CardSpace, from being able to log users into the web site. We are currently investigating how this behavior should be changed for a future release.

Implementing the CardTile with the InformationCard Control

So you have the “Simple Web Application with Information Card SignIn” sample from the SDK up and running and you want to see how you can customize the appearance of the control. Using the CardTile is a great starting point. Colin’s post describes the need to modify the OBJECT tag by hand. If you’re using the InformationCard control that comes as part of the framework, all this will be automatically done for you.

To implement the CardTile, simply open the solution, view the Default.aspx from the CustomUserNameCardStsHostFactoryWebSite project, view the properties for the InformationCard control, and look for DisplayType property.

By default this is set to None. Change it to CardTile and you’re done! Or if you prefer to edit the source XHTML by hand, simply add the DisplayType=”CardTile” attributes to the InformationCard control as shown below.

<idfx:InformationCard ID="InformationCard1"

…

DisplayType="CardTile">

</idfx:InformationCard>

Save your changes, browse to the page in IE, and view the source code. You’ll see that the OBJECT tag has been generated to use the CardTile with the onclick event already wired for you. With one small change you’re taking advantage of the CardTile feature of CardSpace “Geneva”.

type="application/x-informationcard"

onclick="javascript:InfoCardOnClick();">

…

<param name="displayType"

value="CardTile" />

…

</object>

You can also change the default width and height of the CardTile by changing the DisplayTypeHeight and DisplayTypeWidth properties in VisualStudio.

Alternatively, if you choose to do this by editing the source XHTML, just add the DisplayTypeHeight and\or DisplayTypeWidth attributes to the control with the desired values.

<idfx:InformationCard ID="InformationCard1"

…

DisplayType="CardTile"

DisplayTypeHeight="40"

DisplayTypeWidth="60">

</idfx:InformationCard>

After the changes have been saved and you browse to your site, you’ll see the OBJECT tag is rendered with the values you specified.

type="application/x-informationcard"

onclick="javascript:InfoCardOnClick();">

…

<param name="displayType"

value="CardTile" />

<param name="height"

value="40" />

<param name="width"

value="60" />

</object>

Requiring User Interaction

As a web developer, you may see fit to have users manually authenticate every time they come to your site. This can be easily be implemented by enabling the RequireUserInteraction on the InformationCard control.

Still using the “Simple Web Application with Information Card SignIn” sample, in VisualStudio view properties of the InformationCard control and locate the RequireUserInteraction property. As shown below the default behavior is set to False. Change this to True and you’re ready to go.

To do this by editing the source XHTML, add the RequireUserInteraction attribute to the control.

<idfx:InformationCard ID="InformationCard1 "

…

RequireUserInteraction="True">

</idfx:InformationCard>

After you save your changes and visit the web site, you can see by the source HTML that the OBJECT tag now contains the requireUserInteraction parameter.

…

<param name="requireUserInteraction"

value="True" />

</object>

The “Geneva” Framework Makes Customizing Simple

As you can see the “Geneva” Framework allows developers to easily customize their website and take advantage of new card selector features like CardTile and RequireUserInteraction. Our goal is for web sites to be able to implement such features with as little effort possible.

Looking forward to your feedback!

Thank you,

Jason D. Shaw

Software Design Engineer in Test - “Geneva” Framework Team

Microsoft “Geneva” Framework

CardSpaceBlog — Tue, 04 Nov 2008 07:03:00 GMT

We’re excited to announce the Beta release of Microsoft Code Name “Geneva” Framework. This framework is the successor to our previous beta release code named “Zermatt”.

This release, in addition to adding some new features, polishes up many of the existing features that were available in the previous Zermatt release. Our primary motivation for the changes was to simplify the developer experience and better align it with existing technologies. In this post we’re going to discuss some of the changes in this release. Future posts will talk about the features below in greater detail.

Before delving into the details of the framework, we’d first like to point out that the framework is part of a larger wave of products known as “Geneva.” If you haven’t already done so, please be sure to visit http://www.microsoft.com/geneva for more information.

The following document provides a detailed overview of all the changes that were made between the previous release and this release. However, for purposes of keeping this blog post reasonably short, we’ll give a high level overview of some of these changes.

The New Claims Model

This release (as with the previous release) introduces a new claims model. This new model combines the claims world with the IIdentity/IPrincipal world that developers are familiar with into one concept called the IClaimsIdentity/IClaimsPrincipal that is fully compatible with the IIdentity/IPrincipal world. Furthermore, we’ve also replaced ClaimsPrincipal.Current with Thread.CurrentPrincipal as the mechanism by which an application accesses claims about the caller.

In this release, we’ve changed the type of the issuer of a claim, Claim.Issuer, to string instead of a collection of claims to simplify handling, and make the issuer identification independent of the credential that is used to sign issued security tokens. To support the Claim.Issuer as string, we have added a translation mechanism that supports converting an issuer’s signing credential (usually an X.509 certificate) into an issuer’s name. This mechanism is implemented by the IssuerNameRegistry class and is fully extensible so that developers can provide their own implementation for this translation. The framework itself ships with a simple, configuration-based translation implementation.

We’ve also introduced a new data field holding the original issuer of a claim: Claim.OriginalIssuer. This is useful for claims that traverse through a federated chain.

Claims Authentication

One of the pain points with our previous Beta was with not knowing where to authenticate the set of claims representing the user. The concept of authenticating the user existed in multiple places and it was hard to figure out where such an operation should be performed. To address this, we’ve introduced an easy to use extensibility model called the ClaimsAuthenticationManager as the one place to do authentication.

Token Handling Improvements

In this release, we’ve expanded the role of TokenHandlers. If you recall from our previous Beta, TokenHandlers were only used for processing SAML1.1, and SAML2.0 tokens. In this release however, we’ve expanded this model for all token types, including Username/Password, X509Certificates, Kerberos, Secure Sessions in WCF (SCT’s), and HttpCookies. This makes the programming model simpler and more consistent.

Authentication Module Improvements

One of the more prominent changes that we’ve made is to our ASP.NET relying party (RP) processing pipeline. In the previous release, we implemented a single Federated Authentication Module (FAM) that did all the heavy lifting whenever a token arrived at an ASP.NET RP. In this release, we’ve broken up the FAM into a set of authentication modules, namely the SessionAuthenticationModule, the WSFederationAuthenticationModule, and the ClaimsPrincipalHttpModule. These independent modules all work together to make the processing pipeline easier to understand, and provide a much better compatibility story with ASP.NET’s FormsAuthentication and UrlAuthorization modules.

Security Token Service (STS) Pipeline Improvements

We’ve improved the pipeline around building Security Token Services. In addition we’ve also added better support for an asynchronous pipeline.

Federation Establishment with an STS

Wouldn’t it be nice if there were an easy way to establish a trust relationship between your application and the SecurityTokenService it receives security tokens from? We’ve now included a new tool called FedUtil.exe to make this process easier.

Geneva Token Service

In some federation scenarios, an existing application can be written to accept, for example, a SAML token, but may need to translate this to a Windows account.

The “Geneva” Token Service is a Windows NT service that gets installed as a part of the Geneva Framework. This service can translate the incoming SAML token into Windows identities that can be then used by your application to authorize the caller and to access other services using Windows authentication. With this Beta, whenever your STS issues you a SAML token that has a UPN claim in it, the Geneva Framework has functionality that will automatically convert this token into a WindowsToken for you.

ASP.Net control for Windows® CardSpace “Geneva” Beta

The “Geneva” framework continues to make it easier for developers to write an ASP.NET relying party that works seamlessly with Information Cards. Our Information Card SignIn control now exposes new properties, like Card Tile and RequireUserInteraction that work well with this new Beta version of Windows® CardSpace “Geneva”.

Give us your feedback!

Please give us your feedback and tell us what you think. The features described above provide just a glimpse of the changes that went into this release. We’ve tried hard to make the programming model simpler, and better aligned with some of the existing ASP.NET/WCF environments.

- The “Geneva” Framework Team

"Geneva" Beta available now

CardSpaceBlog — Wed, 29 Oct 2008 03:35:00 GMT

The Federated Identity ”Geneva” team is happy to announce the release of Microsoft code name “Geneva”, an open platform for simplified user access based on claims. This release consists of three components: Geneva Framework for .NET developers, Geneva Server for IT Pros, and Windows CardSpace “Geneva”.

You can find all of our installation downloads and supporting documentation for each component of the Geneva platform on the “Geneva” Connect site.

As our team now has three products available we will begin discussing them all on this site. We will continue to discuss details about CardSpace here, but you can also look forward to details on the “Geneva” Server and Framework on this blog. We also have a dedicated forum for “Geneva” available on MSDN.

We look forward to hearing from you about our new release!

- The Federated Identity “Geneva” team