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 Data Governance: Achieve Consistent & Automated Security Webinar Invite

Next Friday September 30 I will be co-presenting a live webinar on SharePoint Data Governance with Microsoft and our partners Titus. I will be speaking to some real world examples of handling SharePoint security and regulatory compliance challenges using SharePoint and Titus Metadata Security.

The amount of data - and sensitive data - is growing within SharePoint environments every day, but is your organization set up to keep it all secure?

Date: September 30, 2011
Time: 12:00pm EST
Speakers:
Dr. Soheil Saadat
Principal Program Manager
Microsoft

Nick Kellett
Microsoft MVP & CTO
StoneShare

Antonio Maio
Senior Product Manager
TITUS

Register Now!

You can find out more information on our StoneShare.com website here:

http://www.stoneshare.com/news/Pages/TitusLabsWebinar.aspx

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?

Anonymously Searching User Profiles in MOSS

I had a requirement the other day to enable anonymous access on an internal portal and allow users to search across the user profile database - to create what was essentially a corporate directory.

The anonymous "core requirement" was to ensure users didn't have to log in when trying to look up their colleagues (they are using the dreaded Novell e-Directory which does not play nicely with SharePoint). Anyway this time the issue wasn't importing the e-Directory accounts but rather a 401 - Unauthorized error that kept appearing when trying to view the people results.

I tried the following things:

• I enabled Anonymous access first on the Search Centre lists and libraries and eventually on the entire site collection
• I added IUSR as a member of Intranet Viewers and made sure that in the policy permissions for anonymous users they had a limited read policy setup
• I tried to add IUSR_ to the SSP Settings - "Process Accounts with access to this SSP"
• I manually turned on anonymous access to some of the individual mysite site collections that I was trying to view
• I modified the My Site settings in the SSP to allow IUSR to be part of the default readers group and for any existing My Sites. Then I had to go to that My Sites collection and give READ permissions directly to the IUSR account
• I created a custom permission level called "Anonymous View" in the site collection, added View Application Pages, View Items, View Pages, and Open permissions. Then I added the anonymous view permission in the "Intranet Visitors" group to ensure they could get these extra permissions.

Nothing worked. If I tried getting results back directly from the People Search page, the 401 error would instantly appear. For some reason though I could perform a user profile search if I used the regular All Items search with the People scope. However when clicking on the results the 401 error would subsequently appear.

The conclusion: anonymously accessing user profile data does not seem to be supported out of the box. I suppose some custom code might fix this but my goal was to adhere to the vanilla SharePoint as much as possible.

This issue seems to be by design - the user profile data includes colleague information, social relevance algorithms, and organizational hierarchies. None of that information would pertain to the anonymous user account. Additionally, the actual user profile data may be considered sensitive.

Has anyone else come across this limitation, and if so how did you resolve it please?

Yesterday evening I saw a live demo of echoTechnology's echo for SharePoint 2007 product, which is a tool for handling SharePoint migration and management. The presentation was
given by CEO Garry Smith, Technical Director Sergio Otoya, and Technical Evangelist Stephen Cummins. The company is positioning echo as the tool that "allows administrators to
effectively manage and migrate onto the SharePoint 2007 platform". The demo was an hour long and was really impressive. Following that I spoke with Stephen to get a little more
information about how they feel the product can be used. I'll be publishing that within a few days.

Last night's demo gave a clear indication of echo's design philosophy, which is to make replication and change management as easy and granular as possible. This is important
because it's actually really hard to roll changes across different SharePoint versions, sites, and environments. I've mentioned before on this blog how complicated I find it to
properly manage the customizations that I make. Echo aims to solve that.

The two core concepts or "streams" that echo specializes in handling are migration and management. Migration might include migrating content from SharePoint 2003, Domino,
Exchange, or file shares. Management includes managing workflows, features, web parts, content types or site hierarchies. By creating discrete "tasks" for each of these, echo
gives you very granular control, allowing you to do one or more tasks handling simple or complicated scenarios.

The first part of the demo was a migration from SharePoint 2003 to SharePoint 2007. Out of the box SharePoint provides options such as in-place, gradual, and content migration.
The steps required to do these, and the pros and cons of each, are well documented elsewhere on the net so I won't go in to them here.

The way echo does it is to use a fresh install of SharePoint 2007 as a clean environment in which to push the 2003 migration. You first create a template site in MOSS 2007 (they
called it the "Blueprint site") which has all the webparts, lists, and views you would like to migrate your 2003 stuff to. Next, you select the 2003 sites you would like to
migrate. The lists of migration candidate sites get added to what looks like an Excel plugin - this allows you to save the list to Excel and give it to your business users so
they can make any changes they want pre-migration. This ensures that someone can clean up metadata, illegal characters, or make any other changes before you do the site
migration. You can run the job right away, or schedule it to run automatically at a later time. You can also save it to use for other batches. Once the batch ran, we saw how the
sites from 2003 were all copied over to the 2007 portal. A log gives complete details on each step of the migration.

After the run, the web parts and lists were migrated, but not any of their content. This led to the second demo, which was about content migration or "content loading" as it is
called. Having migrated the 2003 sites over, we were shown how the Content Loader Task allowed an administrator to map existing 2003 content, including its related metadata,
over to content types created on the 2007 portal. The mechanism to do this is very granular, so content settings, fields, views, permissions, version history and the like can
all be migrated across in whatever way you want.

There is even a choice to truncate the version histories, so that if you wanted you could migrate only the last couple of versions of content to the new 2007 portal. Once again
all of this can be saved to an Excel "control file", which allows customers to modify the migration settings if they want. This allows a deep level of control over the process,
and the Excel format is very user-friendly. In fact if I understood correctly formulas could even be run over the control files to do quick formatting.

The echo team say that one of the primary goals of the Content Loader Task is to help manage content types and support a central taxonomy. They feel that this is a key
requirement to really gain value from a MOSS portal with targeted searches. They have seen that many organizations don't bother doing this in a systematic way due to the adhoc
and unstructured way SharePoint 2003 allowed metadata columns to be added. Since an out-of-the-box migration will just try to copy existing metadata columns across without any
adjustments, and since the administrators doing the migration don't have any knowledge of what metadata should be placed on the content, the tendency is just to port all of
it over to the 2007 portal without applying any lessons learned or disciplined taxonomy. By using the Excel control file, the burden of applying appropriate metadata is removed
from the shoulders of the administrators handling the migration, and placed in the hands of content authors where it belongs. The Excel format seems like a logical way and
friendly to get content authors to plan and manage their metadata before a migration.

Having demonstrated the ease with which metadata can be changed in the Excel control file, it was reloaded into the echo interface, the batch was run, and all the content
migrated over to the 2007 sites and mapped to Content Types as planned.

The next demonstration was a quick example of loading content from file shares - in this case images kept in a series of folders. What was neat here was that there were four
folders with only two duplicated images in each - basically an example of versioning as it is usually done on a file system. The content loader provided a mechanism to
"collapse" these files together so that upon import, there were only two images but they each had the complete version history of their four versions taken from the folders.

At this point we were shown the concept of batching, which facilitates scheduling and change management for SharePoint. Any number of tasks could be added and configured,
providing complete flexibility for whatever scenario was required. The batches could be saved for future use, and scheduled to run at a particular time (such as after business hours). Batching is also an effective mechanism for migrating changes between environments.

Things I found noteworthy:

• The Excel plugin approach is a very good idea. Garry suggested this was driven directly from customer feedback.
• The granular level of tasks is useful because no-one is second-guessing how you want to do a migration or management - you are free to chain the tasks together in whichever
  order or process you like.
• The ability to migrate workflows is pretty key as one of the drawbacks of using SharePoint Designer is that it links a workflow to a particular list - and echo would remove that
  problem.

I'm sure that some organizations will value this tool for the help it can give migrating from SharePoint 2003 to 2007, especially with more complicated sites. It may help such
organizations "jump the gap" if they are hesitating due to the complexity of managing the transition. I haven't had to do many upgrades and those have been straightforward
"content migrations" so this is less important to me. Personally I'm most interested in the potential it has for migrating SharePoint customizations from development to testing
to production. This is a requirement in any organization that supports SharePoint and very hard to address without such a tool, and it's an ongoing need.

Echo for SharePoint 2007 is scheduled for release at the end of July. If you're interested you can find out more information and download a trial at echoTechnology's website
(http://www.echotechnology.com/).

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.

Server error: Access is Denied When Using SharePoint Designer

Every once in awhile I get an annoying error in SharePoint Designer when I'm trying to copy files or check something in or out. The error only says "Server error: Access is Denied".

To fix this, I add my windows account to the Policies for Web Application in All Zones and give the account Full Control.

To do this, log in to Central Administrator and select the Applications tab. Click "Policy For Web Applications". Click "Add Users". Choose the right web application and All Zones. Click Next. Choose your user account and make sure it resolves using the People Picker. Give the account "Full Control" and click "Finish". Hope that helps other people.