SharePoint Conference 2011: Using Claims for Authorization in SharePoint 2010

Rough notes of the presentation by Antonio Maio at Titus Inc. Antonio walked everyone through a complicated Claims setup and made it look pretty easy.

Agenda

• What are Claims?
• How they are used in 2010
• Enabling Authorization through claims
• Customer requirements and scenarios
• Infrastructure and Architecture
• Demonstrations
• Benefits and Goals

What are Claims?

User attributes

Metadata about a user

AD Attributes / LDAP Directory Attributes

But really it’s an assertion I make about myself – “I’m a senior product manager” – and claims can be believed if they are backed up by a trusted identity provider.

Allows us to solve problems like federation and complicated authentication schemes

Deciding what we can see and do not only based on who we are but on our clearances or the type of data, or even if we connect via a secure connection and so on.

Examples – Claims about Antonio

• Name: Antonio Maio
• Department: Product Management
• Security Clearance: Secret
• Employment Status: FTE
• Country of Birth: Canada
• ITAR Authorized: No

How Are Claims Used In SharePoint 2010?

• Authentication
• Single Signon across systems across domains
• Maintain End User privacy (you can configure who can see what)
• Authorization

Claims for Authentication in SharePoint 2010

New option in SP2010

Allows: Claims Based, Classic Mode (Windows), and Forms Based – must be configured via claims

Using Claims – authorization can be specific to the user. Can be dynamic – ex changes in security clearance. Consider environmental attributes (ex current time, geo location, connection type, etc).

Enabling Authorizations Through Claims

Infrastructure and configuration has to be considered. Where are you going to store, manage, and retrieve claims.

Planning is required – policies

Development required or 3rd party applications. Native SharePoint 2010 functionality is manual. Use WS-Trust and WS-Federation to retrieve and validate claims. Design apps to verify specific required claims only – remember privacy.

Customer Scenarios

How do customers want to make use of Claims?

Document Metadata + User Claims

Ex Document classification and a user’s security clearance

Goal: Sensitive content sitting beside non-sensitive content

Policies and rule-based system that determines access control

Automation is critical and policies are simple to start.

"I believe you shouldn’t let security policies dictate where you manage your content”.

Keep policies simple to start and let the business drive new requirements.

Customer Scenario #1:

Claim: Employee Status.

Document Metadata: Classification (High Business Impact,Moderate Business Impact, Low Business Impact)

If employee.status=FTE and document.classification = HBI them PERMIT access to document

If employee.status=Contract and document.classification = HBI then DENY access to document

Customer Scenario #2:

Claim: Group membership

Document Metadata: Project

If user belongs to GroupX and belongs to GroupY and document.project=”eagle” then PERMIT access to document

If user belongs to Groupx and DOES NOT belong to GroupY and document.project=”eagle” then Deny access to document

Customer Scenario #3:

Claim: Client Case Numbers

Document Metadata: Document Case Number

If document.case=X AND client.casenumbers includes X then PERMIT access

If document.case=X AND client.casenumbers DOES NOT include X then DENY access

Infrastructure and Architecture

Client Web Browser talking to SharePoint:

1. User login (with user name and password)

2. SharePoint requests token  from Secure Token Server (ADFS v2 is an example)

3. ADFS2 wants to get claims about the user

4. Packages these claims up and signs them. Because there is a trust relationship set up between SP2010 and the claims provider SharePoint will trust this package

5. Then SharePoint does something with this claim token for authorization. SharePoint is the Relying Party application (it is RELYING on the trusted identify provider (ADFS in this case) for the claims

Demo

AD is running on its own W2008 R2 server. Using default schema, using OrganizationalStatus attribute

Setup

1, ADFS v2 Configuration – installed as Federation Server and IIS has self=signed certificate

2, Use Wizard to create new Federation Service in IIS – note the Federation Service Name.

3. Add a Claims Description – note the claims type URL

EmployeeStatus added by Adding Claim Description – uses this URL – http://schemas.sp.local/EmployeeStatus in the example and sends Claim to calling application

4. Add Relying Part Trust – selected WS-Federation Passive Protocol. Relying Part URL = “Federation Service Name” + “/_trust/”

Relying Party Trust Identifier – urn:ServerName:application – urn:sp-server-2010.sp.local:sharepoint2010

5. Create Claims Rules for the Relying Parties. Add SharePoint 2010 trust rule – use templates – Send LDAP attributes as Claims which allows us to map LDAP mappings to claims.

ex LDAP attribute: mail maps to E-Mail Address outgoing claim attribute

LDAP attribute: organizationalStatus maps to EmployeeStatus which we created earlier

7. View and export the ADFSv2 Token Signing Certificate = c:\adfs20Certificate.cer

Transforming Claims – Claims Rule Language

example: send custom claim called “EmployeePermission” with the value of Full Control if the user belongs to the SeniorManagement group and if the value of the employee’s organization attribute in AD is “Titus”

http://technet.microsoft.com/en-us/library/dd807118%28WS.10%29.aspx 

SharePoint 2010  Configuration

1. Create a new web app in central admin. Use Claims Based. Use NTLM to start. Ensure public URL matches the one in the ADFSv2 certificate – trust between this web app and the ADFSv2 server

Do not create a site collection yet

2. In IIS, setup SharePoint Site to use SSL

3. use powershell to map the claim types in SharePoint

Have to run new claims using Powershell

Will be provided on Titus.com blog where the information will be available on these steps.

4. In Central Admin, access authentication providers and check Trusted Identify Provider and then check next to the ADFSv2 Provider you added. Normally you would remove NTLM

5. Create your site collection.

6. Create sites and libraries.

 

Authorization Policies

Questions you need to ask:

• Which policies are right to protect the business?
• Which user attributes are important? Are you using AD or LDAP or something else?
• Which content items or content types are important?
• Which policy language do you need? (XACML, SECPAL, etc)

Tip: Keep it simple

Titus Demo

Install Metadata Security product as a Farm Solution

Apply rules to items or folders

Created 3 rules – High Business Impact, Moderate business impact, Low business impact.

Showed how Bob could log in as a contractor and not see HBE docs, could read Moderate impact, and could edit low business impact.

Then changed Bob in AD to be a Full Time Employee, and now Bob had full control over everything.

Goals and Benefits of Titus Metadata Security

Benefits:

• Security is automated
• Security is consistent
• Data Governance and Compliance Policies are fine grained.

Summary

Authentication and Authorization are different but both important. Use Claims today in SharePoint 2010.

Infrastructure and Planning is required

Plan policies with business stakeholders – Keep Simple to Start!