This is my first post in this year, so I have decided to change a topic a little bit from Lightswitch to Cloud technologies and Sharepoint 2013. Recently I have been asked at work to prove the concept of creating our Sharepoint Intranet in the cloud. I was familiar with Azure before ( was using SQL servers there for one of my home projects), but I haven’t really touched the space of ACS and all other features provided by Azure. Was quite surprised how many things you can do in the cloud now. God, you even don’t need a heavy PC anymore. How about to set up you fully functional Sharepoint environment in less than a minute? Sounds good right?
Let’s go back to my original topic of creating SharePoint intranet in the cloud. First I am going to create a working SP environment using Cloud Share. You can ask why I am not using trial version of SP2013 which is available right now in the Azure gallery? The answer is – time and money. If you are using free trial subscription from Azure, you will know that this subscription will give you only one months and $210 to spend. At the same time to have a working SP2013 environment in Azure you will need to setup AD server, SQL server and SP server ; what again takes your time and money. I am not going to describe steps how to setup Azure ACS and Sharepoint to be able to login to SP using Facebook, Google, Yahoo and LiveID. There are bunch of good tutorials online, I will just recommend you the blog post from Danny Jessee : click here with complete steps to use Facebook as identity provider to SharePoint.
So if you have everything working fine, you will be asking yourself a question: How can I give an access to users who doesn’t have any facebook, gmail accounts? Can we just have an SQL table with users who can access our intranet? And the answer is – Yes!
After completing all steps from Danny’s blog post you should have something similar to this:
Choosing the second option you will be redirected to Azure ACS page to select which provider you would like to use for authentication:
This picture above means that I have setted up 3 different identity providers in ACS to access my SharePoint site.
There are actually two different ways (which I know) how you can add custom login to sharepoint site. First method is configure Form Based authentication using SQL provider: click here and the second one, which I am going to explain here, using custom Identity provider in ACS. Which method to chose it is up for you, but it is better to have a one point of authentication and it is good to keep everything just in the one place when you will decide for example to connect to you SP from windows store app using credentials from that custom user table. Sounds a bit tricky, but you will be surptised how easy it will become with ACS.
Here is a really good blog post about it, but just applied for MVC aplication. We just need to adopt it to SP 2013. click here
Existing Web Site on the picture is our SharePoint 2013
And here what we need to achieve.
To be able to do that we need to create our custom STS or as a good alternative use an open source product called Thinktecture Identity Server.
You can have a look at the product page here
So our first step will be
1. Creating new VM in Azure and running IIS to host our Thinktecture Identity Server
After you create a new VM Server 2012 in Azure please follow instruction on this video on how to set up Thinktecture Identity Server : here
2. In the next steps we need to follow the blog post which I have provided above:
After you get it running locally and you have completed the initial configuration, don’t forget to open port 443 in Azure VM endpoints to access it from public. The link should be similar to this https://youservername.cloudapp.net/idsrv in a browser. You’ll be prompted by the browser with a security warning about the certificate, if you used a self-signed certificate. Choose the option to continue, or add an exception and continue as appropriate in your browser. You’ll then see the IdentityServer home page.
Right-click the View WS-Federation Metadata link, and save the file (FederationMetadata.xml) to your desktop. Next, return to the ACS Portal for your service namespace. Click the Identity providers link at the left. In the screen that appears, click Add. On the Add Identity Provider screen, select WS-Federation identity providerand click Next.
On the Add WS-Federation Identity Provider screen, enter IdentityServer in the Display name text box, as shown in picture below.
Under the WS-Federation metadata section, select the File option and click the Browse button to select the FederationMetadata.xml document you downloaded previously from IdentityServer. In the Login link text box, enter the text you want to appear to users in their home-realm login page. Finally, ensure that Sample Website is selected underRelying party applications.
Click Save, then click the Rule groups link. On the screen that appears, click the Default Rule Group for <your Website>. Next, on the Edit Rule Group screen, click the Generate link above the Rules table. On the Generate Rules screen that follows, check the boxes for IdentityServer and Windows Live ID and click Generate. The Rule Group should now be configured for both Windows Live ID and IdentityServer providers, as shown in picture below:
Now. What we need differently from that blog post is we need to configure our rules to be able to authenticate to Sharepoint
In the Rules section, find Rule emailaddress for Identity Server.
Go inside and change Output claim type to nameidentifier as shown below.
The last step is to
Configure ACS as a Relying Party of IdentityServer
Return to the IdentityServer home page. Click the sign in link at the top, enter your Administrator username and password that you created previously, and click theadministration link, also in the top menu. Click the Relying Parties link, then click the Add New link.
In the Relying Party dialog box that’s displayed next, for Relying Party Name, enter ACS (or whatever value you prefer). For the Realm URI, enter the URI using the form “http://<namespace>.accesscontrol.windows.net/”, substituting your ACS service namespace. For ReplyTo URL, enter the WS-Federation endpoint in ACS for your service namespace, using the form “https://<namespace>.accesscontrol.windows.net/v2/wsfederation” (note the use of https).
Click Create. You should now see ACS in the list of Relying Parties for IdentityServer. With this, you’ve completed the necessary configuration. Now it’s time to try out IdentityServer!
This is it.