Office 365 and cloud-based solutions and has been used to bring some of the
first ... and OneNote from buttons within the Office ribbon interface using VSTO.
SideKick365 Service Bus & Security Overview A discussion of the SideKick365 Service Bus and detaled discussion of Security within SideKick365 Applications
Version 1.1 October, 2011 SkyLite Systems ©2011
The SideKick365 Service Bus is a revolutionary framework that leverages SharePoint and Office to unify voice, data, electronic files and digital images into meaningful and actionable information. It is the first application framework that can leverage Microsoft’s investment in Office 365 and cloud-based solutions and has been used to bring some of the first true Office 365 applications to the marketplace. This whitepaper contains an overview of the SideKick365 Service Bus and a detailed discussion of how fine grained security is delivered within the SideKick365 Service Bus. SideKick365 Service Bus – An Overview All of our SideKick365 products – including Sidekick365-xRM and SideKick365-DCM - are built around the SideKick365 Service Bus to deliver a secure and scalable collaboration framework leveraging SharePoint, Lync, and Office in new and exciting ways. Elements of the SideKick365 Service Bus include:
Fine-grained security leveraging ad-hoc and structured permission management – SideKick365 applications can leverage two different security models to implement finegrained permission management for every item stored within SideKick365 applications. Both approaches are important and required to properly manage different kinds of content. Structured security is used for content that has security requirements based upon long-lived permission rules and long-standing user and system roles and relationships. Ad-hoc security is required when permission rules are defined on a caseby-case basis on a one-off basis.
Integration of external content using the Client Object Model in SharePoint – SideKick365 includes methods that leverage the client object model in SharePoint to “push” content into the SideKick365 repository from tools like Office and third party applications. This service can be leveraged to support digital scanning of paper and integration of voice messages to name just a few uses of this service.
Extension of Microsoft Office 2007 and using Visual Studio Tools for Office (VSTO) – The Microsoft Office suite of tools is used to create much of the content managed by SideKick365 applications. The SideKick365 Service Bus includes methods to integrate clients running Microsoft Office into the SideKick365 repository from within the Office tool suite. Examples include direct integration with Word, Excel, PowerPoint, Outlook and OneNote from buttons within the Office ribbon interface using VSTO. The VSTO extensions are used in conjunction with the Client Object model allowing authentication and content “publishing” into SideKick365. Copyright SkyLite Systems 2011 – Page 1
Electronic Books – The Service Bus includes methods and design patterns to support organize content into electronic cabinets and “books” with enhanced security, auditing and viewing capabilities within SharePoint .
Cabinets – The SideKick365 Service Bus includes methods and design patterns to support the creation and management of logical structures comprised of disparate content correlated into logical containers called cabinets. Cabinets support the idea of a parent list item and related items from child lists. Cabinet child items and lists share security and metadata information from the parent list item.
Metadata Security Profile Management – The SideKick365 Service Bus supports management of a rich assortment of security profiles that can be used for permissions on items using structured security.
The remainder of this document will examine how security is managed using the SideKick365 Service Bus. Security in SideKick365 The security service included with the SideKick365 Service Bus ensures that permissions are automatically set for every item using a scalable framework allowing millions of items in thousands of lists. The remainder of this white paper will explore how the SideKick365 security model works and the security limitations inherent on a solution built within SharePoint. It includes a detailed review of how the security model is used and suggested best practices to ensure maximum efficiency and efficacy. The examination will include a detailed review of how
Copyright SkyLite Systems 2011 – Page 2
the designers of SideKick365 architected and implemented a highly-scalable, fine grained security capability within the Service Bus of SideKick365. A few terminology conventions and concepts should be explained before we proceed. An examination of the difference between security and permissions is appropriate since these terms are used frequently in this white paper but they are not one in the same.
Permissions - Permissions determine what you can access and what you can do (what functionality) with things stored within SideKick365. Security - Security is the framework that allows you to set permissions on a list, folder or item within list.
SharePoint and SideKick365 – Security Considerations SideKick365 is the first application framework written specifically to work within Office 365. It is comprised of several components including methods and procedures that are packaged as .WSP assemblies for deployment within SharePoint , a stand-alone .EXE application for TWAIN scanners, and VSTO add-ins for Microsoft Office applications. SideKick365 can also be used within dedicated SharePoint environments that may be run locally or in dedicated hosted environments. Finally, it is important to note that SideKick365 is always deployed “on top of” SharePoint . For technical readers, SideKick365 uses patterns and procedures that incorporate sandboxing, declarative workflows, the client object model, and innovative approaches support permission management for large quantities of list items. SideKick365 is bound to the restrictions and limitations that are inherent in SharePoint Online and Office therefore, it is important to understand the capabilities and limitations within SharePoint . A quick review of permission management capabilities and limitations within lists in SharePoint is appropriate. SharePoint Permission Capabilities SharePoint allows for fine-grained permission management on lists, folders in lists, document sets in lists and unique permission on specific list items. SharePoint allows you to “break” permission inheritance from a list so that a list item, folder or document set can have its own permission settings that are separate and unique from the list that contains it. Practically speaking, a SharePoint list can contain up to 50,000 items that break permissions from the list. This is a very important limitation to consider. To illustrate how this limitation influences architectural considerations within SideKick365, consider the following. Imagine that we break permission inheritance and allow unique permissions to be applied to every item in a list. Further, assume we do not use any folders or document sets. This means the SharePoint list can store up to 50,000 items with unique security on each item. Copyright SkyLite Systems 2011 – Page 3
Support for only 50,000 items in a list is often not sufficient to meet the needs of many applications. Consider a set of sales opportunities stored within a list. Sales reps probably want to set unique permissions on every sales opportunity so that only users with the proper permissions can access their deals. A large sales force could easily have more than 50,000 active opportunities at a time and outstrip the limit for unique security in a list. In fact, we ran into this exact scenario during early testing of SharePoint . So how does SideKick365 allow management of more than 50,000 items in a list when we need permissions on every item? SharePoint Permission Capabilities and SideKick365 Architectural Considerations The architects of SideKick365 thought long and hard about this scenario. Luckily, SharePoint lists support unique permission management on folders and document sets in a list. This allows you to set permissions on a folder or document set that can be inherited by items stored within. If you can store items with the same permission requirements into a folder or document set that have the same permission settings as the item you wish to store, then you can hold many more than 50,000 items by bundling items with similar permission requirements within a document set or folder. This is an important concept and the SideKick365 Service Bus includes methods and patterns that automatically “groups” items with the same permission requirements into folders or document sets using SharePoint declarative workflows with custom sandboxed activities. Remember, SharePoint lists can handle 50,000 items, including folders or document sets that have their own unique permission requirements. As mentioned above, if you bundle items with the same permission profile into a folder or document set, then you can now manage many more than 50,000 items. In fact, you can now manage millions of items as long as you can make sure those items can all “fit” permission requirements of the folder or document set and that all of the permission profiles of the folders and document sets you need remains under the 50,000 “broken inheritance” limit per list. To summarize, SharePoint can support 50,000 items with their own permissions settings within a SharePoint list. If you can store items that share the same permission settings using folders and document sets, then you can securely manage permissions for many millions of items in a SharePoint list. Manually storing list items in folders with the proper permissions is tedious and error prone. The trick then, is to have the system automatically create and place list items with the same permission requirements into folders or document sets that share these permission settings. Users should not be required to create and maintain this structure. A way to automatically set up and utilize this scalable approach to fine grained security is at the heart of the SideKick365 Service Bus.
Copyright SkyLite Systems 2011 – Page 4
SideKick365 Service Bus - Two types of support for security Security is central to nearly all applications we have built - especially those built for Office 365. As we began to develop applications using early versions of the SideKick365 framework, we noticed that two security models – long-lived and “one-off” - were usually needed to meet the requirements of these early applications. We call these approaches – ad-hoc and structured security. The following describes both security models and gives general guidelines when each type is required. (Note: The SideKick365 Service Bus includes support for both types of security models described below).
Structured Security – Structured security is based upon metadata about or data stored within a list item. When a new list item is created, SideKick365 uses the metadata or data associated with it to retrieve predefined permission settings stored within another SharePoint list. Once the permission settings are retrieved, the SideKick365 Service Bus moves the list item into a folder or document set with proper permissions. If the folder or document set does not exist in a list, SideKick365 creates the necessary folder or document set, sets the proper permissions and then moves the item into it. This ensures scalability and security since only authorized SideKick365 users can access or edit the item. There is no practical limit to the number of metadata or data fields that can be used to set permissions on an item in a list. Applications that leverage SideKick365 can be configured to support complex security requirements such as sales territories or taxonomies related to the content of the list item.
Structured security is useful when you need to assign security based upon preset, longstanding rules such as the organizational structure of a company or the long-lived relationships between SideKick365 users (for example an inside and field sales representative pairing). Consider a district sales manager-she requires access to all accounts and opportunities in a given sales territory. She should be given permissions via structured security settings (we call them permission associations) stored in a SharePoint list. The permission settings will be selected based upon the district associated with an opportunity or account – either in metadata or stored within the list item.
Copyright SkyLite Systems 2011 – Page 5
Ad-hoc Security Model – Ad-hoc security is designed to support fluid, short lived or onetime relationships. Permissions are defined as users are given access to the item on an as-needed basis. Ad-hoc security is not based upon predefined rules or associations of the organization stored in another SharePoint list. Ad-hoc security is useful when you need to quickly add or remove users or systems and quickly assign permissions as needed for that specific item. For example, projects can contain members from many different organizational units who may only work on that project. As such, there is a need to quickly add access to project members and assign the proper permissions using the ad-hoc security model.
SideKick365 Service Bus – Permission Management Security in SideKick365 is centered on assigning and managing the permissions assigned to an item. Permissions have two default settings – “Read” and “Edit” that are automatically set using the SideKick365 Service Bus. A discussion of each follows.
Read – the Read permission setting allows a user to view content but they cannot edit or delete. Edit – The Edit permission allows a user to read, edit or delete the item
SideKick365 Security – Support for Cabinets SharePoint allows you to define parent-child relationships between lists. This allows for cascade deletes if a parent is deleted and it also help protect against deleting any parent list item if a child record still exists. We call these related list items cabinets. The SideKick365 Service Bus adds cascading permissions management from a parent to child list items within a cabinet. Parent list item permissions are automatically assigned to child records in a cabinet by the SideKick365 Service Bus. Changes to the parent security cascade to all child records in the cabinet. SideKick365 – Using the Service Bus for Security in Sideick365 Applications Permission management in SideKick365 starts when a new item is created in a list. As you will recall, security is managed using ad-hoc or structured approaches. Every item in SideKick365 must have an owner, and the owner is defined by the user as a metadata item about or data within the list item. (Note: the owner of an item in SideKick365 can be a user or a role). The owner can always view, edit, delete or update any item they “own” in a SideKick365–based application. Copyright SkyLite Systems 2011 – Page 6
The remainder of this section will review how ad-hoc and structured security is applied to an item by the SideKick365 Service Bus.
Ad-hoc Security - Once a list item with ad-hoc security is saved, the SideKick365 Service Bus looks at the related child lists in the cabinet and creates folders or document sets to hold child records that share the same permissions as the parent record. Users associated with the parent item in the cabinet are automatically added to the appropriate folders for that cabinet in each list with read or edit permissions by the SideKick365 Service Bus. Similarly, users can be removed from the cabinet permissions in each list as needed.
Structured Security – Structured security uses metadata about or data stored within a list item to look-up predefined permission associations stored in SharePoint. The following example shows how the SideKick365 Service Bus applies structured security to a list item using two dimensions, the owner field and a business unit field. Note - there is no practical limit on the number of data elements that can be used to set security. Step 1 – The SideKick365 Service Bus checks the value in the owner field in a list item and looks up the permission associations in another list used to store owner permission profiles. Any read or edit associations (including named users and groups) that have been defined for this owner are applied to the parent item and all child list items using declarative workflows managed by the SideKick365 Service Bus. By example - in SideKick365-xRM, owner permission associations are used to apply permissions that are based upon the relationships between users of the system. For example, field sales reps usually have an assigned inside sales rep. In our example, the field sales rep is the owner and the inside sales rep is associated with the outside sales rep (the owner) in the fields sales rep security profile. SideKick365-xRM uses the screen below to set up the permission associations for the owners of list items.
Copyright SkyLite Systems 2011 – Page 7
Step 2 – The SideKick365 Service Bus next looks at the business unit associated with the parent list item. The SideKick365 Service Bus checks the value in the business unit field of an item and looks up the permissions set in a related list of permission associations used to store business unit security profile. Any read or edit associations (including names users and groups) that have been defined for the business unit are applied to the parent item and all child list items in the cabinet using declarative workflows managed by the SideKick365 Service Bus.
In SideKick365-xRM, business unit security rules are used to apply permissions that are based upon the structure of the organization. Typically, this dimension of structured security applies permissions to allow managers or co-workers access to an item. Similarly, district sales managers are assigned permissions to view an item because the item is identified to belong within their management span – called a business unit. SideKick365 uses the screen below to set up the permissions between the “business unit” and the users or roles associated with it.
Copyright SkyLite Systems 2011 – Page 8
It is important to note that you can create security profiles for individual lists. Note the checkboxes for “Lead”, “Account” and “Opportunity” in the screen shot above. SideKick365 administrators can set profiles for a specific list or a set of lists by selecting the appropriate checkbox. It is common to have multiple security profiles, perhaps one for each list that may share common metadata or data values. An example includes the ability to see all leads and accounts if you belong to a business unit but not an opportunity unless you are a manager or owner. Users can also be restricted to the parent record of a cabinet or they can see all related lists in the cabinet. This can be set by a user or role as well by way of the radio buttons shown in the screen shot above. Finally, note that security can be changed as needed for this business unit and hitting the “update” button will apply these changes to all list items in SideKick365 that use this security profile. SideKick365- Security Collision Resolution From time to time, a security association of “Read only” and “Edit” may be assigned to the same user or a role for a specific item. SideKick365 resolves the association by applying the more permissive “Edit” permissions to the user for that item.
Copyright SkyLite Systems 2011 – Page 9
SideKick365 - A look at groups and security management in Structured Security When you invoke structured security for a list item, the SideKick365 Service Bus assigns all permission associations stored in security profile for that look-up data value (owner or business unit for example). If you store specific users in the permissions association entries of the security profile, than any change to the user associated with that list item will require SideKick365 to “walk through” all existing parent and child lists using that security profile. This is possible, but it is costly in terms of resources and time. A better practice is to use groups. If you associated groups in the security permission association fields, then all you need to do is maintain membership in the group and you can easily assign permissions just by adding or taking away membership in a group – SharePoint, tenant, external user or Active Directory.
Copyright SkyLite Systems 2011 – Page 10
