Server-to-server authentication and user profiles in SharePoint Server 2013

This Explains how to plan user profiles for server-to-server authentication in SharePoint Server 2013.

* Server-to-server authentication allows for servers that are capable of server-to-server authentication to access and request resources from one another on behalf of users. Therefore, the server that runs SharePoint Server 2013 and that services the incoming resource request must be able to complete two tasks:
  • Resolve the request to a specific SharePoint user
  • Determine the set of role claims that are associated with the user, a process known as rehydrating the user’s identity
* To rehydrate a user’s identity, a server that can perform server-to-server authentication requests access to SharePoint resources. SharePoint Server 2013 takes the claims from the incoming security token and resolves it to a specific SharePoint user.

* By default, SharePoint Server 2013 uses the built-in User Profile service application to resolve the identity.
The key user attributes for locating the corresponding user profile are as follows:
  • The Windows Security Identifier (SID)
  • The Active Directory Domain Services (AD DS) user principal name (UPN)
  • The Simple Mail Transfer Protocol (SMTP) address
  • The Session Initiation Protocol (SIP) address
Therefore, at least one of these user attributes must be current in user profiles. We recommend a periodic synchronization from identity stores to the User Profile service application. For more information, see Plan profile synchronization for SharePoint Server 2013.
Furthermore, SharePoint Server 2013 expects only one matching entry in the User Profile service application for a given lookup query that is based on these four attributes. Otherwise, it returns an error condition that multiple user profiles were found. Therefore, you should delete obsolete user profiles in the User Profile service application periodically to avoid multiple user profiles that share these four attributes.
If a user profile and the relevant group memberships for the user are not synchronized, SharePoint Server 2013 may incorrectly deny access to a given resource. Therefore, make sure that group memberships are synchronized with the User Profile service application. For Windows claims, the User Profile service application imports the four key user attributes previously described and group memberships.
For forms-based and Security Assertion Markup Language (SAML)-based claims authentication, you must do one of the following:
  • Create a synchronization connection to a data source that the User Profile service application supports and associate the connection with a specific forms-based or SAML authentication provider. Additionally, you have to map attributes from the user store to the four user attributes previously described, or as many of them as you can obtain from the data source.
  • Create and deploy a custom component to perform the synchronization manually. This is the most likely option for users who do not use Windows. Note that the forms-based or SAML authentication provider is invoked when the user’s identity is rehydrated to get their role claims.

If the requesting server is running Exchange Server 2013 or Lync Server 2013, which use standard Windows authentication methods, the incoming security token sent by the requesting server contains the UPN of the user and may contain other attributes such as SMTP, SIP, and the SID of the user’s identity. SharePoint Server 2013, the receiving server, uses this information to locate the user profile.
For a requesting server that is running SharePoint Server 2013, the receiving server rehydrates the user through the following claims-based authentication methods:
  • For Windows claims authentication, SharePoint Server 2013 uses AD DS attributes to find the user profile for the user (for example, the UPN or SID values) and their role claims (group membership).
  • For forms-based authentication, SharePoint Server 2013 uses the Account attribute to locate the user’s profile and then invokes the role provider and all additional custom claims providers to obtain the corresponding set of role claims. For example, SharePoint Server 2013 uses attributes in AD DS, in a database such as a SQL Server database, or in an Lightweight Directory Access Protocol (LDAP) data store to find the user profile that represents the user (for example, the UPN or SID values). Your component to synchronize your forms-based provider should at a minimum populate user profiles with the user’s account name. You can also create a custom claim provider to import additional claims as attributes into user profiles.
  • For SAML-based claims authentication, SharePoint Server 2013 uses the AccountName attribute to locate the user’s profile and then invokes the SAML provider and all additional custom claims providers to obtain the corresponding set of role claims. The user identity claim should be mapped to the Account attribute in user profiles through the corresponding SAML claims provider, which should be configured to populate your user profiles. Similarly, a UPN claim should be mapped to the UPN attribute and the SMTP claim should be mapped to the SMTP attribute. To duplicate the set of claims that the user would usually obtain from their identity provider, you must add those claims, including the role claims, through claims augmentation. A custom claim provider must import those claims as attributes into user profiles.

Comments

Post a Comment

Popular posts from this blog

"There's a configuration problem preventing us from getting your document. If possible, try opening this document in Microsoft Word." Office WebApp Error

Problem: When Opening a word document I get the following error when Office Web Apps tries to render the document " There's a configuration problem preventing us from getting your document. If possible, try opening this document in Microsoft Word. " Initial Hypothesis: Check the ULS logs on the Web Front End (SharePoint Server) as this doesn't tell me much.  I found the following issue in my UL S: WOPI (CheckFile) - Invalid Proof Signature for file SandPit Environment Setup.docx url: http://web-sp2013-uat.demo.dev/Docs/_vti_bin/wopi.ashx/files/6d0f38c0d5554c87a655558da9cedcad?access_token... Resolution: Run the following PS> Update-SPWOPIProofKey -ServerName "wca-uat.demo.dev" More Info: http://technet.microsoft.com/en-us/library/jj219460.aspx
Continue Read

"We’re sorry. We ran into a problem completing your request. Please try that again in few minutes." Excel Service SharePoint

Image
This article explains about Excel related issue in our SharePoint 2013 Environment. Whenever user tries to open excel files uploaded in document library, it launches browser to open the file and then displays below error- " We’re sorry. We ran into a problem completing your request. Please try that again in few minutes." Also see below screenshot- As part of issue analysis, following checks were performed- 1.) Check if Excel Services is running. ( This was running in our case. ) Open Central Administration -> System Settings -> Manage Services on Server -> Excel Calculation Service -> Started 2.) Check if Excel Service Application is associated to Web Application in question. ( This was configured in our case. ) Open Central Administration -> Application Management -> Manage Web Applications -> Select Web Application -> Select Configure Service Associations 3.) Check if Trusted File Location is configured for Excel Service...
Continue Read

Deployment error "The web.config is invalid on this IIS Web Site"

I've developed a webpart that deploys and works properly in my DEV environment. When I attempt to deploy to PROD I get the following error: SOMESERVER : http://acme.com/ : SharePoint - 41981 : Error: The web.config is invalid on this IIS Web Site: C:\Inetpub\wwwroot\wss\VirtualDirectories\41981\web.config. SOMESERVER : http://acme.com/ : SharePoint - 41981 : Error: The web.config is invalid on this IIS Web Site: C:\Inetpub\wwwroot\wss\VirtualDirectories\41981\web.config. SOMESERVER1 : http://acme.com/ : SharePoint - 23994 : Error: The web.config is invalid on this IIS Web Site: C:\Inetpub\wwwroot\wss\VirtualDirectories\23994\web.config. None of these virtual directories exist. Any ideas how to resolve? Solution : In Central Administration-> Operation-> Services on Server, please stop the Windows SharePoint Services Web Application service , SharePoint will remove the sites in IIS. And then start the Windows SharePoint Services Web Application service agai...
Continue Read