Archive for SharePoint 2013

Securing & Hardening SharePoint Sites – Part 3

Previously, we discussed how the CorasWorks platform enables working with data anywhere in your SharePoint farm, followed by some masterpage changes you can make to secure away SharePoint’s system pages within a site. In our third and final part of this series, I’ll describe how CorasWorks can be used to essentially create a secure “proxy” for use within your SharePoint-based applications.

Typically in SharePoint, if you want a user to be able to see some data, or even enable them to perform inserts/updates/deletes, you have to give that user at least direct access to the item(s), if not the parent List or even Site the data is in. However, with the CorasWorks External Data Provider – don’t let the word “external” fool you – you can actually create secured connections between a user interface on one SharePoint site and the data on another, without the logged in user actually having any access to said data.

Sounds crazy, or worse, unsecure? Not at all! The architecture supported is not unlike integrating with a line-of-business database application; a SharePoint admin can create and enable the equivalent of a service account that will be given the necessary rights to the underlying data to support the application requirements. That account’s information is then stored in secure web.config app keys. On the CorasWorks side, you can then reference the corresponding app keys in your configuration of an External Data Provider to make HTTP Post calls to any URL said account has access to – these can be calls to native SharePoint service endpoints or, even better, our own API.

From there, you can now focus on creating the optimal UI for your users and let CorasWorks handle the proxied connections between the UI and the data. The users accessing the application will only need Read rights to the UI elements, and so even if they ever figure out where the data is coming from (which they won’t, because you’ll have secured that away too), they still won’t be able to access it outside the UI you create.

If this sounds like a design pattern you need, email steve@corasworks.net and we’ll setup an architectural review to help get you started!

Securing & Hardening SharePoint Sites – Part 2

Previously we blogged about the reasons for – and potential concerns with – opening up a SharePoint application to external users. The improved collaboration and access to real-time data is certainly compelling, but what if we’re concerned savvy users might decide to poke around the SharePoint site we give them access to? Even with the proxy design available to architects using the CorasWorks platform, there’s always those users who may try to access content or underlying back-end SharePoint pages, like the “All Site Content” or “All People” pages.

Luckily, there’s a straightforward way to make some quick adjustments to a masterpage and restrict access to even those system pages for a given site. To start, let’s look at the first few lines of HTML that normally make up the body of a masterpage; this example comes from an unmodified “v4.master” in SharePoint 2010:

<body scroll=”no” onload=”if (typeof(_spBodyOnLoadWrapper) != ‘undefined’) _spBodyOnLoadWrapper();”><form runat=”server” onsubmit=”if (typeof(_spFormOnSubmitWrapper) != ‘undefined’) {return _spFormOnSubmitWrapper();} else {return true;}”><asp:ScriptManager id=”ScriptManager” runat=”server” EnablePageMethods=”false” EnablePartialRendering=”true” EnableScriptGlobalization=”false” EnableScriptLocalization=”true” />… (The rest of the page)</form>

</body>

When customizing a masterpage, one of the things you can do is add Security Trimmed Controls, which essentially allow you to wrap a block of content within your masterpage and thus restrict the display/running of it to only those users whose permissions match the settings specified. Here’s an example of one such use:

<Sharepoint:SPSecurityTrimmedControl runat=”server” ID=”HidePage” Permissions=”ManageWeb” PermissionMode=”All” PermissionContext=”CurrentSite”>

Now imagine you wanted to secure the entirety of your underlying SharePoint system pages, like “All Site Content” or your native List Views. No problem – simply wrap the entire contents of the <form> tag that encompasses the page and you’ve got a locked site where only users with sufficient permissions can access your back-end pages:

<body scroll=”no” onload=”if (typeof(_spBodyOnLoadWrapper) != ‘undefined’) _spBodyOnLoadWrapper();”><form runat=”server” onsubmit=”if (typeof(_spFormOnSubmitWrapper) != ‘undefined’) {return _spFormOnSubmitWrapper();} else {return true;}”><Sharepoint:SPSecurityTrimmedControl runat=”server” ID=”HidePage” Permissions=”ManageWeb” PermissionMode=”All” PermissionContext=”CurrentSite”><div id=”FullPage”><asp:ScriptManager id=”ScriptManager” runat=”server” EnablePageMethods=”false” EnablePartialRendering=”true” EnableScriptGlobalization=”false” EnableScriptLocalization=”true” />

… (The rest of the page)

</div>

</Sharepoint:SPSecurityTrimmedControl>

</form>

</body>

Want to display a note to users who try to sneak their way in; another simple tweak – just add a little HTML with some appropriate verbiage, then hide said message if the user does have sufficient rights:

<body scroll=”no” onload=”if (typeof(_spBodyOnLoadWrapper) != ‘undefined’) _spBodyOnLoadWrapper();”><form runat=”server” onsubmit=”if (typeof(_spFormOnSubmitWrapper) != ‘undefined’) {return _spFormOnSubmitWrapper();} else {return true;}”><div id=”ReadersMessage” style=”width:100%;text-align:center”><h1>Nothing to see here…</h1></div><Sharepoint:SPSecurityTrimmedControl runat=”server” ID=”HidePage” Permissions=”ManageWeb” PermissionMode=”All” PermissionContext=”CurrentSite”><script type=”text/javascript”>document.getElementById(“ReadersMessage”).style.display = ‘none’;</script>

<div id=”FullPage”>

<asp:ScriptManager id=”ScriptManager” runat=”server” EnablePageMethods=”false” EnablePartialRendering=”true” EnableScriptGlobalization=”false” EnableScriptLocalization=”true” />

… (The rest of the page)

</div>

</Sharepoint:SPSecurityTrimmedControl>

</form>

</body>

To learn more about the SPSecurityTrimmedControl, check out the documentation from MSDN here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webcontrols.spsecuritytrimmedcontrol_properties.aspx

The three properties you will want to focus on are the “Permissions”, “PermissionMode” and “PermissionContext” one as seen in the examples above; for reference, the examples here would hide the contents of any page using this masterpage to all users except those with Owner (or equivalent) rights on the current site.

Three Approaches to Building SharePoint Solutions

When it comes to building solutions with SharePoint, there are three approaches.

LowCode

No Code

SharePoint comes with a rich set of features and functionality that can help deliver your solution requirements.  For a feature matrix, you can refer to this SharePoint 2013 Feature Matrix blog posting.

But what if the business requirements can’t be delivered purely with out of the box capability?

Custom Code

With SharePoint Solutions, there is a general impression that the more complex the requirements are the more likely you are going to need custom code.  Depending on your organization, you may need to tap internal developers who will crack open Visual Studio and start plugging away on your requirements.  If you don’t have the luxury of having SharePoint developers you will need to employ outside consultants.

One thing to note around custom SharePoint code.  A .NET developer does not necessarily equal a SharePoint developer.  Knowing the SharePoint object model is required in addition to understanding .NET.  When doing custom code, if you treat SharePoint like all other web site development, you are likely to encounter pain later when upgrading or modifying it later.

With the specialized skills required for custom coded solutions, it requires a huge investment in developer resources, training and ongoing maintenance.  It’s quite possible that it makes it cost prohibitive to pursue solutions where complex requirements are in view.  But is there another option?

Low Code
The CorasWorks Approach

Traditional web developers are much more accessible than those with specialized SharePoint development skills.  They are also more affordable.  Most organizations have web developers with more common skills like HTML and XML along with JavaScript and jQuery.  You could train these resources to understand the SharePoint Client Side Object Model for instance but there are other options.

The “No Code” option implies being locked into certain functionality and capability.  The “Custom Code” comes with specialized resourcing requirements.  The “Low Code” option offers flexibility to meet solution requirements while leveraging more readily available resources.

CorasWorks provides a low code option through our Platform and Application Service (known as CAPS).  Our Platform and CAPS make it possible to build complex solutions with the flexibility you would expect from a custom solution but with a much smaller code footprint.  For a look at CAPS capability, please read this recent blog article outlining those capabilities.

With CorasWorks, your traditional web developer can build a feature rich, complex solution with less code and using the skills they already possess.  Our off the shelf solutions have taken this approach and it’s available for you to build your own solutions.  Have you taken some projects off the SharePoint solution roadmap because their requirements would have forced you down a custom development approach?  Well grab some pizzas, one of your traditional web developers, a copy of CAPS and reinstate those projects.  You’ll be surprised at what you can build with this low code approach.

Sign In as a Different User in SharePoint 2013 – Lost and Found

SharePoint 2013 adds many great things but for those of us that develop & test solution and need to do so as different users, we’ve noticed the “Sign in as a Different User” option is missing from the Name/Welcome menu. To make matters worse, on some machines/browsers, even if you log out it will not let go of the last logged in user.

Now there are at least a few blogs out there which explain how to modify a SharePoint system file within hive (which, remember, can also be overwritten/undone by a Microsoft update) to add the option back to the menu globally. However, what if you don’t want the option in the menu for all users, all the time; or you don’t have access to the physical server, or don’t wish to modify said file? The good news is that there is a simple trick to force the “Sign in as a Different User” prompt to appear.

All you have to do is add “/_layouts/closeConnection.aspx?loginasanotheruser=true” to the end of your site URL and that’s it. It will log you off and bring up the Sign in prompt so you can login as a different user.

What happened to “NT AUTHORITY\Authenticated Users” in SP2010 & SP2013

For those that used SharePoint prior to the 2010 release, you may recall we had the option to add an account named “NT AUTHORITY\Authenticated Users”, which had the effect of granting access for all of your AD users with one shot. However, if you go looking for the same account in SharePoint 2010 or SharePoint 2013, you may become concerned when you search the address book and receive this:

PeoplePicker

Worry not though; while Microsoft has hidden it away from the search of the address book, said account does still exist. You just need to manually type in “Authenticated Users” then click the user check icon instead of searching the address book for it. Once the check completes, you should see an image similar to below:

GrantPermissions

Now you have easy access for all your AD users again!

Prevent Edit in MS Word (or any App) in SharePoint

Recently we were faced with the requirement from a client that wanted to be able to edit a Microsoft Word document accessible via SharePoint (via a link) but ensure that once the document was closed, the user could no longer edit it. Thanks to the way Microsoft Office maintains the linking of documents between the client and SharePoint when opening a file, it is easy for a user to view the link to a document or List Item attachment when it opens and then, when saving, see the original file location on the server.

Our issue became how do we lock down the file without a lot of manual permissions but still allow a user to click a link and download a copy of a document. What we crafted was a solution that leveraged the native “_layouts/download.aspx” page to effectively break the link between the file in SharePoint and the local copy a user opens on their machine. Within our documents display, we simply dynamically generate hyperlinks using the following format:
<<YourSiteURL>>/_layouts/download.aspx?SourceURL=<<YourFileURL>>

Doing so ensures the copy of the file downloaded to the client machine has no URL or link back to the original location, and thus obscures the ability for a user to click & open a document in SharePoint and then easily save it back to SharePoint – because in this case, that’s exactly what we did not want. As an added perk, since the display was built via XSLT (remember, CAPS supports XSLT 2.0), we were also able to conditionally build the link to the documents based on the overall item status.

Custom “Sign in as a Different User” button in SharePoint

Whether you’re working in SharePoint 2007, 2010 or 2013, you may have a need to create a custom “Sign in as a Different User” button within your site design. On a recent project for a client, we were creating a Customer Portal that was external facing and were using a custom masterpage that included removal of the native SharePoint ‘Welcome’ menu, where the “Sign in as a Different User” is normally found – or in the case of SharePoint 2013, not found at all.

There’s a simple way to wire up your own custom element that will trigger the same behavior as the “Sign in as a Different User” menu option. In SharePoint 2007, just wire up the following function call to any element within your layout/page:

LoginAsAnother(‘/_layouts/accessdenied.aspx?loginasanotheruser=true’,0);

Meanwhile, in SharePoint 2010 or 2013, the function call is simply to a slightly different application page:

LoginAsAnother(‘/_layouts/closeConnection.aspx?loginasanotheruser=true’,0);

That’s it! Now you can create any button, image, hyperlink or other markup you want that, when clicked, will pop the “Sign in as a Different User” prompt, then redirect back to the current page.

SharePoint 2013 Feature Matrix

Posted by Rodney Fickas, Director of Professional Services at CorasWorks

Recently I was made aware of a blog post by Dave Coleman over at SharePointEduTech that lists out all the features in SharePoint 2013.  If you’ve been around SharePoint from early on, you know that with each major release comes more layering of features.  Dave’s blog takes all of the SharePoint 2013 features and makes you aware of what SKU you can expect to find that feature.  Kudos to Dave for what I can only imagine was an inordinate amount of time to put this together.

He reminded me of just how rich the feature set is in SharePoint.  It also had me considering our own SharePoint readiness within my Professional Services team here at CorasWorks.  It’s tempting as a software vendor to shrink your world down to the size of your own product.

It’s even more tempting as part of a professional services team at a software vendor to limit your services to just your own product and ignore the many other important things that surround it.  But our customer’s value trusted advisors especially around SharePoint because of the rich feature set.  They desire to work with consultants who want to bring the best of breed to bear on their unique requirements.

This may mean that some of the rich feature set native to SharePoint might provide the best option for meeting that requirement.  If not, then maybe something in the CorasWorks Platform does or some custom development that we can offer.  It might be that a completely separate product to complement all of the above is appropriate.

Customer’s trust and value SharePoint consultants that have a breadth and depth of knowledge.  SharePoint 2013 comes packed with features.  I can see Dave’s feature matrix helping us prepare for that conversation with a customer who wants to know which are the most relevant to their needs.

Perhaps you will find it helpful as well.

Many Connection Types for the External Data Provider, there are – Blog Series Part 5

So you just finished reading all the ways the External Data Provider is THE Swiss Army knife of data integration. In closing up this Series, I’ll share some properties that can reside outside your individual connections (i.e. outside your <Data> elements) which we call the aggregate properties. A handy capability of the External Data Provider is that you can actually do mashups with it. It doesn’t provide all the feature/functions of the dedicated Mashup Adapter, but for quick & simple vertical mashups, it can often fit the need in short order.

To perform a “mashup” with the EDP, simply create a connection file that (a) has one or more connections set as the default and (b) has one or more connections with the same name. If both these conditions are met, the EDP will make all the connections listed and output their aggregate result as a vertical mashup.

In doing so, we’ve then provided some aggregate properties that you can set for the behavior/handling of the aggregate data returned. Many work just like the similarly named properties within a given connection type, they’re simply applied at the macro level. These properties are:

Property Name / Element

Property Use / Function

<AggregateOutputType> Default is “text/xml” however “text/html” & ”text/plain” are also supported.
<AggregateXSL> Actual XSL to transform the aggregate response from your Provider. However, it is recommended to use an attached stylesheet (see next property) as opposed to including your XSL in line here.
<AggregateXSLLocation> The URL to the location of an XSL stylesheet (can be .xml, .xsl or .xslt) to be applied for transforming the aggregate Provider response. This transform occurs *before* the data is rendered or passed on to another component.
<AggregateRedirectTo> The URL to redirect this connection to upon successful completion. This is the ability to take the aggregate response from your connections and instantly pass it into another to complete a process or validate a response. If you specify a parameter in the RedirectTo, you can pass the value of the initial connections using a pre-defined variable called %Data%.

Ex. http://site.net/subsite/providers/ADO.aspx?

ConnectionName=SecondConnection&FirstValue=%Data%

<CacheOutput> A true/false value indicating whether or not the aggregate output from this connection should be cached. If set to “true”, you can use the following three properties to customize the cache label and/or duration. Absent any of the following properties, the default label will be TheConnectionName+”Output”+WebPartID with a duration of 200 mins.
<CacheLabel> A text value to specify the aggregate cache label; if not specified, the default Web Part ID will be used for this portion of the cache identifier.
<CacheAddUserID> A true/false value indicating whether or not to add the ID of the user running the aggregate connections to cache label; this is akin to a cache per user mechanism. If set to “true” the User’s ID will be added to the end of the cache label.
<CacheDuration> An integer value indicating the aggregate cache duration in minutes.

And don’t forget the check out the other posts in this Series:

Many Connection Types for the External Data Provider, there are – Blog Series Part 4

The External Data Provider is THE Swiss Army knife of the Toolset. Sure it connects to your external data, but did you realize all the connection types it supports and the possible properties you can specify with each? During this blog series we’ll cover all the connection types, the properties associated with them and also provide examples for you to reference going forward. This article assumes you have seen a connection file before and understand its format of an opening & closing <CorasWorks> parent element with each connection being stored as a <Data> element within.

This final article in the series will cover two topics actually – the File connection type and the aggregate properties that can be used when “mashing up” data via the External Data Adapter.

A connection type of File, as the name implies, is for when you simply want to connect to a file containing XML data. If the file in question is in a web accessible location, this connection will actually work the same way as if you created an HTTP Post connection to the URL of the file. However, imagine a situation where you have an XML file on a network share. Perhaps you have some legacy or archived data; or it’s a secured application in where you only need periodic data dumps from a secured source you cannot or do not want to tap directly into.

With the File connection type, you can place that XML file on any network resource accessible (from the perspective of the SharePoint server) and pull it in as if it were any other connection type. Update the file in its location; see the results in your SharePoint applications.

The File connection type rivals the HTTP Post in its simplicity. A connection could be as basic as:

<Data>
<Name>YourConnectionName</Name>
<Default>True/False</Default>
<ConnectionType>File</ConnectionType>
<FileLocation>Path </FileLocation>
</Data>

Your path is then simply a URL, like in an HTTP Post connection, or it can be a UNC network path such as “\\ServerName\SharedFolder\MyXMLFile.xml”. Once you’ve connected to that XML file on your network or out on the web, you have the familiar properties from the other connection types available as well. They are:

Property Name / Element

Property Use / Function

<Values> The Values element simply holds empty child nodes representing each and every parameter that you wish to pass into this connection. Thus, if you plan to pass in a parameter called “Department” into your connection, you would need a self-closing <Department /> element inside your <Values></Values> elements. This is to let the connection know to look for a GET/POST param with the name specified. There’s no limit to the number of params.
<OutputType> Default is “text/xml” however “text/html” & ”text/plain” are also supported.
<XslStylesheet> Actual XSL to transform the response from your Provider. However, it is recommended to use an attached stylesheet (see next property) as opposed to including your XSL in line here.
<XslStylesheetLocation> The URL to the location of an XSL stylesheet (can be .xml, .xsl or .xslt) to be applied for transforming the Provider response. This transform occurs *before* the data is rendered or passed on to another component.
<ErrorRedirect> A URL to redirect a user/connection to when the connection called results in an error.
<ReportErrors> A true/false flag to indicate whether errors are reported. If set to “true”, and an <ErrorRedirect> is specified, the error message will be attached to the redirect URL as: ErrorRedirectURL?Error=(Error Message)
<RedirectTo> The URL to redirect this connection to upon successful completion. This is the ability to take the response from one connection and instantly pass it into another to complete a process or validate a response. If you specify a parameter in the RedirectTo, you can pass the value of the initial connection using a pre-defined variable called %Data%.Ex. http://site.net/subsite/providers/ADO.aspx?

ConnectionName=SecondConnection&FirstValue=%Data%

<RDConnection> The URL to pass the results of this connection into. This is different than a <RedirectTo> which literally forwards the request on to a new page/connection. With an <RDConnection>, the results of the first connection are passed into a second connection for use in processing said connection, and the results of the second connection are then returned to the first one. This is most useful when needing to send a collection of XML into a second connection since, with the RedirectTo, the entire response of the first connection is passed via query string variable; see the next property for setting the XML elements you wish to post into the second connection.
<RDConnectionPost> A property for specifying (via XPath) the XML results from your first connection that you wish to post into a second connection, as well as the parameter names to use when posting them. The <RDConnectionPost> also supports setting a default value to pass for a parameter, should the XPath for the parameter value not exist within the first connection’s result.
<CacheOutput> A true/false value indicating whether or not the output from this connection should be cached. If set to “true”, you can use the following three properties to customize the cache label and/or duration. Absent any of the following properties, the default label will be TheConnectionName+”Output”+WebPartID with a duration of 200 mins.
<CacheLabel> A text value to specify the cache label; if not specified, the default Web Part ID will be used for this portion of the cache identifier.
<CacheAddUserID> A true/false value indicating whether or not to add the ID of the user running the connection to cache label; this is akin to a cache per user mechanism. If set to “true” the User’s ID will be added to the end of the cache label.
<CacheDuration> An integer value indicating the cache duration in minutes.

And don’t forget the check out the other posts in this Series: