SharePoint Multi-tenant App: Get Azure Security Group Members Programmatically

We are developing SharePoint provider hosted application for SharePoint Online. This application is going to be multitenant and used by different customers with Office 365 subscriptions. Previously we developed SharePoint solutions on-prem and new app model brings us a lot of challenges and new tasks.

One of them is the following:
The provider hosted app needs to programmatically get members of security group from Office365 tenant. Business case is pretty simple we need to know all members of SharePoint group to make a report per each user. and if our SP group contains Security group we need to resolve members somehow...

Solutions Overview
Before start digging into code, let's find out what Security Group is? Where is it resided, managed?
Does it depends on Office 365 plan?

Security Group is Azure Active Directory security group. When you create some O365 subscription, MS creates Azure AD instance where your users/groups are stored. So you can manage the users and groups from this AD by different ways:

1) Office365 admin portal https://portal.microsoft.com
2) Azure portal https://manage.windowsazure.com, but you need to create additional subscription to windows Azure and I suppose not all customers, especially midsize, have this subscription.
3) Microsoft Azure Active Directory Module for Windows PowerShell commands http://msdn.microsoft.com/library/azure/jj151815.aspx
All these ways make changes to the same Azure AD instance. and if you change something via Office365 portal, you will see the changes in Azure portal immediately.
Good article gives overview what's going on behind the scene http://technet.microsoft.com/en-us/library/hh967611.aspx

So base questions are the following:
1) How to authenticate and authorize to Azure AD from the SharePoint App
2) How to get group identification to pass it to Graph API
3) Customer's installation use cases: What target customers, tenant's owners should do to make their Azure AD available for the SharePoint App.

SPUtility.GetLocalizedString and Potentially excessive number of SPRequest

This post is about simple thing in SharePoint 2010 like string localization :) I know that method SPUtility.GetLocalizedString is well known for every SharePoint developer, but let's deep into details.

What's wrong with this method?

Every call of this method will create SPRequest instance when HttpContext.Current is null. For example, if you have some timer job processes quite big amount of data and you have to save some localized strings (for example Choice field values), the system will create huge number of SPRequests. Of course these SPRequests are disposed by this method but anyway why do we need that if we already have instance of opened SPWeb that holds needed SPRequest instance?

              

Why it's wrong?

This is defenetly not critical problem but some customers worry about messages in ULS log like:

Potentially excessive number of SPRequest objects (16) currently unreleased on thread 41.  Ensure that this object or its parent (such as an SPWeb or SPSite) is being properly disposed. This object is holding on to a separate native heap.This object will not be automatically disposed. Allocation Id for this object: {A19A2B81-8D0A-4A56-BE7C-1D816185417C} Stack trace of current allocation:   
 at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite site, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)    
 at Microsoft.SharePoint.SPRequestManager.GetContextRequest(SPRequestAuthenticationMode authenticationMode)    
 at Microsoft.SharePoint.Administration.SPFarm.get_RequestAny()    

of course such messages could be caused by big amount of opened SPSites or SPWebs and actually such messages are reason for code review.

How to eliminate this in SharePoint 2010?

"Hack" is obvious - create fake HttpContext and set already created SPWeb to HttpContext.Current.Items["HttpHandlerSPWeb"]

But first of all - review the code and try to reduce number of opened SPSite, SPWeb objects at same time. 

What about SharePoint 2013?

SharePoint 2013 has smarter implementation of Request

SharePoint 2013 Search For Anonymous Users

Recently I've migrated SharePoint 2010 search solution to SharePoint 2013 platform and I'd like to share some experience and the most problematic points for me. There is a short description below of valuable things in the solution to get understanding what's going on:

• The initial search solution uses custom Managed Properties, Search Scopes.
• Includes search scenarios under anonymous users. 
• The search UI is provided by OTB web parts like SearchBoxEx and  CoreResultsWebPart.
• Search is intended to search within one site collection

Let’s have a look how the configuration of anonymous search scenarios has been changed in SharePoint 2013 Search with regard to SharePoint 2010:

1) First To make the search works with anonymous users, I need to deactivate site collection feature Limited-access user permission lockdown mode. If the feature is activated, anonymous users won't have access to the list items' display forms and to the lists' view pages at all(even if you enable anonymous access for Entire site). Therefor search crawler trims access to these items and they don't appear in search result for anonymous users.It was the most problematic point for me and I spent a day to realize what going on with access :)

2) New Managed Properties have some additional configuration properties. One of them its Safe check-box. So my managed property is used in the custom search scope and anonymous users have to search in this scope that's why I need it to be checked.Also to search by the managed property and include it to the full-text index, it should be marked as Retrievable and Searchable.

3) Search Scopes is deprecated and SP2013 provides Result Sources instead of Search Scopes. But I have to notice that old Search Scopes(despite of it's deprecated) works fine and I managed to cover all required search scenarios using old approach, due to lack of time to use new approaches. So the custom code which creates Search Scopes hasn't been changed since SharePoint 2010.

4) Search web parts have been changed. Now standard Search Center site collection in SharePoint 2013 includes new web part for search box and new web part for search result. But again old  SearchBoxEx and  CoreResultsWebPart work fine. (except CSS styles of Search Box web part )


So, hope this article will help someone to avoid misunderstanding and will save time.

Code Generator From Xml Fields Defenition

Hi everyone

I continue write my articles about SharePoint development. Today article will about how to write correct code when you use SharePoint field’s name and ID. I present small online tool right on this page. I think that it help you to increase speed of writing code and help to make one part of code more independent from another parts. So let's get down from word to business.

Welcome Post

Hi, Everyone

This is my first post in my development blog. In coming soon I will write articles about .NET, SharePoint development features, but  in generally my posts will about SharePoint. And now I am preaparing topic about ListViewByQuery control and how to extend it for more efficient use. This article will little concern SharePoint custom list templates, CAML in schema.xml file, content type forms and custom rendering templates.

Thanks for read my first post.