2013 Cloud App Model - PowerPoint PPT Presentation

1 / 93
About This Presentation

2013 Cloud App Model


2013 Cloud App Model Presenter: Al Carroll May 15th 2013 * * * Repeat - hack * * Make concise * The user and app policy is required when a SharePoint 2013 site has an ... – PowerPoint PPT presentation

Number of Views:567
Avg rating:3.0/5.0
Slides: 94
Provided by: Windo289
Tags: app | based | cloud | model | testing


Transcript and Presenter's Notes

Title: 2013 Cloud App Model

2013 Cloud App
  • Presenter Al Carroll
  • May 15th 2013

  • Ben Carroll
  • SharePoint Architect (and nice guy)
  • Email bcarroll_at_ctndynamic.com or
  • LinkedIn www.linkedin.com/pub/ben-carroll/5/941
  • (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

  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

  • Its all about the Apps (..almost)

What is the Cloud?
  • IT as a service
  • IaaS, PaaS, SaaS

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 

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

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
  • Easy to deploy, monitor, find, upgrade, and
  • 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
  • Simple lifecycle Apps can be installed,
    upgraded, and uninstalled by site owners.
  • Integrate with Office Apps
  • Not available in SharePoint Foundation 2013

App User Experiences
  • Immersive Apps
  • Part Apps (App Parts)
  • Custom Action Apps
  • Branding and UI Integration
  • App Templates pull CSS from hosting SharePoint
    Environment when creating Visual Studio Apps
  • Chrome Control JavaScript based control which
    allows for consumption of styling of the parent

The App Store
  • Microsoft hosts and controls a public SharePoint
  • Developers can publish and sell their custom
  • End users and IT professionals can purchase apps
    for personal or organizational use.
  • This SharePoint Store will manage discovery,
    purchase, upgrades, updates, and dispute
  • Company-developed and approved apps can also be
    deployed to an organization's internal App
    Catalog hosted on SharePoint 2013 or SharePoint

Advantages of Apps
  • Advantages to Users
  • Apps are available through the App Catalog or App
  • 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
  • Advantages to Developers
  • Web Programming skills are reusable in creating
  • Common web standards of HTML, JavaScript, CSS can
    be used to develop Apps
  • Visual Studio 2012 supports App project templates
  • Like Sandboxed Solutions, developers can access
    SharePoint objects inside Apps
  • Opportunity to create publish Apps to
    SharePoint store

How are apps for SharePoint and SharePoint sites
  • Site owners can add apps for SharePoint to their
  • App containing SharePoint components, store those
    components in a subweb of the site that is
    automatically created upon app installation.
  • Apps have their own, isolated URLs, separate from
    the URL for the site containing the app.
  • If the app is a Provider-hosted then components
    are stored in the in the cloud.

Where are Apps hosted?
  • Provider-hosted
  • HTML and JavaScript hosted by SharePoint
    Environment of Provider
  • Hosted in the cloud (Windows Azure auto-hosted)
  • Hosted in a SharePoint environment
  • Several combinations of these options.

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

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

What is the URL for an app for SharePoint?
  • Apps by default are deployed to their own web
    site in an isolated domain name, separate from
    your farm, thus are unable to affect your
    SharePoint Sites. This prevents cross-site
    scripting between the apps and sites and
    unauthorized access to data.
  • Each app install has a unique URL in your
    SharePoint environment. You determine the
    template for that URL by specifying a domain name
    and an app prefix, and then app URLs are
    automatically generated based on that template.
  • Paths for the apps are based on the URL for the
    site where they are installed. Upon app
    installation, a subweb of that site is created to
    host app content. The subweb for the app is
    hierarchically below the site collection, but has
    an isolated unique host header instead of being
    under the site's URL.

Impacts of apps for SharePoint
  • Supporting apps for SharePoint in your
    environment does require configuration changes
    to your environment. There are two main
  • Requirements for supporting apps for SharePoint  
  • Subscription Settings and App Management service
    applications must be running.
  • A DNS domain to contain the URLs for apps for
    SharePoint in your environment must be created.
  • Plan for capacity  Each app for SharePoint
    creates a subweb under the site on which it is
    installed with its own URL. Environments with
    lots of apps have lots of subwebs. Keep this in
    mind during capacity planning

Where Apps fit in the SharePoint 2013
Customization Pathways?
Custom Development Directions
  • Farm Solutions
  • Sandbox Solutions
  • Apps

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
  • Apps can include SharePoint Solutions but NOT
    server side code.
  • Shiny new things in Apps that arent in Sandbox
  • App Marketplace
  • Oauth support

When to use Apps vs. Farm Solutions
There is overlap between the two due to the
evolution of SharePoint
  • Farm solutions
  • installed by farm admins with farm, web
    application, or site-collection scope, and can
    access the server object model and run code on
    the SharePoint Server.
  • Server object model has APIs enabling SharePoint
    management, configuration, and security,
    including extending Central Administration,
    backups, timer jobs, and PowerShell.
  • allows manipulation of SharePoint components and
    end user features, but in SP2013 the design
    intention is to use apps unless a single
    solution requires both administrative and end
    user functionality.
  • Apps
  • use one of the SharePoint client object models or
    REST endpoints to access SharePoint content and
    components. These client APIs are designed for
    end user functionality, (site owners, site
    members, and tenant admins).
  • Apps can be installed by tenant and site
    collection administrators.
  • Since SharePoint Apps are website scoped and
    cannot include custom code that runs on the
    SharePoint server, it cannot call administrative
  • In general use apps for end users functionality
    and farm solutions for administrator

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
  • Apps can include remote web pages that can use
    built in SharePoint web parts. These pages are
    available from every website where the app is
    installed and function like Application Pages.

Apps Architecture
Tenancies and App Scope..
  • 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

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.

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.

App Packages
  • An app for SharePoint package is essentially cab
    file with an ".app" extension, containing an app
  • App Manifests set app properties and provide
    SharePoint with installation instructions.
  • App Packages meet the Open Packaging Conventions
    (OPC) standard.
  • You can open the file by adding a ".zip"
    extension on the filename and then opening it in
    Windows Explorer or with winzip.

App Permissions
  • Apps that use an App web, the App will have full
    control rights to the App web, so it will only
    need to request and have permissions assigned to
    resources in the Host web or other locations
    outside the App web.
  • Apps use permission requests to specify the
    permissions that are needed at a particular
    scope.  There are different scopes that can be
    specified for content and in addition to these,
    there are also scopes for items such as
    performing search queries, accessing taxonomy
    data, and microfeed activities.
  • App permission rights indicate the activities
    that an app is permitted to do within the
    requested scope which are also detailed in the
    article referenced above. Unlike SharePoint user
    roles, these rights levels are not customizable.
  • Users installing apps must have full permissions
    on the Host web that an App is requesting. On
    installation the user will be notified as to what
    permissions the App requires.
  • Selective delegation and authorization Neither
    users launching an app, nor resource owners
    granting an app permission to access resources,
    have to give an app their username or password.
    SharePoint 2013 use OAuth so users and resource
    owners to grant only the specific permissions
    that the app requests.
  • Cross-domain access An app for SharePoint that
    includes a remote web application that uses
    JavaScript for its data access logic can use a
    JavaScript cross domain library to get authorized
    access to SharePoint data within the tenancy
    where the app is installed. 

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

Planning for Apps
  • Important for Apps
  • More in the configuration section

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

Plan Monitoring Apps
  • Farm Admins can monitor apps usage and errors by
    adding apps to the Monitor Apps page in
    SharePoint on-premises.
  • The maximum number of apps that can be monitored
    on the Monitor Apps page is limited to 100.
  • The Monitor Apps page requires search analytics
    and usage file import timer jobs to be running
  • ECM analytics timer job name Usage Analytics
    timer job for Search Service
  • Usage DB timer job name Microsoft SharePoint
    Foundation Usage Data Import

Plan for app licenses
  • SharePoint 2013 does not enforce app licenses.
    Developers who build apps must add code that
    retrieves license information and then addresses
    users appropriately.
  • SharePoint 2013 provides the storage and together
    with SharePoint Store web services the app
    license renewal.
  • SharePoint Store handles payments for the
    licenses, issues the correct licenses, and
    provides the process to verify license integrity.
    Note that licensing only works for apps that are
    distributed through the SharePoint Store. Apps
    that you purchase from another source and apps
    that you develop internally must implement their
    own licensing mechanisms.
  • SharePoint 2013 supports the following app
    licenses formats

License Type Duration User Limit
Free Perpetual Unlimited
Trial 30, 60, 120 Days, or Unlimited Number per user or Unlimited
Paid per user Perpetual Number per user
Paid unlimited users (site license) Perpetual Unlimited
Plan for App 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.

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.

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.

App authorization policies
  • SharePoint 2013 provides the following app
    authorization policies
  • User and app policy authorization succeeds if
    both the current user and the app have
    permissions to perform the actions that the app
    is attempting.
  • App-only policy  authorization succeeds if app
    has sufficient permissions, regardless of user
    permissions. This is required when the app is not
    acting on behalf of a user.
  • User-only policy authorization succeeds if the
    user has sufficient permissions to perform the
    action that the app is designed to perform.
    The user-only policy is required when a user is
    accessing their own resources..

App Development Environments and Deployment
SharePoint 2013 Developer Tools
  • Napa
  • Visual Studio 2012
  • SharePoint 2013 Designer

Napa - Not just a tasty vegetable..
  • Essentially a cloud or browser IDE and simplified
    browser version of Visual Studio
  • Office 365 Developer Sites have unlimited license
  • One way upsizing to Visual Studio 2012
  • Does not support code behinds
  • Client side code only

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

Languages and Environments for Apps Dev
  • Languages
  • Client side JavaScript for SP-Hosted Apps
  • C and VB.NET for Provider or Autohosted Apps
  • Local Development Environments
  • For SharePoint Hosted Napa within Office 365
  • For Provider or Autohosted Visual Studio 2012,
    Office, SharePoint Designer
  • A setup guide for development environments
  • http//blogs.technet.com/b/wbaer/archive/2012/10/1

Distribute with App Packages
  • Apps distributed using app packages
  • Package is a .zip file with .app extension
  • Built according to Open Package Convention (OPC)
  • Same format used for Office Apps
  • Must contain AppManifest.xml
  • Package contains inner WSP for app web
  • Elements deployed to app web using solution
  • Solution package built into app package as inner
  • 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

App Packaging and Deployment
App manifest (.xml) or .app package
Document Sharing
Office Store or App Catalog
Web Page
Consumers Corporate Users
Web Server (Internet or Intranet)
Packaging for Host Web and Autohosted Apps
  • Host web feature elements added at top level
  • Elements.xml file for each app part, custom
    action, and host web feature
  • Visual Studio adds GUID to file names
  • Autohosted apps packaged with extra resources
  • Office 365 requires resources to deploy remote
    webs be built in the app package as a Web Deploy
    Package (.web.zip)
  • Office 365 requires resources to create SQL Azure
    DB within app package as Data Tier Application
    Package (.dacpac)

Registering App Dependencies
  • If your app is dependent on a SharePoint
    capability 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.

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

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

App Environment Configuration
App Configuration Cheat Sheet from Microsoft
  • Image from Technet http//technet.microsoft.com

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

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

Farm Configuration
  • Create SharePoint Service Applications and enable
  • The Subscription Settings
  • The App Management service application
  • Configure App settings in SharePoint
  • App prefix and App domain for the farm
  • specifying the location of the App Catalog,
  • configuring Store settings such as whether users
    can install Apps from the Office Marketplace.

Internet-facing endpoints
  • The SharePoint Store contains apps for SharePoint
    intended for use with sites that require
    Internet-facing endpoints. Such apps are made
    unavailable for purchase by default since they
    are incompatible with most sites.
  • For farms configured to allow internet-facing end
    points, Administrators can activate the
    Internet-facing endpoints feature to show these
    apps in the SharePoint Store. You turn this
    feature on in Central Administration
    Application Management Manage Web Applications.

App Authentication Config Overview
  • Cloud-hosted Apps require configuration in order
    to work with our on-premise SharePoint 2013
    deployments since externally hosted Apps need to
    access 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.

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

Configure app requests and SharePoint Store
  • Farm admins determine if users can purchase apps
    from the SharePoint Store. This is scoped at the
    web application level.
  • When users request an app for SharePoint from the
    Store, they can request a the number of licenses
    and give a justification for the purchase.
    Requests are added to the App Requests list in
    the App Catalog of the web application. App
    Request include
  • Requested by The user name of the person
    requesting the app for SharePoint.
  • Title The title of the app for SharePoint.
  • Seats and Site License The number of licenses the
    user requested for that app for SharePoint.
  • Justification The reason why the app for
    SharePoint would be useful for the organization.
  • Status By default, the status is set to New for
    new requests. The person who reviews the request
    can change the status to Pending, Approved,
    Declined, Withdrawn, Closed as Approved, or
    Closed as Declined.
  • View App Details A link to the app details page
    in the SharePoint Store.
  • Approver Comments The person who reviews the
    request can add comments for the requestor.
  • If users cannot purchase apps, they can still
    browse the SharePoint Store, and request an app.
    Farm administrators and the App Catalog site
    owner can view and respond to app requests.

App Security
Authentication options for SharePoint Apps
  • Inside SharePoint
  • Must use HTML and JavaScript and SharePoint
    handles the authentication
  • In The Cloud
  • Client side code and cross-domain library
  • OR server side code and Oauth

Authentication Pieces Relevant to Apps
  • Claims
  • New and improved and the default for new web
  • 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

From http//blogs.msdn.com/cfs-filesystemfile.a
OAuth Flow
  • OAuth enables users to authorize the service
    provider (in this case, SharePoint 2013) to
    provide tokens like usernames and passwords
    instead of credentials, to their data that is
    hosted by a given service provider (that is,
    SharePoint 2013). Each token grants access to a
    specific site and resources for a defined period.
    This enables a user to grant a third-party site
    access to information that is stored with another
    service provider without sharing their user name
    and password and without sharing all the data
    that they have in SharePoint.
  • When is using OAuth required?
  • The OAuth protocol is used to authenticate and
    authorize apps and services. If you plan to build
    an app for SharePoint that runs in a remote web
    application and communicates back to SharePoint
    2013, you will need to use OAuth. The OAuth
    protocol is used
  • To authorize requests by an app for SharePoint to
    access SharePoint resources on behalf of a user.
  • To authenticate apps in the Office Store, an app
    catalog, or a developer tenant.

OAuth for cloud-hosted Apps
7 Access token
6 Access token request
2 Request context token
3 Signed context token
SharePoint Farm
Remote App Site
8 Request access token
1 - Request
9 SharePoint data
5 Request page include context token
10 IFRAME contents
App Rights
  • Set App Rights upon app installation
    (Read/Write/Manage/Full Control). Rights are
    granted rights explicitly by Tenant Admin or
    SPWeb Admin
  • End Users are prompted to give consent before App
    accesses their user data
  • Once provisioned, app rights cant be modified,
    but you can revoke them in whole.
  • Remember that permissions of parent objects are
    inherited by children by default.

OAuth in SharePoint low-trust apps
For a detailed walk through follow Josh Gavants
Blog http//blogs.msdn.com/b/besidethepoint/archi
  • 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

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

Data Storage and Access with Apps
Connectivity Options
  • Authenticating with SharePoint from your remote
  • OAuth
  • Cross-domain Library
  • Accessing data from SharePoint from your remote
  • 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.

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
  • In order to access data on a secured external
    system, you must configure the BDC model with the
    appropriate credentials. (fun with XML )

App Data Storage Options
  • Structured Data
  • SharePoint Apps can use a wide range of
    structured data storage not limited to SharePoint
    Data. This list includes but is not limited to
  • SharePoint lists in an app web
  • SQL Azure
  • External data sources connected to SharePoint
    with Microsoft Business Connectivity Services
  • 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.)

Monitoring Apps
Monitoring and logging
Monitoring app details in Central Administration
  • There are multiple ways that an administrator can
    view the error and usage details for apps for
    SharePoint. By selecting an app in the Monitored
    Apps page, an administrator can use the ribbon to
    access the error or usage details for that app.
    OR click an app in the list on the Monitored Apps
    page to open the app details page and access the
    same error or usage details.
  • Each app for SharePoint provides the following
    properties Name, Status, Source, Licenses in
    Use, Licenses Purchased, Install Locations, and
    Runtime Errors. A Farm Administrator chooses to
    add, remove, and monitor apps for SharePoint.
  • With the default settings app usage and app error
    details data that is in the app monitoring pages
    can be delayed for up to 29 hours.

Monitor and Manage App Licenses
  • Farm Administrators and License Managers can
    check licenses for all apps for SharePoint on the
    App Licenses page to make sure usage does not go
    over limits. Both roles can assign users to an
    app license.
  • Administrators purchase additional app licenses,
    and add managers to a license.

Backup Screenshots in case the internet access is
(No Transcript)
(No Transcript)
Prerequisites for creating an autohosted app for
  • 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
  • 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.)

(No Transcript)
(No Transcript)
(No Transcript)
(No Transcript)
(No Transcript)
(No Transcript)
(No Transcript)
(No Transcript)
(No Transcript)
Add an App to Monitor
(No Transcript)
(No Transcript)
Write a Comment
User Comments (0)
About PowerShow.com