Transcript SharePoint Customizations: Solution Pathways and Approaches

Managing
2013 Apps for IT Pros
Presenter:
Al Carroll
May 15th 2013
Introductions
Ben Carroll
SharePoint Architect (and nice guy)
Email:
[email protected]
LinkedIn: www.linkedin.com/pub/ben-carroll/5/941/937/
(I would love feedback and questions/discussion via email)
CTN Dynamic is a Custom Support Organization.
CTN Dynamic provides support for Microsoft SharePoint, Dynamics CRM, and GP
platforms, to companies of all sizes. Our team of Level 3 Application Support Architects
provides each of our customers with dedicated support of their specific environment with
measurable SLAs.
http://www.ctndynamic.com
Audience Poll Time
Agenda
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Overview
Where Apps fit in the SharePoint 2013 Customization Pathways?
Apps Architecture
Planning for Apps
Apps Development
App Environment Configuration
App Security
Data Storage and Access with Apps
Monitoring Apps
Demo
Questions
Overview
It’s all about the Apps (..almost)
SharePoint 2013 Apps
Overview
 Apps are secure, with permissions independent of user permissions
 Lower risk than farm and sandbox solutions since app code never runs in a
SharePoint Host Environment
 Easy to deploy, monitor, find, upgrade, and retire.
 Site owners can discover and download apps for SharePoint from a public
SharePoint Store or from their organization's internal App Catalog and
install them on their SharePoint sites.
 Not a complete replacement SharePoint features and solution packages
but provide pathways for a majority of scenarios where we would've used
the former.
 Simple lifecycle – Apps can be installed, upgraded, and uninstalled by site
owners.
 Integrate with Office Apps
 Not available in SharePoint Foundation 2013
App User Experiences




Immersive Apps
Part Apps (App Parts)
Custom Action Apps
Branding and UI Integration
 App Templates: pull CSS from hosting SharePoint
Environment when creating Visual Studio Apps
 Chrome Control – JavaScript based control which
allows for consumption of styling of the parent
AppWeb
The App Store
 Microsoft hosts and controls a public
SharePoint Store.
 Developers can publish and sell their custom
apps.
 End users and IT professionals can purchase
apps for personal or organizational use.
 This SharePoint Store will manage discovery,
purchase, upgrades, updates, and dispute
resolution.
 Company-developed and approved apps can
also be deployed to an organization's
internal App Catalog hosted on SharePoint
2013 or SharePoint Online
Advantages of Apps
 Advantages to Users



Apps are available through the App Catalog or App Store
Provide easiest discovery & installation without intervention of SharePoint Admins
Apps provide upgrade support
 Advantages to Administrators



Less risk than Sandboxed or Farm Solutions since they execute outside the server.
Apps are Configurable by Administrators allowing them to restrict usage of Apps
Scale App Components rather than SharePoint when appropriate
 Advantages to Developers





Web Programming skills are reusable in creating Apps
Common web standards of HTML, JavaScript, CSS can be used to develop Apps
Visual Studio 2012 supports App project templates
Like Sandboxed Solutions, developers can access SharePoint objects inside Apps
Opportunity to create & publish Apps to SharePoint store
How are apps for SharePoint and
SharePoint sites related?
 Site owners can add apps for
SharePoint to their sites.
 App containing SharePoint
components, store those
components in a subweb of the site
that is automatically created upon
app installation.
 Apps have their own, isolated URLs,
separate from the URL for the site
containing the app.
 If the app is a Provider-hosted then
components are stored in the in the
cloud.
Where are Apps hosted?
 Provider-hosted

HTML and JavaScript hosted by SharePoint Environment of Provider
 Hosted in the cloud (Windows Azure auto-hosted)
 Hosted in a SharePoint environment
 Several combinations of these options.
What is the URL for an app for
SharePoint?
 Apps by default are deployed to their own web site in an isolated domain
name, separate from your farm, thus are unable to affect your SharePoint Sites.
This prevents cross-site scripting between the apps and sites and unauthorized
access to data.
 Each app install has a unique URL in your SharePoint environment. You
determine the template for that URL by specifying a domain name and an app
prefix, and then app URLs are automatically generated based on that template.
 Paths for the apps are based on the URL for the site where they are installed.
Upon app installation, a subweb of that site is created to host app content. The
subweb for the app is hierarchically below the site collection, but has an
isolated unique host header instead of being under the site's URL.
Impacts of apps for SharePoint
Supporting apps for SharePoint in your environment does require
configuration changes to your environment. There are two main
considerations:
 Requirements for supporting apps for SharePoint
 Subscription Settings and App Management service applications must be
running.
 A DNS domain to contain the URLs for apps for SharePoint in your
environment must be created.
 Plan for capacity Each app for SharePoint creates a subweb
under the site on which it is installed with its own URL.
Environments with lots of apps have lots of subwebs. Keep this
in mind during capacity planning
Where Apps fit in the SharePoint
2013 Customization Pathways?
Custom Development Directions
 Farm Solutions
 Sandbox Solutions
 Apps
IT Pro Challenges with SharePoint
Solutions
 Custom code running inside your SharePoint
environment – risk and scaling challenges
 DLL Dependency – futureproofing/migration
challenges
 Solution Permissions based on user identity –
authorization challenges
 Not so easy to install and upgrade – Pain in the
Admins never you mind just where..
Apps compared to Sandbox
Solutions
 Microsoft wants you to use App Model to most places where you would’ve
used Sandbox Solutions.
(Pssst… Hey buddy…. sandboxes are deprecated going forward)
 App solutions can be used to deploy declarative SharePoint Objects like




lists
Apps can’t do everything that farm and sandbox solutions can, but there
are workarounds for many scenarios. (more on that in another slide..)
You will have to use solutions in some cases. Content type or list template
available to an entire site collection would require a sandbox solution
Apps can include SharePoint Solutions but NOT server side code.
Shiny new things in Apps that aren’t in Sandbox Solutions


App Marketplace
Oauth support
When to use Apps vs. Farm Solutions
There is overlap between the two due to the evolution of SharePoint
Farm solutions
 installed by farm admins with farm, web
application, or site-collection scope, and can
access the server object model and run code on
the SharePoint Server.
 Server object model has APIs enabling
SharePoint management, configuration, and
security, including extending Central
Administration, backups, timer jobs, and
PowerShell.
 allows manipulation of SharePoint components
and end user features, but in SP2013 the design
intention is to use apps unless a single solution
requires both administrative and end user
functionality.
Apps
 use one of the SharePoint client object models
or REST endpoints to access SharePoint
content and components. These client APIs
are designed for end user functionality, (site
owners, site members, and tenant admins).
 Apps can be installed by tenant and site
collection administrators.
 Since SharePoint Apps are website scoped
and cannot include custom code that runs on
the SharePoint server, it cannot call
administrative APIs.
 In general use apps for end users functionality
and farm solutions for administrator
functionality.
App Approaches to Pre-App
Scenarios
Custom server side code running on the SharePoint servers is not allowed in SharePoint 2013
Apps, which at first glance may appear to be a big limitation BUT we can just move business
logic to the client or the cloud and accomplish MOST of what you would’ve done with server
side code.
 Use SharePoint’s REST/OData service for accessing SharePoint lists and data.
 Access SharePoint data remotely via JavaScript, .Net Client Object Model, or Silverlight OM.
 Where you would’ve created web parts in SP2010 – SharePoint apps can include remote
pages with custom Web Parts or surface a page from a remote web application in an app
part on a SharePoint site page. The remote page will have the same look and feel as a Web
Part.
 An app for SharePoint can contain remote event receivers that provide the same
functionality as Event Receivers and Feature Receivers.
 Custom web services can be created as remote services.
 Apps can include remote web pages that can use built in SharePoint web parts. These
pages are available from every website where the app is installed and function like
Application Pages.
Apps Architecture
Tenancies and App Scope





“A SharePoint 2013 tenancy is a set of site collections in either a SharePoint farm or in SharePoint Online.
In SharePoint Online, the site collections belong to a single customer account. In a SharePoint farm, the
site collections can be all the site collections in a SharePoint web application or a subset of them, or it
can be a set of site collections from across multiple web applications in the farm. A tenancy can have an
app for SharePoint app catalog just as a SharePoint web application can.” -- technet
An app for SharePoint has an app scope of WEB or TENANT. The difference is not an intrinsic property of
the app and developers do not decide what the scope of their app has. The decision is made by tenant
administrators based on how the app is installed.
Web Scope: After an app is uploaded to the App Catalog of a tenancy, it is available for installation sites
within the tenancy on a website-by-website basis. Apps that are installed this way have web scope.
Tenant Scope applies to apps, batch installed to a subset of websites within their tenancy by Tenant
administrators. The tenant admin can specify which websites the app is installed to, through a list of
managed paths, site templates, or site collections.
If an app that includes an app web is batch-installed, only one app web is created and it is shared by all
the host websites on which the app is installed. The app web is located in the site collection of the
corporate app catalog.
Tenancies and App Scope..
Site-Scoped (Web Scoped)
• App installed in specific site
• App launched from same site
• Site is called Host Web
•
•
Tenancy-scoped
•
•
•
•
App installed in app catalog site
App available to multiple host webs
Host webs access one app instance
Centralized app management
Typical farms do not have explicitly created tenancies. On-premise farms
can be configured with a farm-wide tenancy default.
Apps that contain a custom action for the ribbon or app parts can’t be
batch installed. Custom actions that are deployed as menu items are
allowed.
Hosting
Cloud hosted apps include at
least once component that is
hosted outside of the
SharePoint farm, but they may
also include SharePoint-hosted
components. We break this
down into Auto-hosted and
Provider-hosted
SharePoint-hosted –Apps include only SharePoint
components and logic that runs on the client.
There are no external components and all
components of the are contained within a special
App Web. The app is installed on an existing site,
but it actually runs from and stores all its data
within this App web, which is a sub site of the site
where the App is installed. No server side code is
allowed for SharePoint-hosted apps, only
JavaScript calls between the client machine and
farm.
Azure Auto-hosted Apps include a Windows Azure Web site, and
possibly a SQL Azure DB automatically provisioned transparent to end
user when an app is installed. Azure Web Sites infrastructure manages
isolation of tenancies. You don’t have access to all Azure services like
Media Services or Service Bus
As with provider-hosted apps, auto-hosted apps can have SharePoint
components stored in the optional app web too.
Provider-hosted (developer hosted) apps are hosted by the
provider /developer, or even on your own separate hardware (this
could be in the cloud). Data storage , business logic, and account
isolation is up to the provider or developer, Apps can have SharePoint
components too, stored in an optional app web hosted in the
SharePoint farm. Provider-hosted apps provide lots of flexibility, for
example being able to use any platform and programming language for
your application – even non-Microsoft.
App Webs, Host Webs, Features, and
SP Components in Apps
 Host Web is the website where an app for SharePoint is installed. However, the
significant parts of the app for SharePoint, whether they are SharePoint components
or external components, are not deployed to the host web. External parts are
deployed to external servers or cloud accounts.
 App Web is a special SharePoint Site where an App’s SharePoint components are
deployed and has its own domain.
 A limited set of UI elements allow users access to the app's other components and
are deployed to the host web as a Host Web Feature.
 Host Web Features are in the root app package’s XML Hierarchy instead of inside a
.wsp file. Components deployed to the app web are in Features within a .wsp file.
Both types of Features must have Web scope. Only these two types are allowed.
 Most SharePoint component that don’t include server side code running on
SharePoint servers can be included in an app and deployed to the app web.
App Packages
 An app for SharePoint package is essentially cab file
with an ".app" extension, containing an app manifest.
 App Manifests set app properties and provide
SharePoint with installation instructions.
 App Packages meet the Open Packaging
Conventions (OPC) standard.
 You can open the file by adding a ".zip" extension on
the filename and then opening it in Windows
Explorer or with winzip.
App Permissions






Apps that use an App web, the App will have full control rights to the App web, so it will only need to
request and have permissions assigned to resources in the Host web or other locations outside the App
web.
Apps use permission requests to specify the permissions that are needed at a particular scope. There are
different scopes that can be specified for content and in addition to these, there are also scopes for items
such as performing search queries, accessing taxonomy data, and microfeed activities.
App permission rights indicate the activities that an app is permitted to do within the requested scope
which are also detailed in the article referenced above. Unlike SharePoint user roles, these rights levels are
not customizable.
Users installing apps must have full permissions on the Host web that an App is requesting. On
installation the user will be notified as to what permissions the App requires.
Selective delegation and authorization Neither users launching an app, nor resource owners granting an
app permission to access resources, have to give an app their username or password. SharePoint 2013 use
OAuth so users and resource owners to grant only the specific permissions that the app requests.
Cross-domain access: An app for SharePoint that includes a remote web application that uses JavaScript
for its data access logic can use a JavaScript cross domain library to get authorized access to SharePoint
data within the tenancy where the app is installed.
Service Applications
 Two service applications required for apps
o App Management Service
o Site Subscription Management Service
 These must be created in on-premise farms for apps
to work
Planning for Apps
Plan App Configuration Settings
 You must explicitly configure your environment to allow apps or site owners will
receive error messages when they attempt to install apps.
 SharePoint apps require set up of a Domain Name Services (DNS) domain name to
provide a host name for installed apps. The separate domain name, keeps apps for
SharePoint separate from SharePoint sites, preventing unauthorized access to user
data and reducing the possibility of cross-site scripting attacks.
 Apps have unique URLs, consisting of the app domain plus a prefix and an Apphash.
The format is: prefix-Apphash.domain.com.
 Apphash is an arbitrarily-assigned unique identifier for each app for SharePoint. The
App URLs are automatically created based on developer specifications.
 You do not have to create or manage these URLs separately; instead you configure a
wildcard entry in DNS to provide the URLs for all apps.
 In multi-tenancy environments, admins must use the Set-SPAppDomain PowerShell
cmdlet to configure the URL and prefix.
Plan DNS
 App Isolation is using separate URLs for SharePoint apps and sites.
 DNS records are required in order to correctly resolve the domain name.
 Create one of two of the following types of DNS records for app for SharePoint
URLs:


A wildcard Canonical Name (CNAME) record that points to the host domain assigned to the
SharePoint farm.
A wildcard A record that points to the IP address for the SharePoint farm.
Plan SSL
 “Secure Sockets Layer (SSL) is a requirement for web applications
that are deployed in scenarios that support server-to-server
authentication and app authentication. ….. As a prerequisite for
configuring Task Synchronization, the computer that is running
SharePoint Server must have SSL configured.” -http://technet.microsoft.com/en-us/library/jj554516.aspx
 The above sort of means if you want apps and app security you
need SSL. The app model uses OAuth access tokens. These tokens
contain user and app identity info which it’s safer to encrypt in
order to prevent that info being intercepted by a sniffer and used
to penetrate resources..
 Using SSL means that you must create a wildcard certificate to use
for all app URLs.
Domain Names and Prefixes
App Domain should be in the Internet or Restricted sites security zone in Internet Explorer
“..we recommend that you configure the app domain to be in either
the Internet or Restricted sites security zone in Internet Explorer options, and not in
the Intranet zone or Trusted sites zone. Internet Explorer security settings for
the Intranet zone or Trusted sites zone do not provide a sufficient level of isolation of apps
from user data in SharePoint sites.” --Technet
In general use unique domain names and avoid subdomains
If you use a subdomain then potentially malicious code could read or set cookies.
Host Headers
 Microsoft recommends a best practice of using a single web
application with host headers rather than multiple web
applications with path-named site collections in your
environment.
 When you use multiple web applications and path-named site
collections you might have to complete additional
configuration steps to guarantee that requests for apps for
SharePoint are routed to the correct web application.
Plan The App Catalog & Store
 The SharePoint Store is accessible to the general public. On Premise Farm
Admins can configure whether users can purchase from the store.
 App Catalog - If you allow apps, you can configure a special site that contains
the apps for SharePoint that site owners can install.
 Farms can support multiple App Catalogs, one per web application. To
configure a web application’s App Catalog, you supply names of the site
collection admins who will have approval rights. The admins can then upload
apps into the AppCat.
 The App Catalog can be accessed from a link in Central Administration
or directly by using the URL.
Plan Monitoring Apps
 Farm Admins can monitor apps usage and errors by adding apps to the Monitor Apps page in
SharePoint on-premises.
 The maximum number of apps that can be monitored on the Monitor Apps page is limited to 100.
 The Monitor Apps page requires search analytics and usage file import timer jobs to be running:
 ECM analytics timer job name: Usage Analytics timer job for Search Service
 Usage DB timer job name: Microsoft SharePoint Foundation Usage Data Import
Plan for app licenses




SharePoint 2013 does not enforce app licenses. Developers who build apps must add code that
retrieves license information and then addresses users appropriately.
SharePoint 2013 provides the storage and together with SharePoint Store web services the app
license renewal.
SharePoint Store handles payments for the licenses, issues the correct licenses, and provides the
process to verify license integrity. Note that licensing only works for apps that are distributed through
the SharePoint Store. Apps that you purchase from another source and apps that you develop
internally must implement their own licensing mechanisms.
SharePoint 2013 supports the following app licenses formats:
License Type
Duration
User Limit
Free
Perpetual
Unlimited
Trial
30, 60, 120 Days, or Unlimited
Number per user or Unlimited
Paid per user
Perpetual
Number per user
Paid unlimited users (site license)
Perpetual
Unlimited
Plan for App Governance
Some basic governance questions regarding apps:
 Should site owners to be able to install and use apps for SharePoint at all?
 In which environments (intranet, extranet, or Internet) should apps to be
available?
 Do you want to restrict or control the apps for SharePoint that site owners can
install and use?
 Do you want to control who can purchase apps for SharePoint?
 Do you want to control who can install apps for SharePoint?
 Do you want to provide specific apps for SharePoint in your environment?
 Do you want apps for SharePoint from your own organization added to the
App Catalog.
 What apps do you need SharePoint to monitor? (Apps are not monitored by
default.)
Plan for App Permissions
 App Permissions manage app’s ability to access and use internal
SP2013 resources and perform tasks for users.
 SharePoint 2013 uses the Windows Azure Access Control Service
(ACS) to issue time- and scope-limited access tokens for apps. In
SharePoint, ACS is the app identity provider.
 App Authentication verifies a claim that an app makes and
asserts that the app can act on behalf of an authenticated
SharePoint 2013 user.
 App Authorization verifies that an authenticated app has
permission to access a specified resource and perform a defined
action.
 Admins can allow a SharePoint 2013 site owner, or user with
elevated permissions, to purchase and install an app that a
defined set of internal SP2013 users can access.
App permission rights
•
•
•
•
Read
Write
Manage
Full control
App permission
request
•
•
•
•
Tenancy
SPSite
SPWeb
SPList
App permission request scopes
 SharePoint 2013 apps use app permission request scopes and
permission requests to specify the level at which the app is intended to
run, and the permission level that is assigned to the app.
 SharePoint 2013 supports the following permission request scopes:




SPSite Defines the app permission request scope as a SharePoint 2013 site collection.
SPWeb Defines the app permission request scope as a SharePoint 2013 web site.
SPList Defines the app permission request scope as a SharePoint 2013 list.
Tenancy Defines the app permission request scope as a SharePoint 2013 tenancy.
URI
http://sharepoint/content/sitecollection/
http://sharepoint/content/sitecollection/web
http://sharepoint/content/sitecollection/web/list
http://<sharepointserver>/<content>/<tenant>/
App Permission Inheritance
 Apps follow familiar SharePoint Permissions Inheritance. If an
app is granted permission to one scope, the permission also
applies to the children of that scope. If an app can access a Site
then it can access children of the site such as its lists and
libraries.
 Since Apps don’t know the topology of site collections from
which they request permissions, the scopes are expressed as a
type and URI rather than as the URL of a specific instance.
Content database related permissions are organized under this
URI: http://sharepoint/content.
App authorization policies
SharePoint 2013 provides the following app authorization policies:
 User and app policy authorization succeeds if both the current user
and the app have permissions to perform the actions that the app is
attempting.
 App-only policy authorization succeeds if app has sufficient
permissions, regardless of user permissions. This is required when the
app is not acting on behalf of a user.
 User-only policy authorization succeeds if the user has sufficient
permissions to perform the action that the app is designed to perform.
The user-only policy is required when a user is accessing their own
resources..
App Development Environments
and Deployment
SharePoint 2013 Developer Tools
 Napa
 Visual Studio 2012
 SharePoint 2013 Designer
Napa - Not just a tasty
vegetable..
 Essentially a cloud or browser IDE and simplified
browser version of Visual Studio
 Office 365 Developer Sites have unlimited license
 One way “upsizing” to Visual Studio 2012
 Does not support code behinds
 Client side code only
SP 2013 Deployment Options
 On-Premise
 Installed on your hardware
 Access to all of SharePoint’s features
 Hosted
 Installed 100% in the cloud usually on Office 365
 Feature set is limited
 Hybrid
Languages and Environments for
Apps Dev
 Languages
 Client side JavaScript for SP-Hosted Apps
 C# and VB.NET for Provider or Autohosted Apps
 Local Development Environments
 For SharePoint Hosted: Napa within Office 365
 For Provider or Autohosted: Visual Studio 2012, Office,
SharePoint Designer
 A setup guide for development environments
 http://blogs.technet.com/b/wbaer/archive/2012/10/10/setting
-up-a-sharepoint-2013-development-environment-101.aspx
Distribute with App Packages






Apps distributed using app packages
 Package is a .zip file with .app extension
 Built according to Open Package Convention (OPC) Standard
 Same format used for Office Apps
 Must contain AppManifest.xml
Package contains inner WSP for app web
 Elements deployed to app web using solution package
 Solution package built into app package as inner WSP
 Cloud-hosted apps will not have an inner WSP unless they are implemented to create an app
web
Visual Studio then generates the needed files to publish an app for SharePoint. Developers can find
your deployment package in the app.publish\version folder of your projects output folder.
The folder will contain a single .app file for the application
Cloud based apps will also have any other files required for the app.
Autohosted and provider hosted apps will include files that need to be published in the host web
application.
App Packaging and Deployment
Developer
App manifest (.xml)
or .app package
Document
Sharing
Office Store or
App Catalog
Web Page
Consumers &
Corporate Users
Web Server
(Internet or Intranet)
Packaging for Host Web and
Autohosted Apps
 Host web feature elements added at top level
 Elements.xml file for each app part, custom action, and host
web feature
 Visual Studio adds GUID to file names
 Autohosted apps packaged with extra resources
 Office 365 requires resources to deploy remote webs be built
in the app package as a Web Deploy Package (.web.zip)
 Office 365 requires resources to create SQL Azure DB within
app package as Data Tier Application Package (.dacpac)
Registering App Dependencies


If your app is dependent on a SharePoint capability that’s unavailable and cannot be made
available on the app web, then it won’t work.
Developers can ensure that your app is not installed where the requisite services and Features
are not available by registering the dependencies of the app in app manifest. The installation
infrastructure for apps for SharePoint checks for prerequisites and will block app installation if any
are not available.





For services, such as Excel, Access, or Visio services, the infrastructure will verify that the service is installed and licensed.
For Features, such as a Task list, the infrastructure will verify that the Feature is deployed and activated or activatable with Web
Scope on the App Web
Implicitly register dependencies with permission requests in
the AppPermissionRequests section of the app manifest.
Explicitly register dependencies with AppPrerequisites when your app has a dependency that
is not implied by its permission requests, you register each dependency with
an AppPrerequisite element in the app manifest. There are three attributes in this
element; Type, ID, and an optional MinimumVersion.
If your developers forgot to do this or are unaware then this should be one of the initial places you
point them when they complain that you have the environment configured incorrectly. Then make
them buy you lunch.
Register autohosted components
 AutoProvisioning is a type of app prerequisite used only with autohosted apps.
It registers components of the app that need to be autohosted. When
prerequisite type is AutoProvisioning, the ID attribute is not a GUID. Instead, it is
one of the following:


“RemoteWebHost” (To register a Windows Azure Web Site.)
“Database” (To register a SQL Azure.)
 “Autohosted app that include Windows Azure Web Site and a SQL Azure
database, get a separate AppPrerequisite element for each respectively. The
following markup registers both:

<AppPrerequisites> <AppPrerequisite Type=”AutoProvisioning” ID=”RemoteWebHost” />
<AppPrerequisite Type=”AutoProvisioning” ID=”Database” /> </ AppPrerequisites>” --MSDN
Update Your App




The App framework in SharePoint 2013 enables preservation of the app’s data and roll
back if an update fails.
To update apps, developers use the same Product ID in the app manifest that was used for
the original deployment. The version number should be greater than the version currently
deployed.
Once an app is updated, a notice that an update is available appears next to the app’s
listing in the Site Contents page of every website where the app is installed.
SharePoint’s Upgrade Actions:





Prompt the user to approve any changes in the permissions requested by the app.
Makes the app temporarily unavailable to users while the app is updating.
If the app is autohosted and includes a SQL Azure database, the update process will use the Data-Tier Application
Package (DAC) functionality of SQL Server to determine whether the update changes the schema of any SQL Azure
databases.
It is not possible for SharePoint 2013 to make every kind of schema change. If you have schema changes in your app, it
might be necessary to include that logic in one of four places
 In a Data Script inside the app package.
 In a PostDeployment script in the DACPAC that is executed as part of the DAC upgrade.
 In the PostUpdate web service , which you would create and register in the app manifest.
 In the first run after update logic of the app itself.
If the app is provider-hosted, the developer provides the update logic for all of the nonSharePoint components so that a rollback can take place if the update installs.
App Environment Configuration
App Configuration Cheat Sheet from
Microsoft
Image from Technet: http://technet.microsoft.com/en-us/library/fp161236.aspx
DNS and SSL
 Once the App domain is determined, it will need a DNS record. Since all App
webs have a unique host name, a wildcard DNS entry is required, otherwise, a
new entry in DNS would be required for every App instance which would be a
scalability and manageability issue. You also can’t determine an App ID prior to
creating an App.
 Depending on your configuration (for example, if you are using WINS forward
lookup), you might have to create a new forward lookup zone first, or you can
start with a wildcard CNAME entry in the same zone as the SharePoint site
domain.
 If you are using SSL for SharePoint, or if you use any apps that use data external
to the SharePoint sites, you should use SSL for your apps also. To use SSL, you
create an SSL certificate for your app domain (for example, ContosoApps.com).
Farm Configuration
 Create SharePoint Service Applications and enable services


The Subscription Settings
The App Management service application
 Configure App settings in SharePoint



App prefix and App domain for the farm;
specifying the location of the App Catalog,
configuring Store settings such as whether users can install Apps from the Office
Marketplace.
Internet-facing endpoints
The SharePoint Store contains apps for SharePoint intended for
use with sites that require Internet-facing endpoints. Such apps
are made unavailable for purchase by default since they are
incompatible with most sites.
For farms configured to allow internet-facing end points,
Administrators can activate the Internet-facing endpoints feature
to show these apps in the SharePoint Store. You turn this feature
on in Central Administration | Application Management |Manage
Web Applications.
App Authentication Config Overview
 Cloud-hosted Apps require configuration in order to work
with our on-premise SharePoint 2013 deployments since
externally hosted Apps need to access SharePoint’s data.
Since trusts aren’t going to be in place by default we
need to explicitly configure them.
 SharePoint 2013 uses OAuth to establish ‘trust’ enabling
users to grant a third-party site access to SharePoint’s
data, without providing a user name and password and
without sharing all of its data. In SharePoint 2013, OAuth
is used for Apps that fall in two differing scenarios which
are known as “low-trust” and “high-trust.”
Low and High Trust Apps
Configure SharePoint for low-trust Apps


Low-trust Apps use an authentication provider as a common authentication broker (trust broker) between
the app and SharePoint. This will be Windows Azure Access Control Services (ACS) and requires an Office
365 subscription.
With ACS, SharePoint requests a context token that sends to the location hosting the App. The App then
uses the context token to request an access token from ACS. Upon receipt, the App uses the token to
communicate back to SharePoint.
Configure SharePoint for high-trust Apps






High-trust Apps are those not using ACS as the broker, so therefore no context token.
A Certificate establishes trust and generates your own access token by using the server-to-server security
token service that is part of SharePoint 2013. This is also called server-to-server(S2S) trust relationship and
is between the SharePoint farm and the App.
S2S for each high-trust App that uses different certificates which a SharePoint farm must trust.
High-trust <> "full trust", and such apps still need to request App permissions. The app is considered
high-trust because it is trusted to use any user identity that the App needs, since the App is responsible for
creating the user portion of the access token.
When an App is not SharePoint-hosted and requires server-side processing, this is the recommended
approach in-house apps should take in most cases.
Configuration of this trust is performed primarily via Windows PowerShell for on-premise deployments
and is detailed in MSDN: http://msdn.microsoft.com/en-us/library/fp179901.aspx
Configure app requests and
SharePoint Store settings
• Farm admins determine if users can purchase apps from the SharePoint Store. This is scoped
at the web application level.
• When users request an app for SharePoint from the Store, they can request a the number of
licenses and give a justification for the purchase. Requests are added to the App
Requests list in the App Catalog of the web application. App Request include:
•Requested by The user name of the person requesting the app for SharePoint.
•Title The title of the app for SharePoint.
•Seats and Site License The number of licenses the user requested for that app for SharePoint.
•Justification The reason why the app for SharePoint would be useful for the organization.
•Status By default, the status is set to New for new requests. The person who reviews the request can change the status
to Pending, Approved, Declined, Withdrawn, Closed as Approved, or Closed as Declined.
•View App Details A link to the app details page in the SharePoint Store.
•Approver Comments The person who reviews the request can add comments for the requestor.
• If users cannot purchase apps, they can still browse the SharePoint Store, and request an app.
Farm administrators and the App Catalog site owner can view and respond to app requests.
App Security
Authentication options for
SharePoint Apps
Inside SharePoint
Must use HTML and JavaScript and SharePoint handles the
authentication
In The Cloud
Client side code and cross-domain library
OR server side code and Oauth
REST APIs
Authentication Pieces Relevant to
Apps
Claims
• New and improved and the default for new web applications.
• Need to use PowerShell to create classic mode web apps. CA doesn’t
provide a way to do it.
• Required for some new features including Apps
OAuth 2.0
• SAML claims limitations (ADFS 2.0)
User Profile Application
• For some claims scenarios like Server to Server with Exchange or Lync.
Distributed Cache
• Caches login tokens
From: http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-25-31metablogapi/6840.image_5F00_68B8261A.png
OAuth Flow
OAuth enables users to authorize the service provider (in this case,
SharePoint 2013) to provide tokens like usernames and passwords
instead of credentials, to their data that is hosted by a given
service provider (that is, SharePoint 2013). Each token grants
access to a specific site and resources for a defined period. This
enables a user to grant a third-party site access to information that
is stored with another service provider without sharing their user
name and password and without sharing all the data that they
have in SharePoint.
When is using OAuth required?
The OAuth protocol is used to authenticate and authorize apps and
services. If you plan to build an app for SharePoint that runs in a
remote web application and communicates back to SharePoint
2013, you will need to use OAuth. The OAuth protocol is used:
• To authorize requests by an app for SharePoint to access
SharePoint resources on behalf of a user.
• To authenticate apps in the Office Store, an app catalog, or a
developer tenant.
OAuth for cloud-hosted Apps
7 – Access
token
2 – Request
context
token
3 – Signed
context
token
6 – Access
token
request
1 - Request
8 – Request +
access token
4 – Page +
IFRAME
9 – SharePoint data
5 – Request page + include context token
10 – IFRAME contents
App Rights
 Set App Rights upon app installation
(Read/Write/Manage/Full Control). Rights are granted
rights explicitly by Tenant Admin or SPWeb Admin
 End Users are prompted to give consent before App
accesses their user data
 Once provisioned, app rights can’t be modified, but you
can revoke them in whole.
 Remember that permissions of parent objects are
inherited by children by default.
For a detailed walk through follow Josh Gavant’s Blog:
http://blogs.msdn.com/b/besidethepoint/archive/2012/12/10/sharepoint-low-trust-apps-for-on-premises-deployments.aspx
OAuth in SharePoint low-trust apps
SharePoint low-trust apps rely on the OAuth authorization code flow to delegate limited rights to
apps to act as users. For this to work, both SharePoint and the Client application (SharePoint app)
must trust and communicate with an Authentication Provider. SharePoint relies on Azure Active
Directory. Azure AD, must be aware of SharePoint and the Client app in order to grant them codes
and tokens to work together.
Connect SharePoint to Azure Active Directory





Replace the local STS signing certificate with one Azure AD can trust. Use a self-signed cert or one
from a trusted global authority. Associate the cert with the SharePoint principal in Azure Active
Directory.
Create an SPN for the OnPrem SharePoint farm and add it to the SharePoint principal in AAD.
Configure the authentication realm for the local SharePoint farm to match the AAD realm.
Create an Azure Access Control Service application proxy in SharePoint.
Create a Trusted Security Token Service for Azure ACS in SharePoint.
Create App Principals

We’ve connected SharePoint to AAD, but to use it, we need to create AppPrincipals in Azure Active
Directory and SharePoint. These AppPrincipals represent the remote-hosted Web Applications which
will connect to SharePoint acting as users. Azure AD needs to be aware of these principals to be able
to issue authorization codes for them and access tokens to them. SharePoint needs to be aware of
them to allow them access on behalf of users.
Server to Server (S2S) Trust
What is a High-Trust App?
 It is provider-hosted app for on-premise environment use and not proposed for
cloud-hosted environment. It uses server-to-server protocol to create “High-trust”. It
is considered “high-trust” because it is trusted to use any user identity that the app
needs, because the app is responsible for creating the user portion of the access
token.
 A high-trust app uses a certificate instead of a context token to establish trust.
 Apps that use the server-to-server protocol would typically be installed behind the
firewall in instances that are specific to each individual company.
How to configure server-to-server high-trust?
 Create and export a certificate by using Create Self Signed Cert in IIS
 Include ClientSigningCertificatePath and password for the .pfx fiel in the web.config
of the app
 Select the new cert and close the Details tab. Click Copy To File in button in dialog.
Follow steps of the Certificate Export Wizard and do not select radio button for
export private key when asked.
 Configure SharePoint 2013 to use high-trust apps
Pre-requisite : you should have configured the App isolation for on-premise
environment at this point.



the app management service and user profile application should be started and running
at least one profile is created in the User Profile Service Application as follows
Use PowerShell Script to create a trusted security token issuer based on public key
On-premises Farm
S2S STS
1
3
4
2
SSL Cert
Public/Privat
e key pair
(.pfx)
Server to Server (S2S) Trust..







(1) get appId $appId = your app id (Guid) here. All letters of the client-id must be of
lowercase.
(2) get spweb where you want to deploy your high-trust app $spurl
="http://yoursharepointSite" $spweb = Get-SPWeb $spurl
(3) Get the current authentication realm for your SharePoint site $realm = GetSPAuthenticationRealm -ServiceContext $spweb.Site
(4) Get the corresponding file to the .cer file you are using for the app => the one we just
created in step-1 $certificate = Get-PfxCertificate $publicCertPath
(5) Get the app Id together with the realm value. $fullAppIdentifier = $appId + '@' + $realm
(6) Create a trusted security token service. This basically fetches metadata from your app
and establish trust with it, so that SharePoint 2013 can accept tokens that are issued by your
app. New-SPTrustedSecurityTokenIssuer -Name "High-Trust-App-Name" -Certificate
$certificate -RegisteredIssuerName $fullAppIdentifier
(7) Register the app principal with the app management service, so you can grant app
permissions. $appPrincipal = Register-SPAppPrincipal -NameIdentifier $fullAppIdentifier -Site
$spweb -DisplayName "High-Trust-App-Name"
Data Storage and Access with Apps
Connectivity Options
 Authenticating with SharePoint from your remote app


OAuth
Cross-domain Library
 Accessing data from SharePoint from your remote app


JavaScript or .Net client object models
REST Services



Web proxy
Remote Event receiver
Cross-domain library with a custom proxy page
 Accessing data in your remote app from SharePoint
 Each of the above three approaches require use of the available APIs in the remote
app to access it’s data
 These are developer tasks but mentioned here so IT Pros can be aware of which
libraries developers may be leveraging in your farms.
Overview of app-scoped external
content types in SharePoint 2013
 App-scoped external content types provide access to external data within
an app.
 SharePoint 2010 allowed external content types but only at the farm level.
This could be an implementation bottleneck since developers needed
administrator involvement due to the farm level access rights needed.
 SharePoint 2013 apps can access external data such data without involving
tenant admins.
 Access to external applications is still maintained through Business
Connectivity Services (BCS)
 In order to access data on a secured external system, you must configure
the BDC model with the appropriate credentials. (fun with XML :)
App Data Storage Options
 Structured Data

SharePoint Apps can use a wide range of structured data storage not limited to SharePoint Data. This
list includes but is not limited to:





SharePoint lists in an app web
SQL Azure
External data sources connected to SharePoint with Microsoft Business Connectivity Services (BCS)
non-Microsoft cloud services
database in your own environment
 Unstructured Data




Document Libraries
Site Libraries.
blob storage in your Windows Azure account or on your own servers. (Windows Azure blob storage is not an option for autohosted apps.)
Some non-Microsoft platforms or cloud services.
 Metadata and App Settings

Metadata for an app for SharePoint, such as user preferences, location information, and other settings can be stored in several places. A hidden
SharePoint list is sometimes a good choice. You can also use the property bag of the app web. Another option, for a provider-hosted app, is to
use Windows Azure Table storage. (This is not an option in an autohosted app.)” --Technet
Monitoring Apps
Monitoring and logging
Monitoring in
Central Admin
• App usage/Error details
• Timer Jobs
Monitoring in
Site Collections
• App usage/Error details
What gets
logged?
• App Management, App Monitoring,
Azure Access Control, App Marketplace,
Marketplace Web Service
Monitoring app details in Central
Administration
 There are multiple ways that an administrator can view the error
and usage details for apps for SharePoint. By selecting an app in
the Monitored Apps page, an administrator can use the ribbon to
access the error or usage details for that app. OR click an app in
the list on the Monitored Apps page to open the app details page
and access the same error or usage details.
 Each app for SharePoint provides the following properties: Name,
Status, Source, Licenses in Use, Licenses Purchased, Install
Locations, and Runtime Errors. A Farm Administrator chooses to
add, remove, and monitor apps for SharePoint.
 With the default settings app usage and app error details data that
is in the app monitoring pages can be delayed for up to 29 hours.
Monitor and Manage App Licenses
 Farm Administrators and License Managers can check licenses for all apps for
SharePoint on the App Licenses page to make sure usage does not go over limits.
Both roles can assign users to an app license.
 Administrators purchase additional app licenses, and add managers to a license.
Demo:
Questions?
Backup Screenshots in case the
internet access screws me
over?
Prerequisites for creating an
autohosted app for SharePoint
 Visual Studio 2012. Obtain from Microsoft Visual Studio Ultimate 2012 RC.
 Office Developer Tools for Visual Studio 2012
 A SharePoint 2013 installation for testing and debugging.
 This can be on the same computer as your development computer, or you can
develop with a remote SharePoint 2013 installation, and the remote installation
can be on Microsoft SharePoint Online. If you work with a remote installation, you
need to install the client object model redistributable from SharePoint Client
Components on the target installation.
 The test SharePoint website must be created from the Developer Site site
definition (which you can create in Central Administration).
 The SharePoint 2013 installation must be configured to use OAuth. (If your test
website is a Developer Site provisioned on SharePoint Online, it is already
configured to use OAuth.)
Add an App to Monitor