Back in February, I posted a question on the Geneva forum about Adjusting token lifetimes at the Web Application Proxy (WAP) for external access:
Does the Web Application Proxy or AD FS have any separate controls for adjusting token lifetimes to a different value via WAP than directly at AD FS? I can see there’s a session cookie for EdgeAccessCookie that WAP issues but this seems to be entirely undocumented at present. I’ve poked around in C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config (also undocumented as far as I can tell) but I’m not finding anything there either. We used to have some of these controls (sort of) with TMG/UAG. Are they totally gone now? With the AD FS Proxy this was less of an issue because it was only publishing AD FS but this is something that I’d hope to be able to control with a Reverse Proxy. Any ideas?
I didn’t get any replies, but after carrying out some tests of my own, I noticed the EdgeAccessCookie, and found a bit of information on TechNet:
After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:
- The resource identifier that the user attempted to access.
- The user’s identity as a user principal name (UPN).
- The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.
- Signature of the information in the edge token.
Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:
- Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.
- Validates that the token was issued for the correct application.
- Validates that the token has not expired.
- Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.
If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.
This quickly became one of those things where there was insufficient documentation and limited project time, so I had to put this inquiry on hold. Then in July, I posted a question on the Application Proxy blog (a great resource), to see if this is something that they planned to document. The response that I got from Ian Parramore was unexpected and pleasing:
Continue reading “Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks”
After a brief diversion, I’m returning to my series on SharePoint with RMS. This post finishes off the baseline considerations, although there’s a lot more to say. But at last, in this post, we’ve reached the point where we know that RMS thinks I’m cool – so now what? Or if you prefer, I’m taking a look at the RMS Use License that is typically embedded in Microsoft Office documents, or in other cases might be associated with a client’s machine.
The Use License that RMS issues acts like an offline enforcer of allowed rights. The rights granted by RMS and the duration they persist define what a user can do with their offline copy of RMS-protected content and how long they can continue to take those actions before they need to re-visit SharePoint and the RMS infrastructure in order to claim fresh rights. Since rights persistence is defined by the owner(s) of a SharePoint list, the impact of those settings should be well understood by any users that have this control.This post focuses on what a user can do offline once RMS has done its job, and the user’s experience once those rights expire, bringing the tension between valid offline access versus timely rights revocation to the fore.
You will notice I’m talking about offline access a lot here. When I say “offline” in reference to RMS-protected content, I mean the documents that have already been encrypted by RMS and decrypted/opened by a user. I say the files are offline because the original unencrypted content still resides in the SharePoint content database. Any edits that RMS allows a user to make to the offline content need to be saved back to SharePoint if they will persist over time. Continue reading “RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010”
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.
Continue reading “Office 365 Single Sign Out with ISA or TMG as the ADFS Proxy”