Terminal Services provisioning from a web page

The question: is it possible to set up a webpage to provide access to a Terminal Services based application ?
The answer: Of course ! And without using Citrix, even.

Microsoft offers the Remote Desktop Web Connection as a free addition or download for Windows XP or Windows Server.

This is a Web application consisting of a COM component and a sample connection page. When you deploy Remote Desktop Web Connection on a Web server, you can provide client connectivity to Terminal Servers and other computers using Internet Explorer and TCP/IP.

And the COM component is fully scriptable, making it possible to set up a page on which the user only has to click on a link or a button to go where he or she needs to go.

Links:
Remote Desktop Web Connection
Remote Desktop Web Connection Reference - programming reference

Web Identity and Authentication

I have been reading up on the subject of Web-based Identity, Authentication and Authorisation solutions and options, trying to put together enough of a vision to create a possible architecture to use in a corporate web presence situation.

Constraints are:

• Primary target is to give the customers of the corporation a SSO (Single Sign-On) or at least a reduced sign-on experience on the corporate webpresence.
• It must be Microsoft Windows based on the server end (following the corp's "Microsoft all the way" motto).
• It must be "open" in that it supports any browser on any operating system on the client end.
• It must be able to support 100.000 users or more.
• It's just for the Web, so solutions that (also) support client-side SSO are most likely not needed, or things like integration with legacy Oracle systems (for example).
• The corporate webpresence consists of the main website, in combination with a per-customer private area ( "My Site" ), some forms and sub-applications requiring authentication, and possibly in the near future, a number of community features like forums, weblogs, etc.

From what I have read, and given the constraints above, using an Active Directory based architecture will be the best solution. Most likely, the "stand-alone" ADAM directory server will prove to be the best option to serve as the "identity provider".

There are no storage limits. I recalled a 40.000 entry limit per AD container, but that's only the case if Active Directory is used together with Windows NT Backup Domain Controllers (as the SAM database format on that platform had its limitations).

Storage Limits
There are no practical limits to the number of objects stored in Active Directory. The Active Directory database has been tested for up to 40 million objects. Performance tests show logon performance for a single LDAP client to be the same with 10,000 objects, 100,000 objects, and 1 million objects — that is, the directory service does not slow measurably when the size of the database increases.
Storage Limits, Microsoft TechNet site

ADFS (Active Directory Federation Services) is part of the Windows 2003 Server R2 release. These two (out of four) possible scenario's fit very well with the requirements outlined above:

• Provide your employees or customers with seamless access to Web-based resources in any federation partner organization on the Internet without requiring employees or customers to log on more than once.
• Retain complete control over your employee or customer identities without using other sign-on providers (Microsoft .NET Passport, Liberty Alliance, and others).

See the ADFS Deployment Guide on the Microsoft TechNet site for details on how to implement this component.

Another possible part of the solution might be Windows CardSpace [Wikipedia], a part of the Microsoft .NET 3.0 Framework. It's very brand-new, so the question is how it fits in within the architecture, given that it should be possible to actually implement the resulting architecture in a reasonably short timefrom.

As far as I could determine, it needs (at this point in time) Windows Vista or at the very least IE7 on the client side, which means it doesn't quite fit with the constraints scetched at the top of this post.

There also isn't (yet) a direct way to use Active Directory as an identity provider for CardSpace.

Windows CardSpace and Active Directory
Active Directory is an obvious and important candidate for an identity provider. CardSpace is scheduled for release in early 2007, however, while no new release of Active Directory is scheduled until some time after that. Microsoft has said that Active Directory will eventually be able to act in the role of an identity provider, but no dates have been announced for when this functionality will be available.

A more immediate question is how CardSpace relates to Active Directory Federation Services (ADFS). ADFS is available today, and it can initially seem similar to CardSpace. In fact, however, these two technologies are quite different. CardSpace provides an identity selector and a self-issued identity provider, both of which run on a client machine. ADFS is server-based software that allows an organization using Active Directory to federate its identities with other organizations by using WS-Federation. Another important distinction is that, while a browser using CardSpace plays an active role, as described in the previous section, browsers are oblivious to ADFS—their role is entirely passive. While both are concerned with identity, CardSpace and ADFS perform very different functions.
Introducing Windows CardSpace, Microsoft MSDN

No definite answer yet, but my advise is to look seriously into a solution with Active Directory (probably the ADAM variant of it) as the identity store, and ADFS to enable various web applications to use Web SSO.

Links:
A Developer's Introduction To Active Directory Federation Services (MSDN Magazine, nov 2006)
Eclipse, Novell near 'Big Bang' for identity (Infoworld, 29-jan-2007)

ADFS
ADFS Deployment Guide
Setting up ADFS - how to set up an IT Lab for ADFS

Windows CardSpace