SharePoint MySites and Pluggable Authentication Providers

Introduction To Problem with MySites and Pluggable Authentication Providers
A problem that people commonly encounter in a SharePoint site that they are facing externally on a perimeter is they want to use SharePoint MySites, however also want to implement a pluggable authentication provider that will allow them to give their external users easy access to the environment. The problem that arises is that when you implement pluggable providers, the MySite control that normally appears in a default sites:

< SharePoint:DelegateControl ControlId=”GlobalSiteLink1″ Scope=”Farm” runat=”server” id=”DelegateControl1″/ >

(why it wasn’t given a friendly name, I am not exactly sure)

will disappear when you install the pluggable provider and navigate to the default instance of your site.
This is a large problem for persons that want to implement MySites in SharePoint for a perimeter facing deployment that will allow customers to have their own little space. Although when you implement forms based on your portal the problem is not immediately resolved by the system, it is relatively straight-forward, simple fix that requires a little text editing and the bulk of the labor done through various SharePoint GUI’s.

On the good end, this was a larger problem without the concept of pluggable providers as provided because it typically required the users to be added into the local domain or for local users accounts to be added to the server in SharePoint 2003 which tended to be a user management nightmare and complicated the Active Directory forest.

Analysis of the Problem and The Proposed Solution
The reason that the problem arises is because by default you are going to have two config instances that exist that are going to look their own authentication routines, each acting as you specify it to. If you enable the sqlmembershipprovider and implement Forms Based Authentication on your core SharePoint site this is only going to effect one configuration element, what about if other application elements exist outside of your primary SharePoint web application?

As an example, let’s assume that there are two web application instances that exist in your environment, one with Windows, and another that exists under your FBA routine that resolves to the default SQL membership provider, so it would look like the below:

This is, in essence, is what you get by default when you solely implement a membership provider on your main SharePoint site, so in central administration you have made the changes for only one web application, and specified for external users that they can use the SQL membership provider (we are ignoring the concepts of Zones and AAM right now since we are only examining the overlying problem that is encountered). You can see that your mySites are generally pointing to a different web application in your at _layouts/PersonalSites.aspx or navigate to your SharePoint Service provider through WCAM and then select “My Site Settings”.

In the image referenced above this is demonstrated, two different web applications, one is your main SharePoint site and the other is your mySite, each using a different authentication routine to resolve itself, Web Application 1 is using Windows Based Authentication, whereas Web Application 2 is using Forms Based Authentication. In this scenario, Web Application 1 will have the MySite link available, whereas Web Application 2 will not have the MySite link available.

The evidence for why your are not seeing this link should be becoming more clear, and even has a formal definition (at least in multi-access security models)!. It is called in multi-level, MAC based environment, with various sensitivity label providers (for a brief introduction to MAC and sensitivity labels select here), “Cross-Provider Clashing”. When there are multiple applications that have inherent dependencies on the security routines that are provided for environmental, not local, cross-application stability, the inherent provider store must remain aggregate and assimilated by all the inherent assets. Meaning, if you are using forms based authentication with a custom authentication provider on one web application that provides security trimmed functionality to another web application, you MUST used forms based authentication with the same authentication provider for those related web applications, if you indeed do wish to to share those security trimmed objects.

How Can I Accomplish This?
Solving this problem is as simple as implementing Forms Based Authentication, even less so since the backend data store has already been setup. Seeing as that if you have run into this issue, you have already implemented a custom provider of some sort, you simply have to follow the same steps that you did in the other web application that is housing the other content that is cross context, and then make some changes to some administration sections in WCAM and WAT. So, both web applications that you have should use the same provider:

To do this:

1) Navigate and open the web.config file of both of your web applications (the less labor intensive way to find them and negate having to figure out the GUID’s is to open up the IIS MMC snap-in, select the virtual server, and select “Explore”) and make sure that the connection string and provider settings are identitical since you will be using the same provider for both your SharePoint Web Application and MySite Web Application (and as a best practice you should be encrypting your connections strings as detailed in my TechNet article here).

2) Open up SharePoint Central Administration (WCAM) and ensure that both of your web applications (core SharePoint Web Application and your mySite web application) are set to use forms authentication, this is done by navigating to Central Administration>Application Management>Authentication Providers which should place you at _admin/authenticationproviders.aspx. This can optionally be configured by manually editing the < authentication > < forms > elements in the web.config file, either way the end result will be same. Ensure while you are in this screen that the membership providers are identical that you have configured previously in the first step of the solution. If these is not the case, set them now to the custom provider and check the settings in the web.config for sanity purposes and to eliminate possible issues during the remaining configuration steps.

3) Following, you are going to have to change the site collection administrator settings, because there are both primary and secondary options here it is of no concern so a normal user account / service account can still retain some management options. Firstly, you have to change the site collection administrator of both sites (it is important to make this change for both of the site collections) to the admin user that you created in WAT (Web Site Administration Tool), for a better overview of the WAT tool select here. You should also add the ASP.NET admin account as an administrator in the Shared Service Provider. This can be done through the command line:

stsadm.exe -o editssp

        -title

        [-ssplogin ]

        [-ssppassword ]

        [-ssl ]

or you can optionally achieve it through the GUI by navigating to Central Administration>Application Management>Manage this Farm’s Shared Services>the SSP you need to change>Edit Properties>SSP Service Credentials.

In essence, this administrator account should become a secondary service account to those which you used when setting up the SharePoint implementation, and as the administrator will become your crutch account for troubleshooting administration issues as they arise.

4) RUN an IISRESET /noforce and your link will appear and be fully functional.

Is This A Bug?
This is in no way a bug, and I would imagine that Microsoft designed this flow to act as it does. To expect the option for an authentication provider to immediately blanket the rest of the provider settings would take away from the pluggable architecture that is introduced in this new version of SharePoint. Although it does require due diligence of the SharePoint administrator to really look at the changes that they are making to the authentication providers for all web applications, it ensures that your users are having the exact entry experience that you design them to have.

Share

Formal Access Control Methodologies and SharePoint

Formal Access Control Methodologies for Microsoft Office Server System

There are a variety of access control methodologies that one can implement within a SharePoint environment. The type of access control that an organization will implement will greatly depend on the business structure, industry, and regulatory compliance considerations that have to be instigated. It is usually helpful however to start the access control process by creating an access control matrix. This matrix will have subjects (users) on one end of the grid (typically on the row) and objects (things a user will access) on the other axis of the grid (typically the column). This will create T diagrams of access, which will help you define exactly how to assimilate the arbitrary access control methodology that your organization chooses.

Mandatory Access Control (MAC) Orange Book B Level

Mandatory Access Control is one of the most restricting types of access control mechanisms from a user standpoint that you can implement with SharePoint. The overlying principle of mandatory access control is that the user is segregated from the access control decision. For each object that gets stored within SharePoint, it is given a sensitivity label. Users are associated with the labels, and whenever access is attempted, the users associated access levels are posted to the sensitivity labels to control access to the object. The users have to be of a certain level in order to access objects of certain sensitivity labels. MAC promotes an overlying control that is not bound to an exact identity, but instead shares a set of rules (Ruled Based Access Controls Lists [RBACL]), which are the methods which define what users can access exactly what SharePoint objects. This is an extremely popular control mechanism for the federal sector since it allows a true segregation for classifications of data across a collaboration environment. Within the federal sector there is typically:

  • Public
  • Secret
  • Top-Secret

An object within SharePoint can be assigned the level of public (the sensitivity label). Users are associated with a sensitivity label, so that certain users are given one of the three levels, whether it is public, secret, or top-secret. Therefore groups of people can access the document as long as the rules are satisfied.

Although MAC is a difficult system to implement, it is considered one of the most secure types of access control systems and for companies with regulatory compliance concerns a very practical implementation.

Discretionary Access Control (DAC) Orange Book C Level

Discretionary Access Control is one of the most common access control implementations that exists within SharePoint. DAC allows content managers to define the management of SharePoint objects as well as actions (such as information policy management and versioning configurations) related to SharePoint objects.

Since there is, within a typical SharePoint implementation, usually a site collection administrator along with related site owners, going down to any arbitrary Secured Object level security. In this, there is typically self service management of access control over various SharePoint objects, so the user is given discretion, which can be given from any number of users. Since with most secured objects in SharePoint, there is always one person with full control over that object, that person will be given the options of specifying the other users that can access the object and how the other users can interact with those objects. Out of the box, SharePoint is an object-to-identity based system, and therefore when setting up a plain vanilla SharePoint site where you will be directly binding identities to objects regardless of membership and role providers, you will be implementing Discretionary Access Control.

Lattice Based Access Control (LBAC) No Orange Book Level Association

LBAC is a concept that involves ordered sets and related subsets.  Within LBAC, there are always two certainties, each which span a finite space:

  • There is always one Least Upper Boundary (LUB)
  • There is always one Greatest Lower Boundary (GLB)

Applying the above two as constraints as finite boundaries, the parameters of the LBAC are the subject and the object being secured. For each object, a user will have a LUB and the GLB in regards to access rights to the object.  Using LBAC, it is possible to maintain the lattice between security objects by allowing a combination to exist through the merging of rules and related classification assignment. In short, for each object that can be accessed, there can be an upper and lower limit for what a user can do.

Rule Based Access Control (RuleBAC) No Orange Book Level Association

RuleBAC is a child of the concept of Mandatory Access Control, since it inherits out of the concept out of an Access Control List. The access to objects however is controlled by rules that can be shared globally across an enterprise. This is heavily tied to the concept of grouping and role basing in SharePoint, where one might define a set of rules that are associated with a group of people that share the same type of access needs and object interactions.

Role Based Access Control (RBAC) No Orange Book Level Association

Role based access controls are becoming extremely popular because of their ease in adding users to federated corporate systems, and there bulk management options. They are incredibly pertinent in SharePoint when exploiting the options available with the ASP.NET role provider models. As opposed to rigid access models that have been presented thus far, RBAC allows a user to be added to a role group that will define the objects that they have permission to as well as legal actions that the user can have with that object. RBAC is used on the Windows Server itself, where there are certain permission groups that a user can be added to, such as Local Administrators or Power users (actions performed through the Computer Management MMC snap-in). The concept of RBAC is the backbone of implementing a Limited User Access (LUA) environment where one can determine the exact amount of access that a user needs in order to finish their job with no unused or extravagant permissions.

Share