Few weeks back I took a quick look at the new functionality available in Technical Preview 2 of Windows Server, with focus on things that might be interesting to the Office 365 admin. With the new TP3 released last week, it’s time for another look.
In comparison to the TP2, the changes in the AD FS role are less prominent with the TP3 version. We do get some new cmdlets (up to 164 now!), one new endpoint (the OpenID Connect UserInfo one, /adfs/userinfo), but no new claims. The biggest change is around the newly introduced Application Groups (which builds on the Clients we first saw introduced in TP2). Basically, an Application Group is a quick and easy way to configure your app to use AD FS for authentication. Those can be simple native apps, server-based daemons and Web APIs, or more complex, multi-tiered apps.
The simplest case is a native app, and all you need to provide in order to configure such is a Name, a (optional) description, and the redirect URI (i.e. the endpoint on which AD FS will exchange the tokens). And that’s all – the app is ready to use! The screenshot below is actually from a different template, but the settings are the same (you will not be presented with any other pages however).
A new ‘client’ will be automatically generated for the app, and you can edit the identifier later if needed. You can edit more than that – not only change the URI, but you can actually add another tier to the app, in effect switching between the different templates.
Adding a server application or website requires you to also select a method to authenticate to the AD FS server. Apart from using WIA, you can also use a JWT and/or a shared secret, which is welcome news.
Lastly, you can add a Web API, which allows you to configure Access control policies on the app in order to limit access to the app (remember, those are the ‘new’ claims rules). Before configuring the ACPs, you need to give a unique identifier (does this remind you of creating a new RPT?).
On top of that, you can also configure different ‘clients’, each with separate set of permissions (‘scopes’). As mentioned above, new client will be generated for your Server app, and by default it will be assigned the ‘openID’ scope (another piece of big news here – OpenID Connect is fully supported by AD FS now!). If needed, you can grant additional scopes and/or add additional clients as well.
Lastly, you will be presented with a summary page (would love to get a button for the PowerShell output on that!):
Once you have created the new Application Group, be it a single-tiered app or some convoluted combination of several different layers, you can pretty much get back in and edit all of the settings. Including adding/removing applications. Some other settings will become available as well – for example the Issuance Transform Rules tab will appear on the Web API Settings dialog. Note the similarity between those settings and the settings for a ‘regular’ RPT?
Let’s also talk a bit about the improvements we will get in the WAP role. We get Preauthentication for HTTP Basic applications, in other words publishing for non-claims aware RPTs. The WAP server will now cache the token received from the AD FS server, similarly to what was previously done by the Exchange Online server in Office 365 scenarios.
Next, we have HTTP to HTTPS redirection – if enabled, Web Application Proxy will also listen for incoming HTTP requests. Wildcard publishing will also be possible now, as well as pass-through publishing for HTTP. You can find the full list of improvements here.