2013 Cloud App Model

1
2013 Cloud App
Model

• Presenter Al Carroll
• May 15th 2013

2
Introductions

• Ben Carroll
• SharePoint Architect (and nice guy)
• Email bcarroll_at_ctndynamic.com or
  BenIsAGreatGuy_at_gmail.com
• 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

3
Agenda

1. Overview
2. Where Apps fit in the SharePoint 2013
   Customization Pathways?
3. Apps Architecture
4. Planning for Apps
5. Apps Development
6. App Environment Configuration
7. App Security
8. Data Storage and Access with Apps
9. Monitoring Apps
10. Demo
11. Questions

4
Overview

• Its all about the Apps (..almost)

5
What is the Cloud?

• IT as a service
• IaaS, PaaS, SaaS

6
Why your bosses and clients might care

• When does it make sense for an organization to
  consider cloud computing alternatives to in-house
  IT services?
• CIOS - Is it faster? Can I manage it? Can I
  save money?
• CMO or CFO can I side-step around IT when I
  need to? Can I save Cloud is a Business Enabler 

7
Why you (developer) should care

• emerging force in software development, almost as
  big the Internet was in the mid-1990s..
• Software delivery becomes easier than ever before
  with the power of the cloud at your back.
• interconnected and integrated applications. In
  the cloud, the integration story is usually
  clearer and easier than on premise.
• more is better for available computing power.
• ignore cloud computing at your peril

8
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

9
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

10
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

11
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

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

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

14
SaaS Licensing for SharePoint

• Because of default external sharing, site owners
  can easily share sites and content with external
  users without requiring internal Active Directory
  accounts..
• SharePoint Online's social features have been
  spread throughout the product, including activity
  tracking via the personal Newsfeed, file sharing
  through SharePoint's SkyDrive Pro, and a
  centralized favorite Sites page.
• Optional integration of Exchange Online
  enables SharePoint Online to centralize task
  assignments across sites and even Outlook tasks
  that would otherwise never hit SharePoint.
• SharePoint Online for Enterprise also supports
  Excel services-based business intelligence, a new
  workflow engine based on Windows Workflow
  Foundation 4 that supports loops and a number of
  new actions in SharePoint Designer 2013, and
  enhanced video management capabilities complete
  with search integrations.

15
Azure Workflows

• In addition to a new development model
  for SharePoint app functionality, SharePoint 2013 
  introduces a new model for developing
  workflows. SharePoint 2013 offers the .NET 4.5
  Windows Workflow Foundation as a new approach to
  enacting custom logic inside of
  a SharePoint site. The .NET 4.5 Workflows are
  hosted outside of SharePoint on Windows Azure
  Workflow service. Office 365 uses this new Azure
  service automatically, not requiring developers
  to acquire a Windows Azure account. The
  integrations in Office 365 are provided
  automatically.
• The benefits of including .NET 4.5 Workflows
  include a number of new workflow capabilities
  such as stages and loops, the ability to invoke
  web services, and, of course, the scalability and
  performance benefits to run on the Azure
  platform. 
• New in SharePoint 2013 is integration with
  Project2013, complete with Project-based
  workflows. As developers and site owners approach
  creating workflows for SharePoint 2013, they have
  two choices of platforms the new platform
  leveraging Windows Azure Workflow Services and
  .NET 4.5 or the old SharePoint 2010 platform.
• As with other SharePoint 2010 customizations, the
  entire 2010 workflow platform was brought forward
  into SharePoint 2013 so that no existing
  investments need change.
• Workflows can be built with the
  Office SharePoint Designer or with Visual Studio
  2012. In either case, workflows are
  declarative-only constructs that rely on XAML
  files to define and frame the execution of the
  logic. The implication of this change is that
  workflows are no longer compiled but are instead
  interpreted. This interpretive approach is what
  enables workflows to be executed outside of
  the SharePoint run time and offers opportunities
  for numerous visualization and editor tools.

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

17
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

18
Where Apps fit in the SharePoint 2013
Customization Pathways?
19
Custom Development Directions

• Farm Solutions
• Sandbox Solutions
• Apps

20
Apps compared to Sandbox Solutions

• Microsoft wants you to use App Model to most
  places where you wouldve used Sandbox Solutions.
  
• (Pssst Hey buddy. sandboxes are deprecated
  going forward)
• App solutions can be used to deploy declarative
  SharePoint Objects like lists
• Apps cant 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 arent in Sandbox
  Solutions
• App Marketplace
• Oauth support

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

22
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 wouldve done with server side code.
• Use SharePoints REST/OData service for accessing
  SharePoint lists and data.
• Access SharePoint data remotely via JavaScript,
  .Net Client Object Model, or Silverlight OM.
• Where you wouldve 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.

23
Apps Architecture
24
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 cant be batch installed. Custom
  actions that are deployed as menu items are
  allowed.

25
Hosting
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 dont 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.
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
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.

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

26
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
  Apps 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 packages
  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 dont include
  server side code running on SharePoint servers
  can be included in an app and deployed to the
  app web.

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

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

29
Service Applications

• Two service applications required for apps
• App Management Service
• Site Subscription Management Service
• These must be created in on-premise farms for
  apps to work

30
Planning for Apps
31
DNS and SSL

• Important for Apps
• More in the configuration section

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

33
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

34
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
35
Plan for App Permissions

• App Permissions manage apps 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.

36
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//ltsharepointservergt/ltcontentgt/lttenantgt/
37
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 dont 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.

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

39
App Development Environments and Deployment
40
SharePoint 2013 Developer Tools

• Napa
• Visual Studio 2012
• SharePoint 2013 Designer

41
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

42
SP 2013 Deployment Options

• On-Premise
• Installed on your hardware
• Access to all of SharePoints features
• Hosted
• Installed 100 in the cloud usually on Office 365
• Feature set is limited
• Hybrid

43
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/1
  0/setting-up-a-sharepoint-2013-development-environ
  ment-101.aspx

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

45
App Packaging and Deployment
App manifest (.xml) or .app package
Developer
Document Sharing
Office Store or App Catalog
Web Page
Consumers Corporate Users
Web Server (Internet or Intranet)
46
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)

47
Registering App Dependencies

• If your app is dependent on a SharePoint
  capability thats unavailable and cannot be made
  available on the app web, then it wont 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.

48
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
• ltAppPrerequisitesgt ltAppPrerequisite
  TypeAutoProvisioning IDRemoteWebHost /gt
  ltAppPrerequisite TypeAutoProvisioning
  IDDatabase /gt lt/ AppPrerequisitesgt --MSDN

49
Update Your App

• The App framework in SharePoint 2013 enables
  preservation of the apps 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 apps listing in
  the Site Contents page of every website where the
  app is installed.
• SharePoints 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.

50
App Environment Configuration
51
App Configuration Cheat Sheet from Microsoft

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

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

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

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

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

56
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 SharePoints data. Since trusts arent
  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 SharePoints 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.

57
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 ltgt "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.a
  spx

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

59
App Security
60
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

61
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 doesnt 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

62
From http//blogs.msdn.com/cfs-filesystemfile.a
shx/__key/communityserver-blogs-components-weblogf
iles/00-00-00-25-31-metablogapi/6840.image_5F00_68
B8261A.png
63
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.

64
OAuth for cloud-hosted Apps
STS (ACS)
7 Access token
6 Access token request
2 Request context token
3 Signed context token
SharePoint Farm
Remote App Site
8 Request access token
1 - Request
Client
4 Page IFRAME
9 SharePoint data
5 Request page include context token
10 IFRAME contents
65
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 cant be modified,
  but you can revoke them in whole.
• Remember that permissions of parent objects are
  inherited by children by default.

66
OAuth in SharePoint low-trust apps
For a detailed walk through follow Josh Gavants
Blog http//blogs.msdn.com/b/besidethepoint/archi
ve/2012/12/10/sharepoint-low-trust-apps-for-on-pre
mises-deployments.aspx

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

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

68
Data Storage and Access with Apps
69
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
• 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
  its data
• These are developer tasks but mentioned here so
  IT Pros can be aware of which libraries
  developers may be leveraging in your farms.

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

71
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

72
Monitoring Apps
73
Monitoring and logging
74
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.

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

76
Demo
77
Questions?? 
78
Backup Screenshots in case the internet access is
unavailable 
79
(No Transcript)
80
(No Transcript)
81
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.)

82
(No Transcript)
83
(No Transcript)
84
(No Transcript)
85
(No Transcript)
86
(No Transcript)
87
(No Transcript)
88
(No Transcript)
89
(No Transcript)
90
(No Transcript)
91
Add an App to Monitor
92
(No Transcript)
93
(No Transcript)