Exploring SharePoint 2010, 2013 as knowledge base..: July 2017

Sunday, July 30, 2017

What's new in authentication for SharePoint 2013

User authentication and authorization in SharePoint 2013

source: https://technet.microsoft.com/en-in/library/jj219758.aspx

User authentication in SharePoint 2013 is the process that verifies the identity of a user who requests access to a SharePoint web application. An authentication provider issues the authenticated user a security token that encapsulates a set of claims-based assertions about the user and is used to verify a set of permissions that are assigned to the user. User authorization in SharePoint 2013 is the process that determines the users who can perform defined operations on a specified resource within a SharePoint web application. SharePoint 2013 supports user authentication based on the following methods:

Windows claims
Security Assertion Markup Language (SAML)-based claims
Forms-based authentication claims

These claims-based authentication methods are now the recommended authentication methods for SharePoint 2013.

The app authentication and server-to-server authentication features of SharePoint 2013 require claims-based authentication. Because of this, claims-based authentication is the default for new web applications in SharePoint 2013. When you create a web application in Central Administration, you can only specify authentication methods for claims-based authentication. Although Windows Classic mode authentication is still available in SharePoint 2013 and can be configured through Windows PowerShell, we recommend that you use claims-based authentication. Windows Classic mode authentication is deprecated in SharePoint 2013.

Improvements in claims infrastructure

SharePoint 2013 also includes the following improvements in claims authentication infrastructure:

Easier migration from classic mode to Windows-based claims mode with the new Convert-SPWebApplication Windows PowerShell cmdlet

Migration can be run against each content database and each web application. This is in contrast to SharePoint 2010 Products, in which the migration was run against each web application. For more information, see Migrate from classic-mode to claims-based authentication in SharePoint 2013.
Login tokens are now cached in the new Distributed Cache Service

SharePoint 2013 uses a new Distributed Cache Service to cache login tokens. In SharePoint 2010 Products, the login token is stored in the memory of each web front-end server. Each time a user accesses a specific web front-end server, it needs to authenticate. If you use network load balancers in front of your web front-ends, users need to authenticate for each web front-end server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and its delay, it is recommended to enable and configure load balancer affinity (also known as sticky sessions). By storing the login tokens in the Distributed Cache Service in SharePoint 2013, the configuration of affinity in your load balancing solution is no longer required. There are also scale-out benefits and less memory utilization in the web front-ends because of a dedicated cache service.
More logging makes the troubleshooting of authentication issues easier

SharePoint 2013 has much more logging to help you troubleshoot authentication issues. Examples of enhanced logging support are the following:
- Separate categorized-claims related logs for each authentication mode
- Information about adding and removing FedAuth cookies from the Distributed Cache Service
- Information about the reason why a FedAuth cookie could not be used, such as a cookie expiration or a failure to decrypt
- Information about where authentication requests are redirected
- Information about the failures of user migration in a specific site collection

Server-to-server authentication

SharePoint 2013 extends OAuth to implement a server-to-server authentication protocol that can be used by services such as SharePoint 2013 to authenticate other services such as Exchange Server 2013 or Lync Server 2013 or services that are compliant with the server-to-server authentication protocol.

SharePoint 2013 has a dedicated local server-to-server security token service (STS) that provides server-to-server security tokens that contain user identity claims to enable cross-server authenticated access. These user identity claims are used by the other service to lookup the user against its own identity provider. A trust established between the local STS (the SharePoint 2013 server-to-server STS) and other server-to-server compliant services (the Exchange Server 2013 or Lync Server 2013 server-to-server STS) is the key functionality that makes server-to-server possible. For on-premises deployments, you configure the JavaScript Object Notation (JSON) metadata endpoint of the other server-to-server compliant service to establish this trust relationship. For online services, an instance of the Azure Access Control Service (ACS) acts as a trust broker to enable cross-server communications among the three types of servers.

The new server-to-server STS in SharePoint 2013 issues access tokens for server-to-server authentication. In SharePoint 2013 (and also in SharePoint 2010 Products), trusted identity providers that are compliant with the WS-Federation protocol are supported. However, the new server-to-server STS in SharePoint 2013 performs only the functionality that enables temporary access tokens to access other services such as Exchange Server 2013 and Lync Server 2013. The server-to-server STS is not used for user authentication and is not listed on the user sign-in page, the Authentication Provider UI in Central Administration, or in the People Picker in SharePoint 2013 Products.

App authentication

SharePoint 2013 uses OAuth 2.0 to authorize requests by apps in the SharePoint Store and App Catalog to access SharePoint resources on behalf of a user. The user grants permission to apps in the SharePoint Store and App Catalog to access SharePoint resources on the user's behalf when they are installed. For example, a user installs an app from the SharePoint Store. A SharePoint site contains an embedded HTML inline frame (IFRAME) that the app renders and that requires the app to access a user list. When a Web browser displays the site, the app then calls back to the server running SharePoint 2013 to access the list on behalf of the user. After the app obtains the data from the list, it displays the contents of the IFRAME.

The app authentication process in SharePoint 2013 uses OAuth to verify a claim that an app makes and assert that the app can act on behalf of an authenticated user. In SharePoint 2013, an instance of the Azure ACS acts as the app identity provider. You can also use app authentication without ACS. The authorization process verifies that an authenticated app has permission to perform a defined operation or to access a specified resource.

Sunday, July 23, 2017

Nintex form javascript code(NDP)

Get PeoplePicker Value on Nintex form -(Approval Limits)

Call the Service from JQuery

The following demonstrates how to call the service from a Script Editor Web Part using simple HTML, JavaScript and JQuery.

source: Source

<script src="http://sp13.dev/SiteAssets/jquery-1.10.2.min.js"></script>

<h2>SharePoint 2013: Consume a custom WCF REST service hosted in SharePoint 2013.</h2>
<h3>This is a quick sample to demonstrate calling a custom SharePoint-hosted WCF REST service from a
    Script Editor Web Part using simple HTML, JavaScript and JQuery.
</h3>

<div>
    <br />
    <p id="message">Loading presidents...</p>
</div>

<div id="resultsPanel"></div>

<script type="text/javascript">
    $(document).ready(function () {
        getPresidentsData();
    });
  
function getPresidentsData() {
    var serviceUri = _spPageContextInfo.webAbsoluteUrl +
        "/_vti_bin/BarkesServices/PresidentsService.svc/GetAllPresidents";
    $.ajax({
        type: "GET",
        contentType: "application/json",
        url: serviceUri,
        dataType: "json",
        success:
            function (response) {
                showPresidentsList(response);
                $('#message').html("<a href=" + serviceUri + ">" + serviceUri + "</a>");
            },
        error:
            function (err) {
                alert(err);
            }
    });
}

function showPresidentsList(presidentsData) {
    $.each(presidentsData, function () {
        $('#resultsPanel').append($(this)[0].Id + ' - ');
        $('#resultsPanel').append($(this)[0].FirstName + ' ');
        $('#resultsPanel').append($(this)[0].LastName + ' (');
        $('#resultsPanel').append($(this)[0].EmailAddress + ')');
        $('#resultsPanel').append('<br><br>');
    });
}
</script>