Adventures in SharePoint Forms Based Authentication – Part 4

This fourth and last part of my FBA mini-series (here are links to Part 1, Part 2, and Part 3), is about permissions. You’re using Forms Based Authentication which stores the information about all those “outsider” users in SQL Server rather than cluttering your Active Directory. But if these folks are not known to your environment as Windows users, how can you assign them permissions in SharePoint?

The ASP.NET custom role provider makes this easy. What happens is that any roles you define are visible in SharePoint as users. Since a role shows up as a user, you can add a role to a permission group as if it were a person. How does that help us? When we register our users with the ASP.NET Membership provider, we can also assign each user to the role he/she will play.

For example, I recently worked on a project in which some of the users would be credentialed health care professionals and some would not. To represent those users, we could define two roles: “Registered – HCP” for the health care people (it gets as tiresome to type “health care professional” as it does to read it, so I’ll be abbreviating it HCP from now on) and “Registered – General” for everyone else. When we create an account for an HCP, we assign that user to the “Registered – HCP” role; correspondingly, non-health care pros would be assigned to the “Registered – General” role. Those roles, in turn, we will add to SharePoint permission groups so that, say, HCP users can see certain content that General users cannot.

Here’s a short cookbook for setting this up.

  1. Configure your SharePoint web application to use the Microsoft-provided custom role provider that stores role information in SQL Server. Part 1 of this series outlines how to create the SQL database that will hold user information. Here’s what you put in web.config to start using the custom role provider:
    <roleManager enabled="true" defaultProvider="PJSAspNetSqlRoleProvider">
    <providers>
    <add name="PJSAspNetSqlRoleProvider"
        type="System.Web.Security.SqlRoleProvider, System.Web, &#xA; Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
        connectionStringName="PJSSqlConnString"
        applicationName="/"/>
    </providers>
    </roleManager>
    

    Most of this is boilerplate. The parts that aren’t are the places where you name things. In the <add name=””> declaration, supply any name you like for this provider. Make sure to use this same name above in the defaultProvider=”” declaration. The other name you have to supply is a value for “connectionStringName”; this must correspond to the element in the <connectionStrings> section of web.config that describes how to connect to your database server.

  2. From Visual Studio, open the project for the web application you’re working on and launch the ASP.NET Configuration tool to ensure the custom role provider is in use. You launch the tool from the Website menu; it’s Website->ASP.NET Configuration. The configuration tool is a web application; launching it will either start Internet Explorer for you, or if you already have IE running, it will open a new tab. Select the Provider Configuration link, and on the subsequent page, select the link “Select a different provider for each feature (advanced).” You’ll see a page that looks like the illustration below. Under Role Provider, you should see the name you used in web.config; select your provider. If you want, click the Test link to make sure your connection string is correct and that you can successfully connect to the database.
    Provider configuration in the ASP.NET Configuration tool

    Provider configuration in the ASP.NET Configuration tool

  3. Now go to the Security tab of the configuration tool so you can define roles that correspond to the categories your users will fall into. Using my example, we would define two roles: “Registered – HCP” and “Registered – General.” You do this by selecting the “Create or Manage roles” link in the center of the page. The next page you’ll see is illustrated below. Role creation is simple: type a role name where it says “New role name:” and click the Add Role button. This is all you’ll need to do in the ASP.NET configuration tool.
    Role creation with the ASP.NET Configuration tool

    Role creation with the ASP.NET Configuration tool

  4. Navigate to your SharePoint application and login as an administrative user. Navigate to the site or sub-site containing special content that only the HCP folks should see.
  5. Create a permission group named “SpecialContent” and add the “Registered – HCP” role to the group. If you’re unclear on how to create a permission group, here are the basic steps:
    • From the Site Actions menu, pick Site Settings, and then pick Advanced permissions
    • From the New menu, pick New group
    • Fill in a name for the group. In this example, we’re using the name “SpecialContent.” You can accept the defaults for most of the subsequent sections of this page. At the bottom, you will have to choose which level of permisions members of this group can have, e.g., Read, Contribute, etc. Then click the Create button.
  6. You will now be on a page labeled “People and Groups: SpecialContent.” You’ll see that the administrative user you’re logged in as was automatically made a member of the group. Now you want to add the “Registered – HCP” role as a group member. Here’s what to do:
    • From the New menu, pick Add Users. In the Users/Groups textarea, type in “Registered – HCP” exactly and click the “Check names” icon (looks like a little person with a green check mark superimposed). After a few seconds, the text you typed in should become underlined — your “user” was looked up through the role provider and found to be valid.
    • In the Give Permissions sections, select “Add users to a SharePoint group” and pick “SpecialContent” from the dropdown.
    • In the send E-Mail section, be sure to uncheck “Send welcome e-mail to the new users” since our user in this case is a role, not a real person.
    • Click OK
  7. Now navigate to the site or sub-site containing the generally available content that all users can see. Following the same steps above, create a permission group “GeneralContent”, grant it Read access, and add both roles “Registered – General” and “Registered – HCP” (as if you were adding users) to the group.

To test this out, you can use the ASP.NET Configuration tool to create two users and assign them different roles — one user gets the “Registered – HCP” role and the other gets the “Registered – General” role. Then login as each user and verify that you can see only the content you expect to see.

Advertisements
Tagged with: ,
Posted in SharePoint
One comment on “Adventures in SharePoint Forms Based Authentication – Part 4
  1. […] only learn a few things, but also enjoy the experience.  Pete’s first set of posts is about Adventures in SharePoint Forms Based Authentication.  If you read through these four posts, you should have a good understanding of the basics of […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: