“Geneva” Team Blog : CardSpace "Geneva"

CardSpace Geneva Beta 2 Samples Package

CardSpaceBlog — Tue, 28 Jul 2009 21:08:00 GMT

With the release of Beta 2 comes a set of samples specifically targeted towards CardSpace developers. Whether you are a web developer or a C++ programmer, you are sure to learn something new in our CardSpace Geneva Beta 2 Samples.

The samples pack covers three broad areas:

· A series of incremental web page samples showing how to invoke CardSpace, culminating in a sample that shows error handling and progress spinners for long-running operations like policy and token retrieval.

· A sample that shows using Geneva Framework’s WSFederationAuthenticationModule to protect a web site with CardSpace credentials.

· A sample for VC++ programmers that demonstrates CardSpace’s API for native programs. If you have wanted to include the CardTile in your own program or browser extension, this is for you!

To install the samples, just unzip them and follow the instructions in the included readme file. Enjoy! If you have any feedback, please share it in the forums.

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.

Silent Information Card Provisioning

CardSpaceBlog — Mon, 15 Jun 2009 20:51:00 GMT

One obstacle that administrators looking to deploy information cards in an enterprise will inevitably face is getting information cards to their users. Nobody wants to have to send an email to their users saying that in order to access a web service, they’ll need to go to an issuance website and download an information card. Things should just work. With that in mind, the “Geneva” Server and CardSpace teams created Silent Card Provisioning, a feature that uses Group Policy to deploy information cards to domain users automatically.

Step by Step

Setting up Silent Card Provisioning is very simple. In the “Geneva” Server UI, select your information card and choose “Save Group Policy Template Files.” This will save group policy files called IdentitySelectorBaseGPTemplate and AutoCardProvisioningGPTemplate. The .adm versions of these files are needed for Windows Server 2003 domain controllers, while the .admx and .adml are for use in Windows Server 2008. For more details and a step-by-step guide to setting up silent card provisioning, see this link.

“Geneva” Server creates the necessary group policy templates for you.

Once the group policy is set on the domain controller, domain users with CardSpace “Geneva” will automatically connect to the server, download and install the card. This process happens silently and the user doesn’t have to know or worry about it. If anything about the card, such as the image or authentication types, is changed on the Server, CardSpace will automatically pick up those changes. If the card is disabled on the Server, CardSpace will delete it from client machines. This means that once CardSpace is installed, the user doesn’t have to do anything to get the cards they need.

Tips and tricks

· This feature integrates well with Card Usage Policy. By setting a card to be silently provisioned and automatically used, administrators can really streamline their user experience.

· The group policy template files specify the location of the Geneva Server, the issuer name, and the time interval to check for card updates. This interval is set to two days by default but can be made longer or shorter if necessary. In addition to updating at this interval, users will have their cards updated each time they log on.

· The easiest way to ensure that a client machine gets its group policy and cards updated right away is to log off and log back on. For testing, the following commands run from an administrative command prompt will also update a client’s card(s):

o GpUpdate /force

o "%PROGRAMFILES%\Windows CardSpace\bin\CSHelper.exe" /provision

Hopefully this feature will streamline your experience with Geneva in the enterprise and we look forward to hearing your feedback.

Oren Melzer
Software Development Engineer
“Geneva” Team

Enterprise Policy for Zero-click Sign-in Using Information Cards

CardSpaceBlog — Tue, 09 Jun 2009 20:08:00 GMT

Reducing your login steps one click at a time

One of the major goals of CardSpace “Geneva” is to streamline the login process and make it as quick and easy to understand as possible. In the first beta, as Oren outlines in his post, by building the card selector within the Windows-integrated Credential UI dialog, we provide a minimalistic login interface that has a familiar feel among Windows users. Also, the CardTile web control that Colin describes here uses the card image to quickly show the user the state of their login. For Beta 2 we’ve taken this streamlining one step further by introducing a group policy-based Card Usage Policy feature, which allows an administrator to designate Information Cards for automatic submission. This new feature was designed to walk hand-in-hand with the new Automatic Card Provisioning feature.

How Jerry the domain administrator can pick out cards for his users automatically

Let’s suppose Jerry, a domain administrator at Contoso, has provisioned Contoso Kerberos backed Information Cards to all members of his domain. Jerry has also built a SharePoint site that employees can log into using their new Contoso cards. When users login for the first time, they will be prompted with the CardSpace selector. Normally, the selector is designed to help the user make informed decisions about how they use their issued identities. However, in this case the card selection decision has already been made by the Jerry the Administrator. The Card Usage Policy feature allows Jerry to set up a domain policy that directs the CardSpace clients on his domain to use the provisioned cards automatically at his SharePoint site. With the policy in place, when a user browses to Jerry’s application the CardTile login control automatically finds the Contoso provisioned card in the user’s store and displays that card’s image on the login page. The user notices that an identity has already been picked out for them; all they have to do is click once and they’re immediately logged in without being prompted with a card selector.

What constitutes a Card Usage Policy

The Card Usage Policy feature makes use of the new ic09:CardType element that was recently incorporated into to the OASIS Identity Metasystem Interoperability Specification Version 1.1. Any card that is issued with the new CardType element can be added to an automatic card selection policy. The CardType serves as a card classification mechanism and it is a URI (e.g. a GUID with urn:GUID: prefix.) The CardType is not unique to a specific Information Card and all cards that are issued from the same source or for the same purpose will typically share a common CardType. A Card Usage Policy is made up of a set of CardTypes. Each CardType can be associated with a list of target applications to which it can be used. Jerry uses the Windows Group Policy Editor snap-in to configure the card selection policy he wishes to have pushed to his domain joined users. For a step-by-step guide on how to do this, please see the section Configuring "Geneva" Server to Issue Information Cards in the Geneva Server SbS Guide.

Application patterns and hostname wildcards in a Card Usage Policy

A Card Usage Policy is mapped to a web application using an application pattern, which is in the simplest sense a subset of the full URL of the application’s login page. Jerry’s application login page is hosted at jerry.contoso.com/apps/sharepoint/Login.aspx, so to match his provisioned Information Cards to his application Jerry enters the host name “jerry.contoso.com”. Jerry can make his policy more specific by including the application path. For example, “jerry.contoso.com/apps” will match to all login pages hosted under the “apps” path. The path can be as specific or generic as Jerry wants, but it’s important to note that a card policy will apply to anything hosted under the path of a given application pattern. Jerry can also make the pattern more generic by replacing the leftmost dot delimited components of the hostname with wildcards. Let’s suppose Jerry’s colleague Amanda hosts a Contoso claims enabled application at amanda.contoso.com/reports/Login.aspx, and she wants to be included in Jerry’s Card Usage Policy. Jerry can include Amanda’s application by changing his application pattern to “*.contoso.com”. While handy, the application path wildcard comes with a few restrictions. It can only be included in the hostname portion of an application pattern, and the wildcard must always compose the leftmost piece of a dot delimited hostname. For example, patterns such as “www.*.contoso.com” or “*ntoso.com” will not work.

If you have any feedback or questions about the new Card Usage Policy feature, please check out the Geneva forum.

Andrew Lavers

Software Development Engineer in Test

CardSpace “Geneva”

Information Card Issuance: a small step for "Geneva" Server, a big leap for Federated Identity

CardSpaceBlog — Fri, 29 May 2009 05:26:00 GMT

Imagine this: you have been following this blog and have decided to try “Geneva” Beta 2. You have gone to the connect site and downloaded the "Geneva" platform components, installed them, configured the server, used the framework to write a claims-aware uber cool application, and set up trust between your server and the application. Now your users can log in and use your application and you can manage access easily. But that uses only two out of the three "Geneva" products. What does it mean to incorporate CardSpace "Geneva" into this scenario? From the server perspective, it means configuring information card issuance.

Intro

The "Geneva" Server in this scenario is configured to use the active directory that contains all your users. We call this role an Identity Provider STS because it authenticates users and produces tokens about their identities. One of the powerful features that “Geneva” Server gives an STS is the ability to issue cards that CardSpace "Geneva" stores and allows you to use to authenticate. For more information on cards see: http://blogs.msdn.com/card/archive/2008/05/20/backing-a-managed-card-with-alternate-credentials.aspx

Each part of our scenario needs to be properly configured:

· Your users need to have CardSpace “Geneva” installed (or compatible Identity Selector)

· The Server needs to issue cards.

· The application needs to support card selector log in

"Geneva" Server Card Issuance

Configuring a card is simple: the initial configuration wizard sets all required parameters. You can update any and all of them at any time. List of the parameters you can set:

· Card name

· Card image (typically your organization's logo)

· Privacy Notice (optional)

· Authentication type (more in the next paragraph)

· Certificate to sign the card (this is located in the certificate settings)

Choosing an authentication type depends on your deployment, and the strength of authentication you wish to enforce. “Geneva” Server Beta 2 supports three types of authentication:

· Windows – by selecting this type, CardSpace performs Windows Integrated Authentication, which only works when the user is connecting from the internal network.

· Certificate – by selecting this type, CardSpace authenticates with a user certificate located on the user’s machine. This type works well for smart cards, and is especially useful for authenticating users outside of the corporate network in a highly secure way.

· Username and password – by selecting this type, CardSpace prompts the user for their domain user name and password. This type also works for authentication outside the corporate network.

The order of the authentication types will always be first Windows if present, next Certificate if present and last Username Password if present. The implication of this is that if you can turn on two authentication types, for example Windows and Certificate. Then inside a corporate network, users would automatically get authenticated with Windows Integrated Authentication. Outside a corporate network where Integrated Authentication is not available, authentication falls down on the next authentication type and users will get authenticated by their user certificate.

The initial configuration wizard does one more thing for you. It deploys a card issuance website from where users can download your spiffy new card. Note that by default access to the site is windows authentication based. Once the website is deployed you can customize it with your organization's name, logo, contact information, etc.

Tips

A subset of the settings that are part of the card file your users will download is derived directly from the STS settings. However to give the administrator more control over the process, changes to the STS that affect the card will not be applied to the card until the administrator chooses to do so and clicks the “Update Information Card” action.

The “Geneva” Server Beta 2 gives you a powerful new way to configure and maintain your configuration: PowerShell. I’d like to briefly note that there is a resource dedicated to configuring card issuance: GSInformationCard. There are five different cmdlets/verbs associated with this resource:

· Get-GSInformationCard,

· Set-GSInformationCard,

· Enable-GSInformationCard,

· Disable-GSInformationCard

· Update-GSInformationCard.

The GSInformationCard resource covers all UI capability and some additional parameters not visible in the UI, like explicitly adding claims and in depth management of certificate backed cards amongst others. Look to future posts for more details.

Conclusion

As you can see, “Geneva” Server provides quick access to the world of information cards:

· Simple, secure provisioning of cards to users

· Simple administration of the card

· Flexibility to provide/ensure specific authentication types

· Customizable site to provide users with familiar corporate site experience

A great reference for setting up information card issuance you can find here: http://technet.microsoft.com/en-us/library/dd807042(WS.10).aspx. And in the next post you are going to learn about a powerful feature build on top of card provisioning: silent card provisioning.

Veneta Tashev

Software Development Engineer in Test

“Geneva” Server Team

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.

“Geneva” at RSA2009 and TechEd

CardSpaceBlog — Wed, 29 Apr 2009 23:21:00 GMT

For the last several months, the Geneva team (CardSpace, Framework, and Server) have all been heads down, working on getting our Beta 2 out the door. And now, we are finally in the home stretch!

Geneva featured in RSA2009 keynote

One recurring theme at this year’s RSA conference has been identity. In Microsoft’s “Moving Towards End to End Trust: A Collaborative Effort” keynote, Scott Charney spent significant time discussing identity. You can watch the presentation here. (from the “Tuesday, April 21” menu).

Scott explained that to achieve end to end trust, we need to provide a missing “trusted people” layer to the trusted stack. The identity metasystem (listen from 21:02) and the “Geneva” platform (listen from 26:31) play an important role to fill the gap.

Geneva will be at TechEd

TechEd is coming up very soon. May 11-15, 2009. And the Geneva team will be there! There will be many sessions talking about Geneva, including two Hands-On-Labs. For a list of sessions, click here. (key word: Geneva) Additionally, we will, of course, have a booth at the expo where you can come by and meet us, or ask us questions.

Please stop by and give us your feedback!

Geneva TAP (Technology Adoption Program) Status

We have been overwhelmed by the amount of enthusiasm and the number of the very compelling applications to join our TAP. It was a very difficult process to try to choose the right set of varied scenarios and customers to support. We wanted to try to cover as diverse a set of different usage scenarios and customers as our team could support. But now, I am happy to say that our TAP program is underway. In the coming months, the things we learn from how these customers are deploying and using Geneva should find their way into a set of best practices and templates that everyone will benefit from. Expect to hear more about this in coming months as these take shape.

The CardSpace "Geneva" Control Panel Applet

CardSpaceBlog — Thu, 11 Dec 2008 04:19:00 GMT

Hello! My name is Robert Zhu and I am a developer on the CardSpace team. Today, I'd like to invite you on a brief tour of the CardSpace Control Panel Applet. The Control Panel Applet deals with the management of your Information Cards. From this component, you will be able to view, modify, and delete any Information Card in your possession. In addition to managing Cards, the Control Panel Applet also provides the ability to reset card history (card history keeps track of the Relying Parties at which specific Information Cards were used and what information was released).

To try it out, follow the steps below:

1- Install the CardSpace “Geneva” Beta

2- Install any card from the test site

3- Launch the CardSpace Control Panel Applet from the Control panel:

Control Panel -> User Accounts -> Windows CardSpace “Geneva”

Once you double-click on the Windows CardSpace “Geneva” icon, you should see the Management Interface (below):

The main page shows a complete collection of your Information Cards. To select an Information Card, click on it, and a blue highlight box should appear around your selection. Hold down CTRL while clicking to select multiple cards, or use CTRL+A to select all cards. Once you have made your selection, you can delete the specified cards by clicking the “Delete Card” link on the right. If you have just added a new Information Card to your collection, pressing ‘F5’ will refresh the list of cards.

As mentioned before, the Control Panel Applet provides the ability to reset all card history. To do this, click the “Delete all card history” link on the top left of the Management Interface. As mentioned in Oren’s post regarding automatic submission of credentials (http://blogs.msdn.com/card/archive/2008/11/18/the-cardspace-geneva-selection-experience.aspx#9128068), CardSpace displays a matching card that has been previously used at the site on subsequent visits. This decision is made by inspecting the card history; thus, deleting the card history has the consequence of resetting all your previous Card/RP associations. Think of it like clearing your browser’s page history.

In the future, we will be adding more features to the Management UI. Thanks for reading and your feedback is extremely valuable!

Robert Zhu,

Software Design Engineer

CardSpace “Geneva”

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

The CardSpace “Geneva” Selection Experience

CardSpaceBlog — Tue, 18 Nov 2008 06:33:00 GMT

My name is Oren Melzer and I’m a developer on the CardSpace team. In this post, I am going to talk a bit about the newly designed selector in the new CardSpace “Geneva” beta.

Based on feedback from v1, one of our primary goals in designing the CardSpace “Geneva” selector was to give the user a simple, quick, and in-context card selection experience. Quite simply, users don’t want a lengthy or complex login experience; users want to quickly and easily access the site they’re trying to visit. With that in mind, the CardSpace “Geneva” selection experience was designed to be seamless. At a glance, users can see where their information is going and what data they’re sending. At the same time, they’re never more than a few clicks away from being authenticated.

The CardSpace “Geneva” selector uses Credential UI, a built-in Windows authentication mechanism that you may recognize from Remote Desktop Connection or smart card authentication. Credential UI allows CardSpace to operate in the context of the browser, so that the website the user is accessing is still visible.

The selector keeps users in context by appearing within the browser

Keeping it simple

When a user clicks the CardTile or the “log in” button on a webpage, the selector comes up showing all of the user’s cards that match the site’s policy. If the user has previously logged in to the site using CardSpace, the most recently used card will show up first and will be selected by default. All the user needs to do to log in is choose a card, authenticate to the Identity Provider (which may happen silently in the case of certificate or Kerberos backed cards), and click OK.

Users may also wish to review the personal data that they are submitting. To do this, the user simply clicks on “What information will be sent?” to review the display token returned by the Identity Provider. This functionality is equivalent to the “Preview” button in CardSpace v1.

"Show me what will be sent" allows users to review their data before submitting it.

“Always use this card at this site”

One new feature in the CardSpace “Geneva” beta is the ability to use a card automatically at a website. If the corresponding box is checked and the card is successfully submitted, CardSpace will automatically use the given card to log in to this site in the future, saving any credentials used. During subsequent logins to the same site, the user won’t be presented with the selector. Note that in the case of smart card backed cards, users will still have to authenticate to their smart cards. In the current beta, users can undo automatic card use by opening the CardSpace “Geneva” control panel applet and choosing “Delete all card history.”

Website developers should keep in mind that multiple users sometimes share the same Windows account and they may wish to log in to the same site using different cards. Websites may include an alternate object tag with the “requireUserInteraction” parameter set to true (see below) that allows the user to log in with a different card even if the user has chosen to always use a card. Should the user choose a different card, CardSpace “Geneva” will no longer use the previously chosen card automatically.

< OBJECT ID='infocard' type='application/x-informationCard' >
... other parameters here ...
< param name='requireUserInteraction' value='True' />
</OBJECT>

Information for developers

The following additional information may be useful for web developers:

· If the connection to a site does not use https, the selector displays a large warning advising the user not to submit sensitive data to the site.

If the connection is not over SSL, the user is warned not to send sensitive information.

· To mitigate spoofing attacks, the CardSpace selector limits the total length of the fully qualified domain name and scheme to 50 characters. The CardSpace selector will not be shown on sites with names longer than this limit. In corporate usage scenarios, system administrators may override this limit up to a maximum of 128 by setting a DWORD registry key at HKLM\Software\Microsoft\CardSpace\MaxHostNameLength.

Want to see the selector in action?

Go install CardSpace “Geneva” and try it out – if you don’t have a card, you can download an example card on the demo page.

Thanks,

Oren Melzer

Software Development Engineer

CardSpace “Geneva”

New in CardSpace "Geneva": the CardTile

CardSpaceBlog — Thu, 06 Nov 2008 00:36:00 GMT

Hi, my name is Colin Dellow and I'm a developer on the CardSpace team.

In Windows CardSpace "Geneva" beta, we've added a visual component to the OBJECT tag that we call the "CardTile." The CardTile shows the user the last card they submitted to a given site or the purple Information Card icon if they have never sent a card. Showing the user an image of the card they last submitted assures them it's the same site that they are returning to and that they have previously submitted a card to it.

Websites must explicitly opt into this feature; existing pages that use the object tag will continue to work as they always have, opening CardSpace for card selection. Even though the CardTile control is rendered in the page, the images shown by the control are not accessible to the page – it is not even possible for the page to know whether the image being shown is the Information Card icon or the user's most recent card.

Want to try it out?

Go install CardSpace "Geneva" and try it out – if you don't have a card, you can download an example card on the demo page.

Want to use it on your webpage?

To use the CardTile feature you will need to add the new displayType parameter to the OBJECT tag:

Stay tuned for future posts that describe how to do this using "Geneva" Framework, which also provides support for processing the token returned by CardSpace.

On their first visit, users will see a purple "I" CardTile indicating that they have never submitted a card to the site:

After submitting a card to the site, the tile will render differently for the user on subsequent visits:

This image tells the user that they have visited the site before and have most recently used the Fabrikam card.

A few notes:

The decision of which card to show isn't really as simple as the last used card – in fact, it is the last used card that matches the site's current policy requirements
The onclick attribute is an optional attribute; if set, the user's cursor will turn into a hand when it hovers over the CardTile, and the specified JavaScript will be executed when the user clicks

The default size of the CardTile is 120 pixels by 80 pixels, but this can be overridden:

We have only shipped support for the CardTile in the Internet Explorer plugin that comes with CardSpace "Geneva." In a separate post, we will document how other browser add-ons can also access this functionality in the beta.

Thanks,

Colin

Windows® CardSpace “Geneva” Beta

CardSpaceBlog — Wed, 29 Oct 2008 19:15:00 GMT

We’re excited to share news about the next version of CardSpace with you. In this post we’ll discuss the feedback customers shared with us about the first version, the goals we’re working towards, and the work-in-progress beta that you can download and try out today.

First and foremost, we’re proud that CardSpace is no longer an only child! We’ve announced two new siblings: Geneva Server for IT Pros and Geneva Framework for.NET developers. Both can help you deploy CardSpace for user access or can implement claims-based access without CardSpace. It’s your choice to tailor how the pieces work together for your needs. All three are available to download from Microsoft Connect.

The CardSpace “Geneva” beta available today responds to feedback we’ve received about the first version CardSpace download size and user experience. This early version of CardSpace is a brand new code base and we are still early in the development cycle. While it is far from feature-complete today, we wanted to get this out to you now so you can understand the directions we’re going with CardSpace and have an opportunity to give us feedback.

When less is more

Quite logically, users who didn’t have CardSpace installed on their system wanted the download to be as small as possible. With that goal in mind, the current beta version has been re-factored to a download that’s as small as 6MB for x86 systems, compared to the greater than 50MB required for the original CardSpace. The final version of CardSpace “Geneva” will work with the .NET Framework, but due to our refactoring work, CardSpace “Geneva” can now be downloaded separately and does not have a dependency on .NET Framework anymore.

We heard from web developers and users about the CardSpace user experience. The Information Card metaphor is powerful and resonates with anyone who has too many passwords or who understands the benefits of claims-based identity. At the same time though, both users and web developers told us that Information Cards should be a means to an end and not a distraction from the user’s original task.

In this beta, CardSpace “Geneva” takes on a minimalist form. Users now have a small, fast and straightforward prompt to choose their Information Card. Some users may recognize the prompt as the standard Windows Credential UI, and based on results from our usability studies, users will understand the context of the prompt at a glance. If the user decides to use an Information Card, sign in and claims presentation can be as simple as a single click. As you might expect, users still have the ability to review the claims from their card issuer before they release them. New in this version, the prompt also offers a “use this card automatically” option to bypass the prompt on future visits to the same site.

When users return to a site where they have already used a card, web sites can display the new CardSpace “CardTile” to show the image of the last card used, directly in the site layout. CardSpace doesn’t give out the image to the site; it simply shows the card image on behalf of the site as visual cue that lets the user know that they’re returning to a site where they’ve used a card before.

CardSpace “Geneva” still releases digitally signed security tokens to web sites. If a phishing site lured a user to accidentally use a card and submit a token, that token would not be “redeemable” at any other site and therefore is not useful for impersonating the user. Also, in the same way that offline card issuers can protect against fraud, Information Card issuers can help detect malicious use of a card and notify users before they interact with a known dangerous site.

What we think about the road ahead

It’s important to point out that the final version will include a lot of the functionality from the previous version missing from our current beta. Please hang tight while we work on our next update!

CardSpace v1 always ran on top of a “private desktop” that darkened the screen to help focus the user’s attention, similar to the security experiences in Windows Vista. We heard clear feedback that when signing into a website, the darkened screen could be too distracting. CardSpace “Geneva” does not use the “private desktop” but in the next beta, we plan to provide the option to run CardSpace on the Windows “secure desktop” for the high security scenarios where users or card-providers deem it necessary.

Much of the plumbing needed to support existing cards isn’t available yet in this beta, including the code to import and export cards from .crds files and support for personal (self-issued) cards. When included, self-issued cards will offer privacy conscious users or developers the ability use their own cards rather than downloading cards from a provider. We think of these as analogous to a business card, serving as an excellent introduction, but offering no third party verification of your identity.

Card issuers can enable retrieving the information that CardSpace needs to use a card either via the WS-MetadataExchange protocol or via HTTP GET over HTTPS. This beta only supports retrieving this information via HTTP GET. We will look into the support for WS-MetadataExchange for the next public release. This release continues to support the standard version of WS-Trust (version 1.3) for its interactions with an Identity Provider. This beta will not import the cards you may have currently installed with CardSpace v1. You will have to download and install those cards again to work with this beta.

We have not yet implemented support for the “PIN” codes a user could add to their cards in CardSpace v1. We also deferred validating SSL certificates with the Windows certificate store with the expectation that developers experimenting with this beta might use test SSL certificates with our beta.

Finally, we heard feedback that Relying Parties need more flexibility to choose what type of cards they can accept, such as being able to specify a list of issuers. We’re investigating how we can incorporate that flexibility, amongst many other important features not mentioned here, into a future update.

Tell us what you think!

Thanks,

Rob Franco, Mike Jones, Tariq Sharif, and Anand Sivaramakichenane for the Geneva 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