Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy

Over the last year I’ve spent a decent chunk of my time shaping and delivering Identity and Access Management workshops for Office 365 projects at Content and Code. This is generally underpinned by Active Directory Federation Services v2.0 (ADFS). In fact I don’t think we’ve done a single Office 365 project without it. Along the way I’ve become acquainted with many of the nuances of the sign on and sign out experiences as they differ across Office 365 services, client applications and different (valid) network perimeter technologies. In this post I will mainly focus on the security implications of publishing ADFS through ISA or TMG Reverse Proxies in the place of ADFS Proxy servers. In the majority of our engagements we’ve considered this option (potentially allowing our clients to consolidate infrastructure) since ISA, TMG or similar Reverse Proxies are commonly deployed. Yet we need to evaluate with full awareness of how ADFS operates without a Claims-aware Reverse Proxy such as the ADFS Proxy. This gets pretty technical, so I’m assuming some high-level familiarity with ADFS, Reverse Proxies and Office 365.

Contents

• Office 365 Identity Service Description
• Claims-Unaware Reverse Proxies
• Outlook Web App Sign Out Experience
• Sign Out from Other Office 365 Web Applications
• One Minute Reverse Proxy Session Lifetime
• Mitigations for Perceived Security Risks
• Using this Information

Office 365 Identity Service Description

First, let’s have a look at what the Office 365 Service Description for Identity has to say about the Sign In experience. Note: this is current as of May 2012, but is entirely subject to change. These descriptions are regularly updated.

The sign-in experience changes depending on the type of Office 365 identity in use: Cloud Identity or Federated Identity. Table 1 details the changes for different combinations of applications and operating systems.

Table 1: Sign-in experience with Office 365

Note

1 When first prompted, you can save your password for future use. You will not receive another prompt until you change the password. 2 You enter your corporate credentials. You can save your password and will not be prompted again until your password changes. 3 Outlook 2007 will be updated after Office 365 has been made generally available to have the same experience as Outlook 2010 on Windows 7. 4 All apps require you to enter your username or click to sign in. You are not prompted for your password if your computer is joined to the domain. 5 If you click on “Keep me signed in” you will not be prompted again until you sign out.

The key thing about this table is that it describes the user experience and the number of password prompts a user might see. For the Windows scenarios, these experiential differences are generally accounted for with the Keep Me Signed In tick box at the Microsoft Federation Gateway (login.microsoft.com) and the Windows Credential Manager. This is all reasonably straight-forward once you get your head around the differences above, but for federated users, this all changes if your organisation’s Reverse Proxy isn’t Claims-aware.

Update (26-7-2013): I’m not sure at what point something changed, or if the “Keep Me Signed In” tick box ever worked with the Windows Credential Manager (as I originally detailed above), but this is now implemented with cookies. It’s beyond the scope the scope of this post to get in to those details, but for now assume that what’s written below assumes this box has not been ticked.

Claims-Unaware Reverse Proxies

Typically we would consider the use of Claims-unaware Reverse Proxies to publish ADFS externally when we want to take advantage of existing infrastructure investments and/or when an organisation wants a significant period of Exchange co-existence. We’ve been dealing with a number of clients who are using ISA Server 2006 or Forefront TMG already (for instance, to publish Outlook Web Access or SharePoint), so we can potentially do away with the ADFS Proxies and eliminate two servers for our clients with this topology. We’ve also had a client with a very limited pool of remaining public IP addresses, which is another good reason this topology might be compelling.

While this may seem like quite a niche consideration, in most of our Office 365 engagements to-date it’s been valuable to step through this detail. Reducing on-premises infrastructure tends to be one of the key propositions that drive IT-lead cloud migrations. With new ADFS deployments we’re typically adding four on-premises servers (with the ADFS Proxies included), so we should really consider this opportunity to consolidate with existing infrastructure when it’s viable.

In principle this topology works fine, although there is an important nuance that comes in to play with one of the cookies that ADFS issues. MSISSignOut tracks all of the tokens that have been issued by ADFS (in this session) so a sign out request can invalidate all Relying Party sessions that ADFS has authenticated, rather than just signing out of the application where the request was initiated. This is what’s known as Single Sign Out or Single Logout. However, ISA/TMG haven’t been designed with SAML Claims in mind, so they can’t respond appropriately when the sign out process is initiated. It’s this variance in the Sign Out experience that warrants a closer look below.

Three further comments before moving on:

1. For clarity, we typically avoid the No Authentication ISA/TMG configuration, instead following the Access Onion’s TMG Pre-Authentication model (a fantastic blog, by the way, and one which this post in particular is indebted to).
2. Keep in mind that I’m only talking about browser-based access here since the session for the Outlook and Lync client is so tightly bound to the Windows session. Additionally, the full Outlook client or Lync’s use of the Microsoft Online Services Sign-On Assistant both rely on different types of federation to the passive federation we see here. All told, the risk profile, UX and underlying technologies are all different enough that they would warrant a separate discussion, but there really isn’t much to discuss when it comes to Sign Out from the full clients (as will hopefully become clear in due course).
3. This is all a description of what happens when a user presses the “Sign Out” button. If instead, a user closes the browser that also destroys the session, achieving sign out of everything that was just closed. Obviously the same isn’t true if some browser sessions are left open.

With all this said, let’s dive in.

Outlook Web App Sign Out Experience

For starters, I’ve sketched a high-level overview of this process, with more detail/explanation in text below.

Hopefully you can read my writing!

Inside the Network

First, let’s review what the sign out experience looks like for users inside the network. This is our baseline experience, cited here to show how the process is intended to work:

1. A user presses “Sign Out” in the Outlook Web App.
2. The user is signed out of the Outlook Web App.
3. The user is redirected to an ADFS Sign Out page. This occurs without traversing the Reverse Proxy since passive federation works with 302 redirects and internal name resolution should be configured to point at the ADFS servers directly since we should be in an environment with split DNS.
   1. At the ADFS Sign Out page the user will be signed out of ADFS, then redirected to the Microsoft Federation Gateway (MFG). The user’s tokens for all Office 365 web applications have been invalidated.

Outside the Network, Through ADFS Proxies

If a user is outside the network and we’re using ADFS Proxies, the user’s sign out experience appears to be the same since the ADFS Proxies handle the MSISSignOut cookie appropriately (by default). This allows the request to pass through the proxy without authentication, completing the sign out process at ADFS, redirecting to the MFG when complete, as above.

Outside the Network, Through an Active Claims-Unaware Reverse Proxy Session

Next, let’s review what the sign out experience looks like for a user outside the network if we use a Claims-unaware Reverse Proxy and the Reverse Proxy session hasn’t timed out when the user signs out of the Outlook Web App:

• The off-premises user will be signed out of ADFS, then redirected to the MFG in the same way it works for on-premises users above. In this case the user is successfully signed out of all Office 365 applications but this user has an active session at the Reverse Proxy. Within the lifetime of the Reverse Proxy’s session a user can re-authenticate to ADFS without getting prompted for credentials, since the proxy passes the already-collected credentials on to ADFS for the duration of the session. This doesn’t really have anything to do with ADFS or Office 365 per se. This is how the session at the Reverse Proxy has been configured. This is a strong reason to restrict the Reverse Proxy session lifetime for this listener. I typically recommend a one minute lifetime for these sessions, which is the minimum value. If we provisionally assume that this is a sensible recommendation then we’re typically going to see one of the scenarios below in reality because the Reverse Proxy session should expire before sign out is initiated from the Outlook Web App.

Outside the Network, Through an Expired Claims-Unaware Reverse Proxy Session

Now let’s review what the sign out experience looks like for a user outside the network if we use a Claims-unaware Reverse Proxy and the Reverse Proxy session has timed out when the user signs out of the Outlook Web App:

• The sign out process will successfully log the user out of the Outlook Web App and the user will be redirected to ADFS, but the user will be prompted for authentication at the Reverse Proxy before arriving at ADFS since the previous Reverse Proxy session has timed out. Keep in mind that in this case the user is being prompted for authentication so they can sign out, which is fairly unintuitive. I’ve dubbed this scenario, “Sign-In-to-Sign-Out”. One of two things will happen here:
  • If the user re-authenticates at the Reverse Proxy they will be signed out of ADFS and the user will be redirected to the MFG, completing the Single Sign Out process. In this case the user is successfully signed out of all Office 365 applications. However, they will have a new active session at the Reverse Proxy since the user just signed in again. It will be valid for the normal lifetime of a session even though the user thinks they just signed out. Keep in mind, this new session lifetime is probably just one minute if we’ve chosen to configure the Reverse Proxy as I suggest above.
    • Note: I think it’s unlikely that many users would step through this entire Sign-In-to-Sign-Out process with any regularity. But if they do, we need to understand that they may be walking away from their machine assuming they have done the best thing they can do as a security-conscious worker, yet they will have just renewed their session at the Reverse Proxy. In this scenario Single Sign Out succeeds but only because the user just signed in to the Reverse Proxy again. Hopefully this reinforces the benefits of having a one minute Reverse Proxy session lifetime.
  • Alternately, if the user does nothing when the Reverse Proxy prompts for authentication, they are still successfully signed out of the Outlook Web App. The catch is that any other active sessions in the browser with other Office 365 applications will remain active. These other sessions will still be available if a user presses “back” enough times to reach them or navigates through history to access them. In this scenario Sign Out succeeds but Single Sign Out fails. Put another way, Single Sign Out has been disrupted because our Reverse Proxy isn’t Claims-aware.

Outlook Web App Risk Assessment

In both of these cases the experience is kind of undesirable, but the magnitude of the risks will depend on how Office 365 is being used. If the Reverse Proxy session lifetime is reduced to one minute, most of these risks are minimised a great deal. The one lingering issue is the lack of a completed Single Sign Out if the user doesn’t Sign-In-to-Sign-Out, but this is simply not an issue for organisations that only use one Office 365 web application. Organisations that use more than one Office 365 web application may decide that the lack of reliable Single Sign Out is acceptable since most organisations will have been living without it up until now. Alternately, they may want to consider using ADFS Proxies or another Reverse Proxy. As I’ve indicated above, the only real drawbacks to using ADFS Proxies are the added infrastructure and the extra holes in the perimeter, but this is precisely the trade-off that needs to be sized up, between this security context and the opportunity to consolidate infrastructure. There are also other factors that I’ll throw in to the mix towards the bottom of this post.

Now let’s look at how this varies (marginally, but importantly) with the other Office 365 services.

Sign Out from Other Office 365 Web Applications

SharePoint Online Sign Out Experience

There are some further nuances with how SharePoint Online handles sign out slightly differently to the Outlook Web App:

• SharePoint Online prompts to close the browser after sign out is complete. This helps drive good practice (especially in this context) since closing the browser closes all open sessions.
  • This prompt only pops up after a user Signs-In-to-Sign-Out (if there’s a Claims-unaware Reverse Proxy in the mix).
    • If the user doesn’t complete the sign out process they will be signed out of SharePoint Online but Single Sign Out does not complete.
  • If a user choses “Sign in as different user” in SharePoint Online it effectively triggers a Sign Out (see above), but note that:
    • If the user is outside the network and…
      • if the session at the Claims-unaware Reverse Proxy has not yet timed out, then the user will be signed in as the same user again via proxy.
      • if the session at the Claims-unaware Reverse Proxy has timed out, then the user can re-authenticate as a different user.
    • If the user is inside the network, they will be signed on automatically via Integrated Windows Authentication, assuming they are using IE and the site is trusted – otherwise they will be prompted for credentials at the ADFS server and then they can sign in as whoever they like.
      • Because we would almost always recommend adding the ADFS site to Trusted Sites or Local Intranet Sites for automatic sign on, we would see this option most frequently in another browser. Note: this behaviour can be useful for testing.
• If SharePoint Online lists are taken offline in the full Outlook client or in SharePoint Workspace, the user will be prompted to sign in with a Microsoft Federation Gateway logon web page in order to sign on to ADFS. This follows the passive federation pattern of web applications rather than Outlook’s active federation. This is worth mentioning briefly, since it’s a common way to interact with SharePoint data, but the sign out considerations are in line with the full Outlook client rather than the browser-initiated sign on process, since sign out would typically occur when a user closes Outlook or logs out of the Windows session.

Lync Online Web Scheduler Sign Out Experience

The Lync Online Web Scheduler is a little-known web application that enables users to create meetings from diverse devices:

Microsoft Lync Online Web Scheduler is a web-based meeting scheduling and management tool for users who don’t have access to Microsoft Outlook, or are on an operating system not based on Windows. With Lync Online Web Scheduler, you can create new meetings, modify your existing meetings, and send invitations using your favorite email program.

Although I haven’t tested as rigorously as with the web applications above, I believe the Lync Online Web Scheduler sign out experience is the same as for the Outlook Web App.

Office 365 Portal Sign Out Experience

The Office 365 Portal will probably be used primarily by administrators but this may vary by organisation. Normal users may update their profile data, download Office clients or they may use the site for shortcuts to the Office 365 web applications.

What’s unusual about the portal is that the “Sign Out” button only works if the user Signs-In-to-Sign-Out at the Claims-unaware Reverse Proxy (completing Single Sign Out). If the user does not re-authenticate at the Claims-unaware Reverse Proxy they will be able to press “back” and the user will be able to take action in the Office 365 portal. Unlike the web applications above, Sign Out fails unless Single Sign Out succeeds. It’s worth mentioning again, that this is a non-issue with ADFS Proxies, as they are Claims-aware.

So… that’s the behaviour. Now let’s have a look under the hood.

One Minute Reverse Proxy Session Lifetime

I suspect my suggestion to reduce the Reverse Proxy session lifetime to one minute may raise a few eyebrows. What might not be clear is that this doesn’t dictate the web application session lifetime with the Outlook Web App, etc. because there are four tiers where cookies get issued when federating with Office 365:

1. ADFS
2. The Reverse Proxy
3. The Microsoft Federation Gateway (MFG)
4. The Office 365 web application that a user requests

So far we’ve been talking about the second of these tiers, which has a token lifetime that we can reduce to one minute since we don’t need to go back to ADFS for a while after we first authenticate (within a browser session). That should be straight-forward enough, but it raises the question of how long an Office 365 web application session remains valid. It goes something like this:

1. ADFS has a default value for the WebSSO Timeout. This value is 480 minutes unless it’s set to something else. All Relying Party Trusts created in ADFS will respect this value unless they are specified otherwise when the trust is created (or later updated).
   1. For Office 365 we create a trust between ADFS and the MFG. The Office 365 services don’t care about ADFS. They trust the MFG, which in turn trusts ADFS. The lifetime of the trust between ADFS and the MFG does not directly determine the Office 365 web application session lifetime in this configuration.
2. The Claims-unaware Reverse Proxy token lifetime can be set to a low value, since that lifetime doesn’t influence the length of an Office 365 user’s session. This token lifetime matters when:
   1. An Office 365 user’s session has expired with the requested web application (see point 4 below) and they need to re-authenticate with ADFS, or…
   2. Sign Out is initiated, as described above.
3. The MFG accepts the authentication token from ADFS and acts as a Federation Hub for the Office 365 services. The MFG issues the client a token that the client can use to authenticate to the Office 365 web applications.
4. The actual session lifetime that will matter most to a user is the lifetime of the session with the web application, which is controlled by the requested web application itself.
   1. The session lifetime for SharePoint Online is not configurable and is set to last for eight hours. It is valid only within a browser session.
   2. The default session lifetime for the Outlook Web App is the same as for SharePoint Online, although it can be modified with the Set-OrganizationConfig PowerShell command’s ActivityBasedAuthenticationTimeoutInterval switch. Note: I’ve not tried this command myself but it was pointed out to me when I queried these lifetimes with a trusted technical resource at Microsoft.

How to Reduce Session Lifetime in Forefront TMG

If you are interested in reducing the session lifetime in TMG go to the Advanced Form Options for the listener, then the Client Security Settings should be toggled to “Treat as maximum session duration” and the “Timeout for public computers” should be set to one minute, or whatever is acceptable for your organisation, given the descriptions above.

Mitigations for Perceived Security Risks

For most of our clients what I’ve outlined here has been acceptable at face value (if complicated). However, a few clients were still worried about security – particularly when users might log on to the Outlook Web App or SharePoint Online from an internet kiosk. In this section I’ll briefly outline some considerations that help establish a fuller context for evaluating those concerns.

Rich Clients Have a Different Risk Profile

As described above, we’re only really talking about browser-based access if we’re focusing on the sign out process, because it simply isn’t common for users to sign on to a full Outlook or Lync client from another user’s machine, and even when they do, it’s not clear what risk that presents.

Closing the Browser at the End of a Session “Just Works”

Everything that I’ve discussed above is irrelevant if a user closes a browser at the end of a session. In this case their session tokens will be destroyed; they will be logged out of all Office 365 web applications and will be prompted for authentication when a new session starts. This entire post has focused on the behaviour of the “Sign Out” button, for those users who press it.

The ADFS Proxy “Just Works”

You can always use the ADFS Proxy. Everything I’m talking about here is geared towards validating an alternative topology that may reduce the on-premises infrastructure requirements of federation with Microsoft for Office 365. Once we move beyond Office 365 to consider publishing SharePoint on-premises with SAML Claims, etc. this all becomes a lot more complicated, but if we’re only interested in publishing ADFS then the ADFS Proxy is an excellent default proposition.

Single Sign Out Assumes More Than One Service Is In Use

When an organisation is only using one of the Office 365 web applications, there is no need to have Single Sign Out, since sign out still works. In short, we see these risks when users access two or more of the Office 365 web applications in a single browser session. For the purposes of this comment, I’ve not focused on the Office 365 Portal or the Lync Online Web Scheduler. They should still be considered, but the risks that they present are probably going to be seen to be less significant.

Keystroke Logging is the Real Internet Kiosk Concern

If an organisation is focusing on the internet kiosk scenario then I think they need to pay equally-close attention to the risks that keystroke logging presents. In many ways, keystroke logging is a greater threat than a disrupted Single Sign Out experience. I would caution against focusing on the Single Sign Out scenarios I describe here to the exclusion of these risks at public kiosks and access points. I will also point out that most keystroke logging risks are equally prominent with remote access to on-premises applications.

In order to provide an ADFS solution for these keystroke logging risks we would typically look to Multiple-Factor Authentication (MFA) solutions, often implemented through a Reverse Proxy logon page customisation. Some third-party products already exist for ADFS, although a deeper consideration of this approach to enhancing ADFS security is beyond the scope of this post; the Office 365 Identity Service Description presents a high-level overview.

ADFS Client Access Policy Support is this Nut’s Sledgehammer

Lastly, external access can be restricted by configuring the ADFS Rollup Package’s Client Access Policy Support. However, this may have broader impacts like restricting device access and Lync. There’s a lot to consider here and it certainly stretches beyond the scope of this post. I would recommend reading the Limiting Access to Office 365 Services Based on the Location of the Client TechNet article and the Access Onion blog’s deeper dive if this is of interest. The AD DS team also published some recent information regarding the second Rollup Package, which builds on these options.

Using this Information

With a Claims-unaware Reverse Proxy such as ISA or TMG we introduce a tier in between ADFS and the MFG which doesn’t precisely fit. To this end, we need to bend its shape to our needs (assuming it’s acceptable for it to be there). For some organisations it still won’t be the right fit, but for other organisations it may be a perfectly acceptable place to consolidate infrastructure, which after all is one of the primary reasons why organisations adopt Office 365 services. In my experience there is no single best practice recommendation. The Reverse Proxy design needs to fit specific requirements and they should stretch beyond security to include business continuity plans, power consumption, usability, cost and more. With that entire picture in mind, the specific scenarios above can be evaluated clearly.

Disclaimer
None of this should be taken as gospel. The documentation for these technologies doesn’t speak to this scenario because it’s an interjection of a mismatched technology in the middle of the sign out flow. From my reading of the community there is some take-up of this approach, but keep in mind that we are all still gaining experience with ADFS and Office 365, so all of this should be tested thoroughly against specific requirements before moving on to production.