authentication Archives - Tristan Watkins on IT Infrastructure

Many people think of AD FS as merely a federated authentication service. And with a name like Active Directory Federation Services, it’s easy to see why. However, it also has the capacity to make authorisation decisions within its Claims Engine. This may be most familiar as the Office 365 Client Access Policies, but those policies are basically just a flavour of AD FS Issuance Authorisation Rules. An AD FS Issuance Authorisation rule provides a gate at AD FS, where permissions can be granted or denied to authentic users, per-Relying Party, before giving the user Claims for the requested Relying Party. In most cases we will think about these rules as coarse controls, to block a wide category of requests, such as those originating from outside the network, for members of a group, or for any combination of request-based, device-based and user attribute-based Claims. We can even create authorisation rules based on the user’s Identity Provider, or from additional factors of authentication. We will typically still implement most of our authorisation logic within the Relying Parties we are authenticating to, but in some cases it’s very useful to control access at this intermediary tier – especially if a large class of users, devices or networks should be treated as higher risk.

These concepts are not new, and the TechNet documentation I reference here dates back to the earliest wave of AD FS 2.0 RTW content:

Ultimately, I think these articles do answer the question of how to create an AD FS Issuance Authorisation rule, but I can’t point very clearly to the place on these pages that spells it out, and I do think there is a lot of confusing information about this in other places which may lead people astray. Namely, there is a lot of information that only concerns itself with the default Active Directory Claims Provider Rules and the Claims that come from request headers. Also, some of the most referenced AD FS + SharePoint content seems to have been written without authorisation rules in-mind. I want to try to clear some of that up in this post.

UPDATE 24/2/2015
I’ve added a fairly significant update regarding the new MFA stage in the pipeline half-way down this post.

Continue reading “The Rules of AD FS Claims Rules”

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”