Loading...

Sunday, August 25, 2013

Security Trimming for Managed Navigation in SharePoint 2013

Managed Navigation is the new concept which is introduced in SP 2013. Manged terms can be used for Navigating to Pages but it has  few limitations .
one of the limitation is, there is no OOB way to apply security trimming. But Interestingly I found one :)
So , try as follows
1)In Pages Library, Edit Page property to update the Managed metadata column ( Wiki Category can be used  for the same purpose

2)Once the Page is tagged with specific Metadata , Open  up the  Hidden Taxonomy List and break the permission for this List (here you have to make sure that , the Page and Managed Term has same unique permissions)
So Navigate to siteurl/Lists/TaxonomyHiddenList/AllItems.aspx  and find  for the metadata term , for which the page was tagged for
3)Hit 'Shared With' --> 'Advanced Setting'  and provide unique permission to this term , so that this term will be visible to only particular group or user.


Friday, August 9, 2013

An OOB Webpart Customization Approach:Client Side Rendering Of List / WebParts using JSLink in SharePoint 2013

I read many articles regarding use of JSLink and this one for MDS enabled sites. But I would like to explain it at high level
Unlike in SharePoint 2010 OOB list customization/WebPart customization ,Now there is no need to override OOB css or writing javascript logic considering whole html rendered at runtime.
Using JSlink , OOB html can be replaced at elementary level as follows.


(function () {
    // Initialize the variable that stores the objects.
    var overrideCtx = {};
    overrideCtx.Templates = {};

   1) // Here customize list header by replacing header html
    
    overrideCtx.Templates.Header = "<B><#=ctx.ListTitle#></B>" +
        "<hr><ul id='unorderedlist'>";

   2) // Here this function will be called  n number of times where n is the numb         er of items in list or library

    overrideCtx.Templates.Item = customItem;

    3) // Here customize list footer by replacing footerhtml

    overrideCtx.Templates.Footer = "</ul>";

    
    // Register the template overrides.
    SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrideCtx);
})();

// This function builds the output for the item template.
// It uses the context object to access announcement data.
function customItem(ctx) {

    // Build a listitem entry for every listitem in the list.
    var ret = "<li>" + ctx.CurrentItem.Title + "</li>";
    return ret;
}

This resolves problem about writing XSLT at listview/Dataview level.But in Content query webpart , still there is space for writing xslt but that's why Content search webpart is introduced . though it is available in on-premise version, try this link for it's replacement in office 365

Monday, August 5, 2013

Data Access in SharePoint And Remote App :Inbound and Outbound scenarios


1)Data Access in SharePoint And Remote App :Inbound scenarios

Inbound data connectivity

The following connectivity options are available for inbound scenarios:
  • OAuth: An open protocol that enables secure authorization in a simple and standard way.
    AppOnly Policy : enables users to approve an application to act on their behalf without sharing their user name and password.                                                                                                         
    Server Side Code :You can use OAuth with server-side code. It is a good option if you need to run a non-interactive process, or if you need to elevate privileges to other than those of the logged-on user. For information about OAuth, see Authorization and authentication for apps in SharePoint 2013.
  • Cross-domain library: A client-side alternative in the form of a JavaScript file (SP.RequestExecutor.js) hosted in the SharePoint website that you can reference in your remote app as long as they are in the same internet zone. Multi-domain Interaction : The cross-domain library allows you to interact with more than one domain in your remote app page through a proxy.                                                                        
    Client Side Code : This is a good option if you prefer your app code to run in the client rather than in the server, or if there are connectivity barriers, such as firewalls, between SharePoint and your remote infrastructure. For more information, see How to: Access SharePoint 2013 data from remote apps using the cross-domain library.
    (Click following image )

2)Data Access in SharePoint And Remote App :Outbound scenarios


Outbound data connectivity

The following connectivity options are available for outbound scenarios (see Figure 2):
  • Web proxy: As a developer, you can use the web proxy exposed in client APIs such as the JavaScript/.NET client object models. When you use the web proxy, you issue the initial request to SharePoint. In turn, SharePoint requests the data to the specified endpoint and forwards the response back to your page. Use the web proxy when you want the communication to occur at the server level
    Both Javascript/.Net CSOM is available.                                                                               
    Direct calls through browser are not supported.
    For more information, see How to: Query a remote service using the web proxy in SharePoint 2013.
  • Remote event receivers: You can use remote event receivers to handle events that occur to an item in the app, such as a list, a list item, or a web. These events resemble those in a traditional SharePoint solution, except that they can work with the remote components of the app for SharePoint.
    Only .Net CSOM is available.    
    Client Side Technologies are not supported .                                                                 
    App can not access resource as current logged in User .
     For more information, seeHandling events in apps for SharePoint.
  •  Custom proxy page for the cross-domain library: You can use the cross-domain library to access data in your remote app if you provide a custom proxy page that is hosted in the remote app infrastructure. As the developer, you are responsible for the custom proxy page implementation and must deal custom logic, such as the authentication mechanism, to the remote app. Use the cross-domain library with a custom proxy page if you want the communication to occur at the client level. 
    Can not add SharePoint Components to Remote App                                                         
    .Net CSOM is not available
    (Click following image )

Sunday, August 4, 2013

What is Distributed Cache Service in SharePoint 2013 ?How does it help in authentication?

One of the big changes for the authentication infrastructure is being able to use the new Distributed Cache Service.  SharePoint uses that caching service to keep track of FedAuth  cookies for users that authenticate using FBA or SAML authentication.  In SharePoint 2010 each web front end kept their own local cache of fed auth cookies, and as a result we required you to use sticky sessions with your load  balancers to ensure that once a user got
authenticated, he or she was always redirected back to the same server so the 
authentication cookie could be found.  By using the new Distributed Cache to keep track of 
these authentication cookies, we no longer require sticky sessions when you use FBA or
SAML claims in SharePoint 2013.

 A) FBA authentication


Forms-based claims authentication is an interaction between a client computer, a SharePoint server, and a membership and role provider that is available through the ASP.NET interface.

Step 1: Assuming that the client computer does not already have a claims-based security token, forms-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint web page.
Step 2: The SharePoint server responds with a forms-based login page for the user to enter credentials.
Step 3: The user on the client computer types credentials and the client computer sends them.
Step 4: The SharePoint server then validates the sent credentials with the configured membership provider.
Step 5: The SharePoint server then queries the role provider for the roles associated with the user credentials. These become the list of role claims for the user account.
Step 6: The Security Token Service on the SharePoint server then creates a claims-based security token and stores it with the Distributed Cache service on the SharePoint farm. Claims in the security token are based on the user name and the list of roles for the user account.
The SharePoint server then creates and sends a Federated Authentication, or FedAuth, cookie to the client computer. This cookie contains an encrypted key or index to the security token. If the user is authorized to access the requested web page, through analysis of the claims in the security token and the configured permissions, the SharePoint server then sends the contents of the page. For subsequent requests, the client computer uses the FedAuth cookie for authentication.

B)SAML Based (ADFS)  claims authentication




SAML-based claims authentication is an interaction between a client computer, a SharePoint server, an identity federation server (such as Active Directory Federation Services, or AD FS), and an identity provider, which contains the actual accounts, passwords, and account attributes, such as Active Directory Domain Services, or AD DS.
Please note that this process example is deliberately simplified. AD FS and SAML claims are not required if you are using an AD DS infrastructure in which the forests and domains trust each other.
Before we step through the authentication process, let’s examine the set of trust relationships that must be in place. First, the federation server, the AD FS server, must trust the identity provider for which it is issuing SAML security tokens. In this case, the trust is implicit because the AD FS server is a member of the AD DS domain, and therefore trusts the validation of security credentials by its domain controllers.
AD FS must also trust security token requests for locations on the SharePoint server.
For this trust relationship, you configure AD FS with the URLs of SharePoint web applications as relying parties. Web pages within those URLs will now be trusted for SAML security token requests.
The SharePoint server must also trust the AD FS server. The AD FS server uses a signing certificate to sign the SAML security tokens that it issues. To validate the digital signature on the security tokens issued by AD FS, you configure the SharePoint farm with the public portion of that signing certificate.
Now let’s take a look at the authentication process.
  • Step 1: Assuming that the client computer does not already have a claims-based security token, SAML-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint web page.
  • Step 2: The SharePoint server redirects the client computer to the AD FS server to obtain a SAML-based login page for user credentials.
  • Step 3: The user types credentials and the client computer sends them to the AD FS server with a request for a SAML security token.
  • Step 4: The AD FS server validates the sent credentials with the identity provider, which in this case is an AD DS domain controller.
  • Step 5: The AD FS server constructs a SAML security token, signs it, and then sends it to the client computer.
  • Step 6: The client computer sends a new request for the web page, this time it includes the SAML security token that it received from the AD FS server.
  • Step 7: The Security Token Service on the SharePoint server then creates a claims-based security token and stores it with the Distributed Cache service on the SharePoint farm. Claims in this security token are based on the claims in the SAML security token from the AD FS server.
The SharePoint server then creates and sends a Federated Authentication, or FedAuth, cookie to the client computer. This cookie contains an encrypted key or index to the security token. If the user is authorized to access the requested web page, through analysis of the claims in the security token and the configured permissions, the SharePoint server then sends the contents of the page. For subsequent requests, the client computer uses the FedAuth cookie for authentication.


Thursday, August 1, 2013

Building Custom Service Applications But When?

1)Whenever there is requirement to share the data across cross sitecollections or across farms
 or if you want to associate third party service may be for analytics or computation. building custom service application is must
2)To do so, you need to develop Webfront end server (Proxy UI for configuration), Application server (WCF end point) and SQL databases
Checkout this to get standard template to build custom service application