Links for 28-Apr

Pattern Matching in C# -- source code.

So, do you really need IQueryable<T>?  LINQ query patterns

Converting AD FS security properties to Claims. 

Creating a language on the DLR.

Links for 4-Mar

New IIS7 resources

IE8 web standards conformance -- Bleeding edge, not IE7, will be the default.

AD FS troubleshooting tool

Functional data structures out of nowhere

Links for 23-Nov

The challenge of teaching yourself a new programming language -- of which there are plenty of candidates (Ruby, F#, Erlang...) for reboring your thought processes with

Leadership advice from WWII -- still as valid today

Developing an STS with AD FS 2 (part 1)

Ruby.Net 0.9 release -- compiles your Ruby code to an assembly, which the DLR doesn't as yet.

Links for 6-Nov

Visual Studio 2008 RTM and licensing announcement -- very interesting news about licensing changes

Memory leak debugging in JRuby -- you have to put out the garbage for it to be collected

Bram's Law -- oh so true.

More on the breakdown of the naive noun/verb OOP model 

AD FS documentation update on MSDN

Links for 31-Jul

Extending Java with Yield semantics

AD FS integration with Oracle Identity Federation

The Coming Software Patent Apocalypse -- This man speaks great wisdom

XRAY and MODIv2 -- DOM inspection bookmarklets

AD FS + Windows Integrated Authentication = Trap for the unwary

There is a quirk in the use of AD FS in its default intranet mode that may come as a surprise to the unwary user.

By default, AD FS sets up the Federation Server to take Windows Integrated authentication; out of the box, it also installs client certificate authentication, but you have to actively enable that by editing the root logon page at  /adfs/ls/clientlogon.aspx

<%@ Page language="c#" AutoEventWireup="false" ValidateRequest="false" %>
<%@ OutputCache Location="None" %>
<% Context.Response.Redirect("auth/integrated/"+Context.Request.Url.Query); %>

to do something other than redirect to the Integrated authentication page.

Now, the interesting thing about Windows Integrated authentication is that having authenticated explictly, your browser is already doing single sign-on (SSO) on your behalf every time you touch an authenticated URL. 

So, having authenticated once to the Federation Service, you are henceforth silently re-authenticated for the rest of the browser session.

"What has this got to do with AD FS?" you may be asking.

Well, AD FS is not only an SSO mechanism; for applications spread across many hosts, it also offers a single sign-off capability.

So let's talk our way through what goes on when all of these are happening at once

1. You go to an AD FS protected application
2. It redirects you to the Federation Server
3. That does integrated authentication, popping up a dialog box at the browser
4. Having logged on, you're redirected back to the application
5. Later, you log off that application -- AD FS directs you back to the Federation Server
6. The Federation Server sends you a page that removes its session cookies, and contains images whose URLs are part of AD FS on the application, so they can remove the session cookies
7. Now you go back to the application page, and--
8. AD FS redirects you to the Federation server which--
9. Silently reauthenticates you and sends you back to the application
   

Step 9 may come as a surprise to the unwary -- unless you have some obvious indication in the web application (such as a last sign-on time), the log-off appears not to have happened.

This is not a bug -- it is an inevitable consequence of an old SSO model with no sign-out capability being used to bootstrap the new federation system; and will happen with any silent re-authentication scheme (such as the alternative authentication mechanism provided in the install, which uses client certificates).

When re-authentication is not silent -- explicit form driven authentication at a Federation Service Proxy, for example -- step 9 is blatantly obvious. This may lull the user into complacency.

ADFS Troubleshooting : Part 1

I've been having to do some work on Web SSO at work, and to start with I wanted to take a simple ADFS set-up (as per the MSFT step-by-step test rig), and put my own certificate infrastructure on — an Enterprise CA for the server identities and a stand-alone CA for the assertion signing, just to make everything as clear and under control as possible. This wasn't too bad to set up, until it came to kick the tyres and do a trial authentication.

UnauthorisedAccessException in the WebSsoAuthenticationModule.OnEnter method. After the authentication had happened and the Federation Server was sending the assertion back to the Web Agent. The error message was all about setting the process to have the appropriate access to “the resource”. What “resource”?

Server Error in '/testcode' Application.

---

Attempted to perform an unauthorized operation.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.

ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[UnauthorizedAccessException: Attempted to perform an unauthorized operation.] System.Web.Security.SingleSignOn.WebSsoAuthenticationModule.OnEnter(Object o, EventArgs args) +3352 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

---

Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.42

Even Google didn't help.

Yesterday, I'd had a problem where the web agent opened the SSL connection to the FS, and the connection was dropped just as soon as the SSL handshake was complete; but that went away without any of my doing when I tried it this morning. So I wondered if there was anything wrong with the time-zones, which meant it took 8+hours for certificates to become valid?

Well, it turned out that they were all on BST, but the FS and Web Agent were about 10 minutes adrift. So I synched them all up. And suddenly it all worked. And if I set the Web Agent machine's clock slow again (or sufficiently fast), the error re-appears.

If it was the result of having an assertion signed too far in the future, the response of the infrastructure was rather out of order.