Microsoft recently released a draft guide to Data Governance for Privacy, Confidentiality and Compliance. It is written by Patrick Voon, Senior Governance Risk Management and Compliance (GRC) subject matter expert at Edgile Inc, a privately held consulting firm based in San Jose, California, USA.

This whitepaper is the first in a series that looks at different aspects of data governance. It opens with a brief overview of the entire whitepaper series. It then outlines the threats and challenges that organizations face in this area and looks at the concepts of governance, risk management, and compliance in general. From there, it examines the concept of data governance for privacy, confidentiality, and compliance (DGPCC) in particular. It closes with a brief overview of the objectives and overall process flow for a DGPCC initiative.

I think it's a good guide and is worth reading for anyone interested in data governance and compliance. It is introductory in content, providing an overview of some key drivers behind GRC, the growing importance of privacy controls that supplement security controls,  and the relationship between IT governance, compliance, and data governance.

The drivers noted by the paper include:

• an increasingly complex regulatory environment - the law is becoming increasingly restrictive and broader in scope, impacting a lot of business operations. Organizations will need to align and comply with these changes across the board, including IT departments. The governance implication here is that some of the decisions that are currently made by IT departments should in fact be made by the business with proper input from compliance and legal teams.
• consumer and citizen concerns about privacy - can organizations be trusted to treat private information properly? do they really do what they say they will do? who do they share data with? how do they protect against hacking and accidental loss of information? historically, businesses have considered themselves to "own" customer data. However, in the European Union and elsewhere legislation has been passed saying that this is not the case.

The paper provides an overview of Governance, Risk Management and Compliance and the relationship between these activities:

 the need for some kind of GRC approach to maintain the security of confidential data, the privacy of personal information, and related compliance obligations—while also maintaining alignment with business goals—becomes clear.

... In today’s organizations, no single group or entity holds all the relevant knowledge and expertise necessary to achieve this. The necessary knowledge might encompass organizational practices and processes, financial and legal aspects of the business, company policies, and market trends. An integrated approach—data governance—is required.

Data Governance is positioned as the solution to this, providing:

• protection of data against threats to security and privacy;
• compliance with applicable legislation and policy; and
• documented proof of compliance 

The document also provides a set of principles loosely based  on the OECD's Guidelines on the Protection of Privacy and Transborder Flows of Personal Data. (The OECD's guidelines are scoped to international-level privacy considerations aimed at helping harmonise national privacy legislation).

1. Honor policies throughout the confidential data lifespan
2. Minimize risk of unauthorized access or misuse of confidential data.
3. Minimize impact of confidential data loss
4. Document applicable controls and demonstrate their effectiveness.

As mentioned above I think it is worth reading and I'm looking forward to the other documents to be published in the series.

: 

Introduction

There is a lot of hype about claims based authentication, and unfortunately a lot of confusing jargon.   My goal in this post is to explain what claims based authentication means in plain English. This includes what it enables, and what it doesn’t enable. I am going to try my hardest not to use any technical terminology beyond the bare minimum.

What is authentication?

Authentication is the process of determining if someone is who they claim to be. It answers the question “Who is this guy really?”

In the Microsoft world, authentication is usually performed by Active Directory.  I claim to be Tristan, and i prove this to Active Directory by providing my password. Other systems don’t trust me, they trust Active Directory. Active Directory gives systems a bit of data that says “yeah, I personally vouch for this guy. It really is Tristan.”

Now, if everyone used the same Active Directory installation in the same environment, then that’s all we would need. Claims based authentication is not needed in a simple environment like that.

But in the real world, things are different. We face three big challenges:

• Privacy regulations and other pieces of legislation are impacting what kind of information we are allowed to capture and store about users, so in some cases we can’t just demand that people give us all of their personal details.
• Businesses want to interoperate with other businesses, and government organisations want to provide more integrated services to citizens. However, different systems use different authentication systems (not everyone uses Active Directory, and even when they do, they have different instances.), and businesses want to integrate in a secure, legally compliant manner.

What does claims based authentication do?

Claims based authentication is designed to address the two challenges mentioned above.

Claims based authentication addresses privacy and other compliance concerns by requesting less specific, less personal information about people, and by trusting other parties or systems to do the “proof of identity” check.

Imagine you have a “sell alcohol to public” ecommerce website, and you are in a country where there are only two laws, called Fantasyland. One of these laws says “alcohol may not be sold to people under 18”, and the other law says “people have a right to privacy and web sites aren’t allowed to track individual people”. (If the law was this simple in real life we wouldn’t need lawyers!)

We’ve got two competing concerns here. Firstly we need to ensure that a user is of legal age, while at the same time we’re not allowed to know who that user is! (Again, I blame the lawyers of Fantasyland).

It turns out that in Fantasyland, the Government has set up a web service that users log on to, which authenticates them based on their citizenId and citizenPassword. It then is able to tell other systems that a user is above 18 or not, without revealing who that user is.

So we implement our “sell alcohol to public” website by building a claims-aware system. Instead of building the standard “username and password” login mechanisms, we simply ask the Government’s web service to tell us if the user browsing our site is over 18. The claim that our system uses is a “userIsOver18” claim, and the claim value is either yes or no. We simply don’t build any authentication system at all beyond a simple “if (userIsOver18) then..“ statement.

By doing this, we address privacy concerns – we don’t know or keep personally identifiable information – while at the same time ensuring that we don’t sell alcohol to someone under 18.

Claims based authentication addresses integration of different systems by allowing communications using open standards, and by providing a platform for developing more specialised ‘identity connectors’ between systems.

What won’t it do for me?

Claims based authentication won’t address the lifecycle management of identity information. You’ll need a broader solution to that, but your solution may integrate with claims based authentication systems. How do you deal with new staff? How do you handle staff who are on long service leave? How do you handle fake accounts? Microsoft would like you to use their Identity Lifecycle Management application for this kind of thing.

I’m going to be a little controversial here, and point out what I believe the biggest limitation of claims based authentication. I believe that what enterprise customers really need is claims based authorization.  Claims based authentication may let our system know that a user is a contractor from a partner company, but it alone won’t let me specify a rule that says “all of my company’s financial spreadsheets must not be seen by contractors”. Not only does claims based authentication not provide this capability, but neither do the role-based access controls provided by SharePoint. In fact SharePoint’s role-based access control model itself is too limited to address this. It still needs substantial improvements.

The way industry is addressing this is by producing “entitlement management” systems, for specifying access control rules. Microsoft’s current solution, in my opinion, is strongly deficient in this regard. Yes, you can specify per item permissions for each individual financial spreadsheet. But this imposes such a high maintenance overhead that it is unworkable in practice. In my opinion companies like Oracle are well ahead of Microsoft in this field, but by no means does anyone have a complete turn-key solution.

How is it implemented?

The claims-based authentication implementation has a number of components. In simplified terms here’s how the pieces of technology fit together.

• From a developer’s point of view, the platform that Microsoft is providing is called the Windows Identity Foundation. This used to be called the Geneva framework. It provides a programming library suitable for building claims-aware applications. This library is also used by SharePoint 2010.
• Active Directory Federation Services implements services to create, accept, and transform tokens that contain claims.
• Cardspace provides a user interface for users to select which “identity card” they wish to use for a particular system

Next article

In the next article I will go into more detail about the implementation of Claims-based authentication in SharePoint 2010. Let me know what you thought of this article, and if you'd like to see focus on any particular aspect.