How to marry AD Claims User and Forms Based Users?

    I have been working at a client that uses FB authentication model to authenticate all users and to create new users. This works great as everything is with the SQL Server and you could associate users to different locations/departments, which are defined in SQL Server.

    However, there are scenarios where internal users need to log to SP site and they don’t necessarily have to use their FB authentication. There are other scenarios where the user may not exist in FB system, but in order to use the system they have to be created/registered in FB system. It would be really cool, if we could have the system in such a way that when an AD user logs to the SP Site, the system looks if the user exists in the FB database, if not, then checks a flag to see if I can auto add this new user all at once.

    How do you do such a thing where you can auto add an AD user with their groups as they are mapped to different locations the user exists and their other data(Title/Phone…etc)? This involves a couple of different components within SP/.NET world. First, you would need to examine the claims the user is bringing when coming via AD world. This is the most important step in the process as if you cannot find the UPN, then everything will break. You would need to have the email address of the AD user also to examine if the system already has a user in the database. We have an assumption that FB/AD user have the same email address as technically they are 2 different users, but we trying to impersonate AD user with FB user. The next thing you would need is to use the identity framework to examine what are the groups users belongs to so that you can map them to locations/departments in the system. Finally, you would need to active User Profile Service in order to extract other pieces of information like Title, Phone number etc. Once you have collected all this data, you can easily go ahead and create the FB user with this information.

    Thereafter, every time an AD user logs into the system, we query the db to find associated FB user and then make every single call as if the FB user is making. This is in brief how you would marry AD with FB 

Where / How to store email address in SharePoint 2010 when using Claims

When you are using Claims based authentication method, the user is never added SharePoint SiteCollection unless the user has logged to the site for the 1st time. However, when a user logs into the site for the first time, its identifier is only stored in a UserList List.

If you have a need to send emails to user as per of workflow or alert or anything, you need to find a place to store them. You could easily use the UserList to store this information. As a user is entering your site, you could write code to query the claims to extract email address the user primarily has and then extract that value and store it to the User List.

The location of this list http://myserver/_catalogs/user/Simple.aspx

Specail Consideration with this list:
- User List is very notorious as to when it updates the data.
- Initially when you create a new Site Collection, this list shows less than 15 columns and then a timer job runs and it adds around 40 more columns to the list.
- This list can only be seen by Site Collection Admin and above.
- In order to update to this list, you should ue run with elevated privs.

I will post some sample code soon.

Troubleshooting: The user does not exist error or is not unique

Today I was rebuilding my VM as a result of some issue with the old VM. An authenticated claims user when added to a SPGroup threw the following error:

The user does not exist or is not unique.0x81020054"} System.Exception {System.Runtime.InteropServices.COMException}

I banged my head for some time before found out the problem was in the setup of WebApp. In my case, the WebApp had 2 STS Providers so it was pointing to the wrong STS Provider, which was causing the user to be not added to the group. However, the user was an authenticated user who could be directly assigned access to a resource, but not added to the group. The user was added and viewable from this URL-> http://YOURSERVER/_catalogs/users/simple.aspx.

The above solution is only applicable if you are using Claims Based Authentication.

How to create a Digicert.cer

Instructions
1. Open the YOUR.cer certificate.


2. Click on the Certification Path tab and highlight DigiCert. Click on View Certificate.

3. In the Details tab, click on Copy to File.


4. The Certificate Export Wizard appears. Click Next.


5. Select the default ‘DER encoded binary X.509 (.CER)’ option. Click Next.


6. Specify a file name and a location to export the certificate to. Click Next.


7. Click Finish to complete the Export Wizard. The digicert.cer certificate is created in the specified directory.

8. Run the following commands using SharePoint 2010 Management Shell to add the trusted root authority.
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\temp\digicert.cer")
New-SPTrustedRootAuthority -Name "YOUR Token Signing Root Authority" -Certificate $root

Step 1: Claims Based Authentication (Software Required & Hardware)

In my setup, I had the following softwares in order to get the claims based authentication to work. You can install all the softwares on the same VM/HyperV it would not really matter. Typically most people have the list of the software below, but not have Microsoft Identity Framework. This is a free software from Microsoft that is required in order to set up STS.

- Microsoft Identity Framework 3.5 (Note: Not 4.0)
- SharePoint 2010
- Visual Studio 2010

Hardware
In my setup at the client, here is how my VM machine evolved over a period of 6 weeks:
- 1 VM - 2 GB Ram and 1 Processor (week 1) with SQL Express
- 1 VM - 4 GB Ram and 1 Processor (week 2) with SQL Express
- 2 VM - 4 GB Ram and 1 Processor and 2 GB Ram and 1 Processor (Full SQL)
- 2 VM - 4 GB Ram and 2 Processor and 2 GB Ram and 1 Processor (Full SQL)
- 2 VM - 8 GB Ram and 2 Processor and 4 GB Ram and 1 Processor (Full SQL)
- 2 VM - 8 GB Ram and 2 Processor and 8 GB Ram and 2 Processor (Full SQL)

SharePoint worked even in my week 1, but it was very slow. If you are going to be debugging the code, then it is better to start with 8GB Ram and 2 processor. If you have anything less then it takes approximately 60-70 seconds to cause the processor to break at your break point and another 20 seconds to just stop it. In the last week, we added more RAM and Processor to other VM because I added another developer. We used the same SQL Server box for the new developer too.

Tip: Creating WebApplications using Classic/Claims Mode

When you are creating a web application to use claims based authentication, ensure that the web application uses Claims based authentication. It is not possible to create a web application using classic mode and then extending it to use claims authentication mode.

Tip: Webapplication set up for Claims Based Authentication

It is better to set up a default WebApplication that connects to your AD and then extend the Web Application for Claims based authentication. One of the key advantages of this is that what if your Secured Token Services breaks down due to any reason and your manager needs some documents ASAP. A site collection admin can go into SharePoint site using their AD credentials to get you appropriate documents.

Therefore, you should have 1 Web Application and 1 extension.

Step 0: Claims Based Authentication

On the internet, you can find half a dozen walkthroughs on claims based authentication, but they all don't work accordingly. Some of them have some issue when you deploy the code.

In the next several blog posts, I will step through the process of registering a STS and Claims Provider and then setting up a Web App in SharePoint that is integrated with your STS.

Integration with Oracle

If your login information is stored in Oracle you can integrate it with Sharepoint.

Essentially you have to create a website (Secured token service) that a user will be redirected to when they go to Sharepoint. This web site wil authenticate the user and then redirect the user back to Sharepoint and then user can login to Sharepoint.

Over the next several weeks I will go through the process of creating this integration. I recently completed this integration for a large client.