Managing 2013 Apps for IT Pros

Presenter: Al Carroll May 15th 2013

Ben CarrollSharePoint Architect (and nice guy) Email: bcarroll@ctndynamic.com LinkedIn: www.linkedin.com/pub/ben-carroll/5/941/937/(I would love feedback and questions/discussion via email)

Introductions

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

1. Overview2. Where Apps fit in the SharePoint 2013 Customization

Pathways?3. Apps Architecture4. Planning for Apps5. Apps Development6. App Environment Configuration7. App Security8. Data Storage and Access with Apps9. Monitoring Apps10. Demo11. Questions

Agenda

It’s all about the Apps (..almost)

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

SharePoint 2013 Apps Overview

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

App User Experiences

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

The App Store

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

Advantages of Apps

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.

How are apps for SharePoint and SharePoint sites related?

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.

Where are Apps hosted?

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.

What is the URL for an app 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

Impacts of apps for SharePoint

Where Apps fit in the SharePoint 2013

Customization Pathways?

Farm Solutions Sandbox Solutions Apps

Custom Development Directions

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..

IT Pro Challenges with SharePoint 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

Apps compared to Sandbox Solutions

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.

When to use Apps vs. Farm Solutions

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.

There is overlap between the two due to the evolution of SharePoint

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.

App Approaches to Pre-App Scenarios

Apps Architecture

“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

Tenancies and App Scope..

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.

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.

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

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 BusAs 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.

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 Webs, Host Webs, Features, and SP Components

in Apps

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 Packages

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. 

App Permissions

Two service applications required for appso App Management Serviceo Site Subscription Management Service

These must be created in on-premise farms for apps to work

Service Applications

Planning for Apps

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 App Configuration Settings

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 DNS

“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.

Plan SSL

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 subdomainsIf you use a subdomain then potentially malicious code could read or set cookies.

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.

Host Headers

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 The App Catalog & Store

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 Monitoring Apps

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:

Plan for app licenses

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

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 Governance

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.

Plan for App Permissions

App permission rights

• Read• Write• Manage• Full control

App permission request

• Tenancy• SPSite• SPWeb• SPList

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.

App permission request scopes

URI

http://sharepoint/content/sitecollection/

http://sharepoint/content/sitecollection/web

http://sharepoint/content/sitecollection/web/list

http://<sharepointserver>/<content>/<tenant>/

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 Permission Inheritance

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 authorization policies

App Development Environments and

Deployment

Napa Visual Studio 2012 SharePoint 2013 Designer

SharePoint 2013 Developer Tools

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

Napa - Not just a tasty vegetable..

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

SP 2013 Deployment Options

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

Languages and Environments for Apps Dev

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.

Distribute with App Packages

Office Store or App Catalog

Consumers &Corporate Users

Developer

Web Server(Internet or Intranet)

App manifest (.xml)or .app package

DocumentSharing

App Packaging and Deployment

Web Page

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)

Packaging for Host Web and Autohosted Apps

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.

Registering App Dependencies

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

Register autohosted components

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 non-SharePoint components so that a rollback can take place if the update installs.

Update Your App

App Environment Configuration

Image from Technet: http://technet.microsoft.com/en-us/library/fp161236.aspx

App Configuration Cheat Sheet from Microsoft

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).

DNS and SSL

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.

Farm Configuration

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.

Internet-facing endpoints

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.”

App Authentication Config Overview

Configure SharePoint for low-trust AppsLow-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 AppsHigh-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

Low and High Trust Apps

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

Inside SharePointMust use HTML and JavaScript and SharePoint handles the authentication

In The CloudClient side code and cross-domain libraryOR server side code and Oauth

REST APIs

Authentication options for SharePoint Apps

Authentication Pieces Relevant to Apps

From: http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-25-31-metablogapi/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

1 - Request

2 – Request context token

3 – Signed context token

4 – Page + IFRAME

5 – Request page + include context token

10 – IFRAME contents

9 – SharePoint data

8 – Request + access token

7 – Access token

6 – Access token request

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.

App Rights

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 DirectoryReplace 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 PrincipalsWe’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.

OAuth in SharePoint low-trust apps

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

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 IISInclude ClientSigningCertificatePath and password for the .pfx fiel in the web.config of the appSelect 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 appsPre-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

Server to Server (S2S) Trust

On-premises Farm

1

2

43

S2S STS

SSL Cert Public/

Private key pair (.pfx)

(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 = Get-SPAuthenticationRealm -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"

Server to Server (S2S) Trust..

Data Storage and Access with Apps

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

Accessing data in your remote app from SharePoint Web proxy Remote Event receiver Cross-domain library with a custom proxy page

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.

Connectivity Options

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 :)

Overview of app-scoped external content types in

SharePoint 2013

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

App Data Storage Options

Monitoring Apps

Monitoring and logging

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.

Monitoring app details in Central Administration

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.

Monitor and Manage App Licenses

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