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!

SharePoint 2010: Search Service is not able to connect to the machine that hosts the administration component

Had a strange Search error in a new SharePoint 2010 farm:

The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component 'bae8d161-c132-4570-aa0d-57baf6cf9d9b' in search application 'Search Service Application 1' is in a good state and try again."

I was unable to start any crawls as a result.

The search services were all started correctly but in the Application Services window it showed “Error”. The fix for me was to click on the Search Service Application name in the list of Application Services, choose Properties on the ribbon above, and change the Application Pool to another one (in my case, from SharePoint Web Services Default app pool to SharePoint Web Services System).

Hope it helps someone.

Using LDAP Authentication With A SharePoint Intranet Is A Very Bad Idea

A couple of years ago I wrote an article explaining step-by-step how to integrate Novell e-Directory with SharePoint. At the time it was pretty much the only available information on the web. Since then I have frequently been asked for tips on integrating LDAP with SharePoint intranets, most recently last week. So I thought I would provide some updated advice:

Run away! Run far, far away.

1. Get one of your colleagues to distract your boss.
2. Climb out of your office window.
3. Head for the nearest bus, train station, or airport.
4. Change your name.

If somehow your boss or client finds you and demands that you integrate LDAP with the SharePoint intranet, explain why it's a very bad idea.

Why is it a Very Bad Idea?

 

From a technical perspective LDAP integration is really just Forms Based Authentication (FBA) - you are passing in a username and password to SharePoint, and these happen to be authenticated via LDAP calls to an identity store somewhere.

Using LDAP, logging into your SharePoint portal will look like this:

Doing this is a big mistake!

Reason #1: Time Spent Tinkering

Now in order to do this, there are a variety of technical steps you need to take. If you run into problems anywhere along the way, you will spend your valuable time trying to figure out if the problem is in your Role and Membership provider settings, in your various web.configs, your LDAP query, or something else you have to enable in SharePoint.

This means you are spending your effort (and your client or employer's money) struggling to implement something that with Active Directory would "just work".

Some might argue that this isn't a great reason - after all plenty of time and effort goes into modifying SharePoint to accomplish other requirements. But any effort you expend making SharePoint work without AD is time you could be spending modifying SharePoint to address problems the business actually cares about. The business does not care that its credentials are currently stored in Novell eDirectory and SharePoint prefers them in AD.

Reason #2: Your SharePoint Intranet Won't Work The Way You Expect

Portal users expect seamless integration and functionality when they are using SharePoint for the intranet, because that's what all the marketing materials teach them to expect.

Building an intranet without Active Directory can lead to some surprising and annoying side effects. Out of the box web parts or controls like the Organizational Hierarchy don't work very well without Active Directory. You can make them
work with ADAM or by exploring 3rd party replacements but you'll have to test any portal functionality you think you are likely to use.

Also, the user experience with Microsoft Office integration can become a problem. Open up Word or Excel when logged in using LDAP credentials and you might see this:

It's fun explaining that to an end user!

SharePoint Designer is also tricky - it wants to automatically authenticate you using windows credentials, and throws errors when it runs into forms based authentication.

I'm not claiming that these issues are insurmountable, but collectively they introduce new bugs, development, testing, and management issues, increase cost and risk, and potentially annoy your users. Is it really worth it?

How Is that Different from Internet or Extranet Environments?

Many extranet and internet environments use Forms Based Authentication without problems. Administrators or installers have to modify SharePoint to work in these zones using Role and Membership providers...So why is it ok for those environments to use FBA but not the Intranet?

Again, it's a question of user expectations. When a user logs on to an extranet or internet site, they don't expect seamless Office integration and automatic access to file shares using their desktop credentials. When they use SharePoint intranets, they do expect these conveniences.

All the literature and sales material tells them that they should be able to interact directly with SharePoint intranets via Outlook, Word, and Excel - without annoying popup boxes and workarounds. They expect to be able to use all of the out of the box controls and web parts like the Organizational Hierarchy, and don't want to hear excuses like "that works best with Active Directory so we can't use that now".

So What Should You Do?

I recommend synchronizing your e-Directory identity information into an Active Directory domain and building SharePoint on top of that.

There are a variety of ways to do this but one way you can investigate is via Novell's IDM which can synchronize between e-Directory and Active Directory.  Your e-Directory is still the master identity store, but any e-Directory changes get automatically sync' ed to the child Active Directory. Here's a link that might help: http://www.novell.com/coolsolutions/appnote/18349.html

You can definitely make SharePoint use multiple identity providers - but the reality is your SharePoint portal becomes much more flaky and expensive to manage. These days there are many ways to populate Active Directory from some other identity store - I always recommend that since it is less effort and risk down the road, and (probably) less cost as well.

SharePoint is complicated enough without adding to the challenges.

Of course your mileage might vary. If you have attempted (or succeeded) in integrating a SharePoint intranet with LDAP what were your experiences? Besides IDM, are there other good ways to synchronize Active Directory with a master identity store?

Follow up to "No authority could be contacted for authentication"

Anthony Moore, an IT Manager at LivePoint, provided me with some more understanding of the root causes of yesterday's demo machine errors.

Each machine in a domain has a password, (exactly like your username / password) and the passwords are reset periodically as well automatically though Active Directory...

If you restore an image of a machine to a prior state, the password in active directory becomes out of sync with [what] is stored in the machine, and the...issue can occur.

I imagine this isn't news to any Active Directory gurus out there but it clears things up for me. Going forward I will be including the AD Domain Controller in the server snapshots and rolling it back alongside the SharePoint virtual machines.

Hope this helps someone else. Thanks for the insight, Anthony!

"No authority could be contacted for authentication."

I have been giving weekly webinars using a demo environment that mimics 3 SharePoint farms (2 x MOSS 2007, 1 x SPS 2003). While prepping for tomorrow's demo I ran into some very strange SharePoint behaviour.

For no apparent reason, the default site collections no longer worked - they failed to load and couldn't see each other via a web browser. However, on both 2007 farms, I could still see and use the remote internet site collections just fine (using anonymous authentication on port 8000).

In the Event Viewer, various errors started complaining about DCOM saying things like

Reason: The trust relationship between this workstation and the primary domain failed. (Exception from HRESULT: 0x800706FD)

And when I viewed the other sites in the browser, I would get "Service Unavailable" errors and, eventually:

No authority could be contacted for authentication.

These errors, plus the fact that I could still use anonymous authentication, obviously pointed to something beyond SharePoint being the culprit. When these kind of authentication errors abound you don't have to look far beyond Active Directory to find the guilty puppy.

I eventually ran across this very helpful post by Noman Juzar Lakdawala on the ASP.NET forums:  http://forums.asp.net/t/986545.aspx

I followed his instructions and removed my servers one at a time from the domain, deleted the entry in the Domain Controller, and then readded them. Everything works now!

Not sure why AD got corrupted in the first place, so I will continue testing, but so far so good.  Thanks Noman!

I mentioned in a previous post that I was having trouble with Forms Based Authentication (Open LDAP) into SharePoint, or more specifically with the Client Integration part of it (opening Word and Excel when logged in using LDAP). I've received confirmation from Microsoft that this is by design: IIS and Office will only integrate using NTFS authentication.

Now, having said this, and having personally seen it not working, there is a chance you can still use Office integration and FBA. I'm linking to Mike Fitzmaurice's blog where he discusses this issue in detail: FitzBlog.

Willie Rust on his blog mentions that checking the "Sign me in automatically" checkbox when you log in using Forms Based Authentication will save a persistent cookie to your desktop.










I did try this, but the browser wouldn't let me sign in if tried this...It was either log in successfully without setting a persistent cookie; or fail to enter the site at all. So your mileage may vary. Good luck!

I've been struggling to implement Open LDAP Authentication. I've posted a technical article about it how to do it here. Today I ran into some more technical issues around it: the big one as mentioned is client integration but there is also an issue around web permissions.

I created a master page that had a variety of images, uploaded into a SharePoint portal's Style Library. This was done on the default port 80, which had Windows Authentication. When extending this app to allow LDAP Authentication, I had a problem: the image and css references in the master page all resolved to the new port number, and didn't show up, because they didn't exist in the SharePoint database for that application.

SharePoint Designer couldn't access the new LDAP site because of the client integration issue, so I couldn't upload the images and css to it.

As a workaround, I tried to hardcode the references to point to the port 80 site....it worked for some of my user accounts but not for others.

Finally I had to create a completely non-SharePoint site in IIS, make it anonymous authentication, stick all the images and css in there, and reference that site from the Master Page. Not pretty, but it worked.

The moral of the story: SharePoint and Forms-Based Authentication is PAINFUL.