SharePoint SPIdentity Team Blog

Another great resource for SPIdentity readers

SPIdentity — Fri, 19 Mar 2010 12:10:00 GMT

Steve Peschka is a long time Authentication expert in SharePoint who is really digging into the new Identity subsystem in SharePoint 2010. His blog is now full with lots of super useful information for developers and IT Pros. his blog is at https://blogs.technet.com/speschka/

We particularly pscyhed about the latest series of posts on how to write a Claims Provider for SharePoint 2010.

Thanks Steve.

(belated) Intro to Identity in SharePoint 2010

SPIdentity — Tue, 26 Jan 2010 13:13:00 GMT

We just realized that we kicked off the blog without so much as an introductory paragraph, let alone an overview. We were really fixated on getting the instructions out to configure and test the non-Windows Identity pipeline to unblock testing... Now that the two basic configuration posts are up, let's do the Intro...

At the beginning of the SharePoint 2010 cycle, we took a thorough look at the design of Identity in SharePoint with everything we had learned about in SPS 2003, MOSS 2007, WSS v2 and WSS v3. Boy, did we learn a lot in those products. We finally articulated the problem statement eventually down a few bullets:

Support User Identity delegation

to other servers/services in the same farm (BCS, Excel Services, etc.)
to other servers/services in another SharePoint farm (Search, Secure Store, etc.)
to other servers/services outside of SharePoint (WCF, Web Services, SQL, etc.)

Allow addl. security principals (ex. Application Roles)
Support Multiple Identity Providers on one URL (Windows AND Federated Identity Provider)
Support for Office Client access w/o Windows Integrated Authentication
Integrate with Identity Provider products via Standards

In order to address these identity issues/problems/opportunities, we selected the Claims Based Identity model introduced to us by Kim Cameron. We worked super closely with the Windows Identity Foundation (WIF) team for this work. Huge thanks to them!

In a nutshell, here is Identity flow in SharePoint2010:

Incoming (Sign-in) has two sign-in modes - Windows-Classic and Claims. Claims mode, in turn, supports Windows, ASP.Net Forms Based Auth and SAML Token often referred to as Windows-Claims, FBA-Claims and SAML-Claims. We offer an extensibility point to Augment claims into the sign-in token.
Outgoing (SharePoint Services) uses SAML tokens exclusively in our server-to-server communication between the WFE and App Servers over WCF in our Shared Services framework.
Outgoing (Business Connectivity Services) features such as Virtual Lists support PassThrough identity to "external webservice" using SAML tokens as well.

There is a lot to cover about the subject and we will devote a bunch of time discussing what we have done and how to address customer issues as we see/hear/run into them. The videos below give a good feel for the approach we took to address the issues above using Claims and WIF.

Video 1:

Here, Venky talks about what we did and why we did what we did! Mention @venkyv or @SPIdentity directly with questions.
https://channel9.msdn.com/shows/Identity/Sharepoint-2010-and-Claims-Based-Identity/

Video 2:

Vittorio, who interviewed Venky for the above video also gave a talk on Claims Based Identity in Belgium. He talks about what claims are and gives analogies and anecdotes to drive the concept home. Wonderful talk.
https://www.microsoft.com/belux/techdays/2009/session.aspx?sid=idcloudserv&tid=arc_preconf&engine=MSDN

Video 3:

Venky's presentation at the Professional Developer's Conference 2009 in LA, where he is a little bit more specific than in Video 1!
https://microsoftpdc.com/Sessions/PR11

We are on Twitter as well, so please add @SPIdentity to your tweets get our attention.

We would love your comments and questions in either this blog or on Twitter. Thanks!

----

The SharePoint Identity team is Chris, Huy, David, Bryant, Titus, Vlad, Nick, Suntosh, Javier, Sarat and Venky

Claims-based authentication "Cheat Sheet" Part 2

SPIdentity — Fri, 22 Jan 2010 16:50:00 GMT

On part 1 of these blog post series we went over the process of configuring forms based authentication. In this second part we will talk about configuring a SAML based sign-in (also known as claims sign-in).

In the upcoming blog posts, we will discuss more scenarios like mixed mode authentication and multi-auth, so stay tuned for more on these.

Make sure you read the part 1 of this blog in order to get the information about pre-requisites for this guide.

Sign-in using a SAML claims token scenario overview

In windows authentication, the user present a windows token to SharePoint in order to request access. This token is given by the AD domain controller during authentication. In the case of SAML sign-in, the user will present a SAML token, in this case, the user gets the token from an STS (Security Token Service).

SAML sign-in is generally used in enterprise federation scenarios, for example: provide access to a partner. This authentication mechanism is also used in other scenarios like extranet and even internally, for example: Provide access to users from the same company but in a domain that is not part of the forest where SharePoint lives.

You can find more information about claims scenarios in the "Geneva" team blog. Another good resource that talks about claims sign-in scenarios can be found here.

Pre-requisites to run this scenario

For this example, we will use Geneva Server as the trusted STS (authentication provider) for our SharePoint web application. Click here to learn more about how to setup AD FSv2 (aka Geneva Server).

The link noted above describes how to configure the STS, below I describe how these steps relate to SharePoint SAML sign-in:

On the step "Federation Service Name Page" the STS certificate is defined. You will need to export this cert (without the private keys) and copy to the machine where SharePoint 2010 is installed. During trust establishment, you will be required to use this cert.

Once AD FSv2 STS has been configured, you will need to create a new relying party application, SharePoint in this case, so the STS can issue user tokens for SharePoint. You can find information about this on the Geneva Team blog and also in TechNet, below are the basic steps to create the relying party for SharePoint:

Open up the Microsoft Geneva Server Management shortcut on the desktop

In the left pane:

Expand Policy
Select Relying Parties
In the right pane
Add Relying Party...

A wizard will appear

Select Start
Choose "Enter relying party configuration manually" Click Next
Give a Name. Click Next
Leave "Geneva" Server Profile selected. Click Next
You will not use a encryption cert. Click Next

Select Enable support for Web-browser-based identity federation
Give the Web App url and append /_trust/

Example: https://servername/_trust/

Click Next

Add the following entry as a identifier (realm)

urn:COMPUTERNAME:Geneva
Click Add

Click next

Click Next on the summary page

Click Close

A new dialog will appear
Rules Editor: we will map claims from LDAP to send to SharePoint
In the Left Pane

New Rule
Predefined Rules

Create Claims from LDAP Attribute Store

Right Pane
Drop down Attribute Store:

Select Enterprise Active Directory User Account Store

Under LDAP Attribute select sAMAccountName

Under Out Going Claim Type select E-Mail Address

Left Pane

Click the Save Icon

Close the dialog

Steps to configure claims-based authentication in SharePoint 2010 beta

At a high level, the steps needed to configure this authentication mode are:

Define a trust with an STS (Geneva server in this example)

Select a claim from the "incoming" token that will be used as unique identifier for the user

(optional) Define which claims from the incoming token we will be accepted and how they will show up in SharePoint 2010 (claims mappings)

Note: All claims from incoming token that don't have a mapping will be discarded.

Select the certificate that will be used to validate that the token was issued by the trusted STS (our assumption here is that the cert from Geneva Server was provided to us and: it is already deployed in all farm machines or import via SharePoint claims functions so it can be distributed to all machines in the farm).

Create a new SharePoint web application and enable this authentication provider

In order to do what's described above, you can use SharePoint Central Administration or PowerShell cmdlets, below I'll describe both options and same as in previous blog post, we will use a sample script that facilitates the use of the cmdlets. This script is also very good reference to learn how to use these PowerShell cmdlets.

PowerShell sample script instructions:

We created a PowerShell script that you can use to deploy these scenarios in a very easy way, below we will discuss how to use this script in the different scenarios. Feel free to play with the script to accommodate your specific requirements, it is also a great tool to learn how to use our new SharePoint 2010 beta PowerShell cmdlets.

The sample script can be found here

Note: In order to use the script, copy the files from the above link to where the SharePoint 2010 beta is installed, you will need to create a directory (in any location) to place the files.

Pre-requisite step - Prepare an Identity Provider STS (IP-STS)

You can use your own STS or use Geneva Server. In the steps noted below, we will assume Geneva Server as the external IP-STS. To learn about Geneva Server and how to setup, go to: Geneva Server RC anouncement

Step 1 - Establish a trust with the Identity Provider STS (IP-STS)

Via PowerShell

$waurl = "https://" + $env:ComputerName

$title = "SAML-Claims"

1.1 Get certificate of the STS we want to trust

Export the certificate of the Geneva Server and copy it to a location where the SharePoint server has access. To make more readable and clean the user of the PowerShell cmdlets, I will create an object with this cert:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\geneva.cer")

1.2 Define the claim that will be used as unique identifier of the user (claims mappings)
For this example we will use email as the user identifier. In real world scenarios, the administrator of the trusted STS will need to provide this information, the reason is that only the owner of the STS knows which value in the token will be always unique per user. It is also important to note that the URI we are using in claim type for email is not mandatory, the administrator of the trusted STS could create its own URI to represent email. In this example we use the one defined by OASIS.

$map = New-SPClaimTypeMapping -IncomingClaimType "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

1.3 (Optional) Define additional claim mappings

You can define additional claims that we want to keep from the incoming token, for example if the trusted STS also include roles of the user, we may want to keep that claim so we can ACL resources in SharePoint using these claims. In this example we will not create additional claim mappings.

One last comment about claim mappings; All claims are per trusted STS (authentication provider), this means that if SharePoint establish a second trust with a different STS, the claims from that STS will not clash with the ones from the other trusted STS. The reason for this is that the claim also contains the original issuer value which makes it different for each trusted STS.

1.4 Create a new authentication provider

In this step, we will create the SharePoint authentication provider that the web application will use.

$realm = "urn:" + $env:ComputerName + ":Geneva"

$ap = New-SPTrustedIdentityTokenIssuer -Name "Geneva" -Description "Geneva" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://nicstu-test-2/FederationPassive/" -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

The realm is the parameter used by the trusted STS to identify a particular SharePoint farm, refer to Geneva Server documentation for more details.

Step 2 - Create a new SharePoint web application and configure it to use SAML sing-in

2.1 Create a new SharePoint web application and configure it to use the newly created authentication provider (Geneva STS)

In this step we will create and configure the web application, note that we are enabling SSL, the reason is that in SAML Sing-In and same as in forms based authentication, we use cookies as the single sign on ticket for the user. This allows us to give access to the SharePoint resources for the duration of the token without the need of re-authenticate the user. Without SSL these cookies can be easily high jacked by a malicious user and be used to impersonate the original user.

$wa = New-SPWebApplication -Name "SAML Sign-In" -SecureSocketsLayer -ApplicationPool "SAML Sign-In" -ApplicationPoolAccount "domain\admin" -Url "WebAppUrl" -Port 443 -AuthenticationProvider $ap

Note: You must replace the place holders "WebAppUrl" and "domain\admin" with the proper values

2.2 Create a SharePoint site and assign an owner

This step can be done via PowerShell or via central administration. Refer to SharePoint 2010 documentation in TechNet for details on how to create a site.

OPTION 2: Via sample script for PowerShell (Does not apply for Central Admin path)

Launch a the SharePoint 2010 beta Management Shell

Switch to the location where you copied the script files

Edit the script file and replace the place holders with the values based on your environment, for example: administrator accounts, url's, etc.

Open the SharePoint 2010 management shell (Start -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell)

NOTE: Make sure you run the shell console as administrator

Execute the script with the appropriate parameters depending on the authentication type you want to configure:

Forms: claimswa.ps1 SAML

NOTE: This will create a web application with SSL enabled in port #443, to specify a different port, just add the port number after the "SAML" parameter

NOTE: If you run the script for a second time in order to create a new web application, you must specify the port number. This parameter is only optional the first time the script is used.

You should be able to browse to the newly created web application and get redirected to the Geneva Sign-In page in order to authenticate.

Don't forget to send your feedback, and stay tuned for the upcoming posts of this guide with the steps to configure other authentication scenarios.

More information can be found on TechNet: Authentication planning

Additional TechNet resources can be here: https://technet.microsoft.com/en-us/library/ee806881(office.14).aspx

Claims-based authentication "Cheat Sheet" Part 1

SPIdentity — Mon, 04 Jan 2010 12:59:00 GMT

This is the first part of a series of blog articles that talks about configuring claims-based authentication in SharePoint 2010 beta, on this first part, we will cover the following authentication scenarios:

Asp .NET membership / role provider (aka forms based authentication)

Anonymous access

We will keep posting blogs to cover additional claims-based authentication scenarios, meanwhile try these scenarios and send us your feedback.

For those that want to learn more about what is claims-based authentication and the benefits of this new feature, I recommend the following links:

https://technet.microsoft.com/en-us/library/ee428302(office.14).aspx

Scenario Pre-requisites

First, and before we drill down into claims-based authentication details, install a SharePoint 2010 beta and run the configuration wizard. You can find more information about installing and configuring SharePoint 2010 in TechNet and the SharePoint team blog:

TechNet: https://technet.microsoft.com/en-us/library/cc262957(office.14).aspx

SharePoint team blog: https://blogs.msdn.com/sharepoint/

Steps to configure claims-based authentication in SharePoint 2010 beta

You can use SharePoint Central Administration or PowerShell cmdlets to configure claims-based authentication. For the later, we included a sample script that will make this path much easier. This is also a great way to learn how to use PowerShell in SharePoint 2010.

PowerShell sample script instructions:

The sample script can be found attached to this blog post.

Note: In order to use the script, copy the files from the above link to where the SharePoint 2010 beta is installed, you will need to create a directory (in any location) to place the files.

Pre-requisite step - Defining which membership provider to use and how to setup

In order to configure the web application with forms based authentication, we first need to have a ASP.net membership / role provider. If you don't have your own membership provider, you can use any of these two options:

Use the SQL Membership / role provider (which is installed by IIS, click here for more info)

Use the LDAP Membership provider (which is part of the SharePoint 2010 Beta Server product, click here for more info)

Depending on which membership provider was chosen, you will need to modify / update the values used in the sample script, this will be covered in step 1 below.

Step 1 - Modify the script to use values that adapt to your environment (Only if using PowerShell route)

Note: This step only applies if you want to use the script mentioned above

For configuring the settings required in the Asp .NET membership provider scenario, the script pulls the membership and role provider settings from the file WEBConfigs.xml

The default setting we provide in this file, configure the LDAPprovider which connects to a domain controller in order to authenticate the user and get the user security groups it belong. You can change them to use your own membership provider or the SQL membership / role providers.

Open the file WEBConfigs.xml using the editor of your preference (notepad will work) and change the value of the "server" attribute to point to your domain controller. You will also need to modify the "userContainer" element with the information of your domain controller:

Note that these changes needs to be done for both nodes: membership node and roleManager node.

To learn more about LDAPprovider go to here: https://technet.microsoft.com/en-us/library/cc262069.aspx#section3

Remember that you can also use your own membership / role provider or the SQL membership / role provider. More information about this can be found in TechNet and MSDN.

There are other parameters that need customization in the script, but we will be cover them in the upcoming blog articles that talks about other claims-based authentication scenarios, for the scenarios described in this article, you can leave them "as is".

Step 2 - Create a claims enabled web application

Via central admin (Does not apply for PowerShell path)

Got to central admin -> Manage web applications

Click on "New" web application

Click on "Claims based authentication"

Enter the values for the web application as directed in the page

(Optional) If you only want to have forms based authentication, then uncheck the "Enable Windows Authentication option"

Note1: If you leave Windows authentication, then during sign-in, the user will be redirected to the "authentication selection" page. In this page the user can chose between windows and forms based authentication

Note 2: Windows authentication is disabled, then SharePoint search service won't crawl content on that web application, one alternative to this is to create a second extended web application and enable Windows authentication.

Click on Asp .NET membership / role provider (Forms auth) to enable this authentication option

Enter the name of the membership provider and the role provider

These values will be used later on and should match the name set in the web.config file

Once the web application has been created, you will need to manually add the membership and role provider configuration sections in the following web.config files:

Your newly created web application

To get to the place where the web.config file resides, in IIS management console, click on the newly created "web application" node, then "browse"

Central administration web application

To get to the place where the web.config file resides, in IIS management console, click on the "central admin web application" node, then "browse"

Just in the case of this web.config, you need to add a entry before the node

Security Token Service web application

To get to the place where the web.config file resides, in IIS management console, click on the "SharePoint Web Services" node, then on the "SecurityTokenServiceApplication" node, then "browse"

You need to find the node and add the entry with the settings of you membership provider, same for the role provider (in )

Via sample script for PowerShell (Does not apply for Central Admin path)

Launch a the SharePoint 2010 beta Management Shell
Switch to the location where you copied the script files

Open the SharePoint 2010 management shell (Start -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell)

NOTE: Make sure you run the shell console as administrator

Execute the script with the appropriate parameters depending on the authentication type you want to configure:

Forms: claimswa.ps1 FBA

NOTE: This will create the FBA web application in port #201, to specify a different port, just add the port number after the "FBA" parameter

Anonymous: claimswa.ps1 ANON

NOTE: This will create the anonymous web application in port #201, to specify a different port, just add the port number after the "ANON" parameter

NOTE: If you run the script for a second time in order to create a new web application, you must specify the port number. This parameter is only optional the first time the script is used.

Step 3 - Assign the site collection administrators

NOTE: This is only needed if during web application creation you didn't created a site collection, you can check via central administration console if the web application you created has or not a site collection already configured.

Via Central Administration Console:

Go to Central Administration -> Application Management

Click on Create Site Collection (if not done during the web application creation)

Enter the users that will be the site collection administrators, if site collection was created during web application configuration, then you will need to click on Change Site Collection Administrators in order to access this configuration section

You should be able to browse to the newly created web application and use the configured membership provider in order to authenticate. Notice that all sites in this web application, the people picker can resolve the users from the configured membership provider.

Don't forget to send your feedback, and stay tuned for the upcoming posts of this guide with the steps to configure other authentication scenarios.

More information can be found on TechNet:

Article on configuring Asp .NET membership / role provider can be found here: https://technet.microsoft.com/en-us/library/ee806882(office.14).aspx

Additional TechNet resources can be here: https://technet.microsoft.com/en-us/library/ee806881(office.14).aspx

ClaimsScript_v1.5c.zip