KEMBAR78
Securing SharePoint Apps with OAuth | PPTX
Securing SharePoint Apps 
Using OAuth 
Kashif Imran 
kashif_imran@hotmail.com
Agenda 
• Issues with SharePoint Development/Security In the Past 
• SharePoint Apps 
• Security Primer 
• App Authentication in SharePoint 2013 
• OAuth 
• OAuth Flow in SharePoint 2013 and Security Tokens 
• Managing App Principals 
• Questions
Issues with SharePoint Security 
• Farm Solutions 
• Runs within the SharePoint workerprocess (w3wp.exe) 
• Access to Server Object Model 
• By default runs with current user’s permission 
• Developer can use SPSecurity.RunWithElevatedPrivileges that reverts code to Windows 
identity of host application pool 
• Farm stability issues 
• Installation and upgrade (iisreset) 
• Upgrade farm to newer version of SharePoint 
• Sandboxed Solutions 
• SPUCWorkerProcess.exe 
• Access to Server Object Model 
• Feature activation has full access to content (runs as site administrator) 
• Always runs as current user, can not use SPSecurity.RunWithElevatedPrivileges 
• Deprecated in SharePoint 2013 in favor of developing apps for SharePoint
SharePoint Apps 
• A web application that is registered with SharePoint using an app 
manifest. 
• Customize and extend SharePoint without full-trust access 
• Get its own security principal 
• Interacts with SharePoint using Client Object Model/REST 
• Distributed as app package (.app) to the public marketplace or 
corporate app catalog 
• Installed at site or tenant scope 
• Any Programming language/technology that can communicate with 
SharePoint via REST and OAuth
Types of SharePoint Apps 
• SharePoint-hosted 
• App resources stored in child 
site known as (app web) 
• App can only have client-side code 
• Cloud-Hosted 
• App resources deployed on remote server 
known as remote web 
• App can have both client-side and 
server-side code 
• 2 Types of Cloud-Hosted Apps 
• Autohosted (Hosted in Azure) 
• Provider-hosted (Deployed by provider)
Security Primer 
• Authentication (AuthN) 
• Authentication establishes an identity 
• SP 2010 supports user authentication 
• SP 2013 supports user and app authentication 
• Authorization (AuthZ) 
• Based on ACL 
• Ensure current principal has the proper permissions 
• SP 2010 supports permission only for users 
• SP 2013 supports permission for users and apps 
• Security Principal 
• An entity that is understood by a security system 
• An entity on which you can configure permission for resources 
• Examples: User in AD, FBA User, AD Group or FBA Role, SharePoint App
Claims-based Identity Model 
• Way for applications to acquire the identity information about internal or external users 
• Abstracts individual elements of identity and access control into “Notion of claims” and “Concept of issuer or an authority” 
• Applications do not need to authenticate users, store user accounts or passwords, etc. 
• Original intention behind the claims-based identity model was to enable federation between organization, but claims are not just 
for federation 
• Claim 
• Statement that one subject (user or organization) makes about itself of another subject. E.g.: name, group, ethnicity etc. 
• Why call these “claims” and not “attributes”? “Delivery method” => User delivers claims to application instead of application looking these up 
in some directory 
• Claims are NOT what a user can or can not do, they are what a user is or is not 
• Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer 
• Issuer, Type, Value => (Google, Email, darwaish@gmail.com) 
• Security Token 
• Serialized set of claims that is digitally signed by the issuing authority (Claims are unchanged and comes from whoever signed in) 
• Successful outcome of sign in 
• SAML (Security Assertion Markup Language), SWT (Simple Web Token), JWT (JSON Web Token)
Relying Party and STS 
• Relying Party (RP) 
• An application that relies on claims 
• Claims aware application 
• Claims-based application 
• Security Token Service 
• Service component that builds, signs and issues security tokens 
• Implicit authN (no token, no party) 
• WS-Trust, WS-Fed, SAML 
• IP-STS: 
• authenticates a client and creates SAML token 
• Façade for one or more identity stores 
• RP-STS (R-STS: Resource STS, FP-STS: Federation Provider STS) 
• Transforms token issues by another STS 
• Does not authenticate the client but relies on SAML token provided by IP-STS that it trusts 
• Façade for one boundary 
• Federation Patterns 
• Passive (Web Clients) WS-Trust emulated using GET, POST, redirects and cookies. 
• Active: Code to acquire tokens explicitly
Windows Identity Foundation (WIF) 
• .NET library encapsulating the inner workings of WS-Federation and 
WS-Trust 
• System.IdentityModel 
• System.IdentityModel.Services 
• IPrincipal (IsInRole, Identity), IIdentity (AuthenticationType, 
IsAuthenicated, Name) 
• IClaimsPrincipal = IPrincipal + Identities 
• IClaimsIdentity = IIdentity + Claims 
• Claims: Property bag, Subject, issuer, originalissuer, claimtype, value, 
valuetype
SharePoint Claims
App Authentication in SharePoint 2013 
• App are first class security principals and granted permissions separate 
from user permission 
• Granted as all or none and No hierarchy of permission 
• App authentication is only supported in CSOM and REST API end points 
• App authentication is NOT supported in custom web service entry points 
• Apps have Full rights against app web, can request permissions for other 
webs 
• Full Control permission can not be used for OfficeStore apps 
• Project Server permissions available if PWA is installed
Demo 
App Permissions
SP Permission Policies 
• App + User Policy 
• Both user and app require permission on the resource 
• App-Only Policy 
• Only app needs permissions on resource 
• Allow app code to elevate above permission of current user 
• Only supported for server-side code in cloud-hosted apps 
• AllowAppOnlyPolicy=“true” in AppManifest.xml 
• Permission granted during install (all or nothing) 
• User Policy 
• Not used when app makes a call to SharePoint
SP 2013 AuthN Flow for CSOM/REST Endpoint
Types of App Authentication in SharePoint 
• 3 basic types of app authentication 
• Internal authentication 
• External authentication using OAuth 
• Office 365 
• External authentication using S2S 
• On-premise
Internal Authentication 
• Used in Client-side calls from pages in app web or remote web which 
use cross domain library 
• Incoming calls require a SAML token holding an established user 
identity 
• Call targets unique domain of app web associated with an app 
• SharePoint maps target URL to instance of an app 
• App code is not required to create and manage security tokens
App Web 
• App by default has full permissions to read/write content to app web 
• No default permissions on any location in the SharePoint host environment 
• App.master provides UI to go back to host web 
• Isolated in its own private domain 
• https://{ TenancyName}-{14 char App UID}. sharepoint.com/ sites/{ ParentSiteName}/{ 
AppName}/ 
• http:// apps-{ UniqueID}. sp2013apps.local/ sites/{ ParentSiteName}/{ AppName}/ 
• Why Private Domain? 
• XSS: JavaScript code can not call back to host web 
• JavaScript do not run with the same established user identity as host web 
• SharePoint environment sees JavaScript callbacks from appweb with unique URLs and can 
authenticate apps 
• {StandardTokens}: { HostUrl}, {AppWebUrl}, { Language} 
• Use Internal Authentication: App is not required to create/manage security tokens
Demo 
App Web and Internal Authentication
External Authentication 
• Calls to SP from server-side code running in remote web 
• Used for both OAuth and S2S 
• Incoming calls require access token with app identity 
• Access token can optionally carry user identity as well 
• Call can target any CSOM or REST endpoint in any site 
• App code is required to create and manage security tokens
Demo 
External Authentication
OAuth 
• Manage app permission on the web 
• OAuth.net 
• Internet protocol/spec for creating/mapping app identity 
• A cross platform, open protocol for authenticating apps 
• Internet standard used by Google, Facebook, Twitter 
• Authorize requests by an app for SharePoint to access SharePoint resources on behalf of a user 
• SP2013 uses OAuth 2.0 (very different from OAuth 1.0) 
• OAuth specs provides details on how to create access tokens 
• Used for external auth in Office 365 
• Delegated authorization codes or access tokens are issues by OAuth STS (Windows Azure Control Services) 
• Remote web must communicate with ACS to obtain access tokens 
• Access tokens pass to SharePoint host in CSOM or REST API calls 
• WS-Federation STS and SAML passive sign-in STS are primarily intended to issue sign-in tokens 
• In SP2013, OAuth STS is uses only for issuing context tokens and not used as identity providers
OAuth Concepts 
• Content Owner(s) 
• SharePoint user(s) who can grant permissions to site content 
• Content Server 
• SharePoint web server that hosts site with the content that is to be accessed 
• Client App/ClientID/AppID 
• Remote web that needs permissions to access site content 
• Authentication Server 
• Trusted service that provides apps with access tokens allowing access to 
content 
• Windows Azure ACS in Sp2013 apps case
App Principals 
• Tenancy-scoped configuration for app identity 
• App principals must be registered with SharePoint and ACS 
• App Principal Properties 
• Client Id: GUID based identifier for app principal 
• Client Secret: Key to encrypt message between app and ACS 
• App Host Domain: Base URL of domain hosting remote web 
• Redirect URL: URL to a page used to configure security
Security Tokens used in OAuth 
• Context Token 
• Contextual information passed to app 
• JWT 
• Valid for 12 hours 
• Cache key: identify unique user 
(user, app, tenant) 
• Refresh Token 
• Used by client app to acquire an access token 
• Valid for 6 months 
• Access Token 
• Token passed to SharePoint to app 
when using external authentication 
• Valid for 12 hours
OAuth Workflow in Office 365
Context Token
Access Token
Steps to use OAuth in O365 
• Create new Cloud-hosted app project 
• Register App Principal 
• Registration handled automatically in autohosted apps 
• Registration requires manual steps in provider hosted apps 
• Registration requires extra steps for apps published to Office Store. Have to get client 
id/secret from Seller Dashboard 
• App principal properties 
• Client ID: Guid or app principal 
• Clint secret: key used to encrypt message sent between app and ACS 
• App host domain: base url which defined hosting domain for remote web 
• Redirect URL: URL to a page used to configure on the fly security 
• Add code in remote web to manage tokens 
• Code required to retrieve access tokens from ACS 
• Explicit code required to add access token to csom and rest api calls
Demo 
OAuth Tokens and App Principal
Managing App Principals in O365 
• /_layouts/15/… 
• AppRegNew.aspx 
• AppInv.aspx 
• AppPrincipals.aspx 
• PowerShell for SPOnline to administer SharePoint apps and app 
principals
Questions 
• ???

Securing SharePoint Apps with OAuth

  • 1.
    Securing SharePoint Apps Using OAuth Kashif Imran kashif_imran@hotmail.com
  • 2.
    Agenda • Issueswith SharePoint Development/Security In the Past • SharePoint Apps • Security Primer • App Authentication in SharePoint 2013 • OAuth • OAuth Flow in SharePoint 2013 and Security Tokens • Managing App Principals • Questions
  • 3.
    Issues with SharePointSecurity • Farm Solutions • Runs within the SharePoint workerprocess (w3wp.exe) • Access to Server Object Model • By default runs with current user’s permission • Developer can use SPSecurity.RunWithElevatedPrivileges that reverts code to Windows identity of host application pool • Farm stability issues • Installation and upgrade (iisreset) • Upgrade farm to newer version of SharePoint • Sandboxed Solutions • SPUCWorkerProcess.exe • Access to Server Object Model • Feature activation has full access to content (runs as site administrator) • Always runs as current user, can not use SPSecurity.RunWithElevatedPrivileges • Deprecated in SharePoint 2013 in favor of developing apps for SharePoint
  • 4.
    SharePoint Apps •A web application that is registered with SharePoint using an app manifest. • Customize and extend SharePoint without full-trust access • Get its own security principal • Interacts with SharePoint using Client Object Model/REST • Distributed as app package (.app) to the public marketplace or corporate app catalog • Installed at site or tenant scope • Any Programming language/technology that can communicate with SharePoint via REST and OAuth
  • 5.
    Types of SharePointApps • SharePoint-hosted • App resources stored in child site known as (app web) • App can only have client-side code • Cloud-Hosted • App resources deployed on remote server known as remote web • App can have both client-side and server-side code • 2 Types of Cloud-Hosted Apps • Autohosted (Hosted in Azure) • Provider-hosted (Deployed by provider)
  • 6.
    Security Primer •Authentication (AuthN) • Authentication establishes an identity • SP 2010 supports user authentication • SP 2013 supports user and app authentication • Authorization (AuthZ) • Based on ACL • Ensure current principal has the proper permissions • SP 2010 supports permission only for users • SP 2013 supports permission for users and apps • Security Principal • An entity that is understood by a security system • An entity on which you can configure permission for resources • Examples: User in AD, FBA User, AD Group or FBA Role, SharePoint App
  • 7.
    Claims-based Identity Model • Way for applications to acquire the identity information about internal or external users • Abstracts individual elements of identity and access control into “Notion of claims” and “Concept of issuer or an authority” • Applications do not need to authenticate users, store user accounts or passwords, etc. • Original intention behind the claims-based identity model was to enable federation between organization, but claims are not just for federation • Claim • Statement that one subject (user or organization) makes about itself of another subject. E.g.: name, group, ethnicity etc. • Why call these “claims” and not “attributes”? “Delivery method” => User delivers claims to application instead of application looking these up in some directory • Claims are NOT what a user can or can not do, they are what a user is or is not • Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer • Issuer, Type, Value => (Google, Email, darwaish@gmail.com) • Security Token • Serialized set of claims that is digitally signed by the issuing authority (Claims are unchanged and comes from whoever signed in) • Successful outcome of sign in • SAML (Security Assertion Markup Language), SWT (Simple Web Token), JWT (JSON Web Token)
  • 8.
    Relying Party andSTS • Relying Party (RP) • An application that relies on claims • Claims aware application • Claims-based application • Security Token Service • Service component that builds, signs and issues security tokens • Implicit authN (no token, no party) • WS-Trust, WS-Fed, SAML • IP-STS: • authenticates a client and creates SAML token • Façade for one or more identity stores • RP-STS (R-STS: Resource STS, FP-STS: Federation Provider STS) • Transforms token issues by another STS • Does not authenticate the client but relies on SAML token provided by IP-STS that it trusts • Façade for one boundary • Federation Patterns • Passive (Web Clients) WS-Trust emulated using GET, POST, redirects and cookies. • Active: Code to acquire tokens explicitly
  • 9.
    Windows Identity Foundation(WIF) • .NET library encapsulating the inner workings of WS-Federation and WS-Trust • System.IdentityModel • System.IdentityModel.Services • IPrincipal (IsInRole, Identity), IIdentity (AuthenticationType, IsAuthenicated, Name) • IClaimsPrincipal = IPrincipal + Identities • IClaimsIdentity = IIdentity + Claims • Claims: Property bag, Subject, issuer, originalissuer, claimtype, value, valuetype
  • 10.
  • 11.
    App Authentication inSharePoint 2013 • App are first class security principals and granted permissions separate from user permission • Granted as all or none and No hierarchy of permission • App authentication is only supported in CSOM and REST API end points • App authentication is NOT supported in custom web service entry points • Apps have Full rights against app web, can request permissions for other webs • Full Control permission can not be used for OfficeStore apps • Project Server permissions available if PWA is installed
  • 12.
  • 13.
    SP Permission Policies • App + User Policy • Both user and app require permission on the resource • App-Only Policy • Only app needs permissions on resource • Allow app code to elevate above permission of current user • Only supported for server-side code in cloud-hosted apps • AllowAppOnlyPolicy=“true” in AppManifest.xml • Permission granted during install (all or nothing) • User Policy • Not used when app makes a call to SharePoint
  • 14.
    SP 2013 AuthNFlow for CSOM/REST Endpoint
  • 15.
    Types of AppAuthentication in SharePoint • 3 basic types of app authentication • Internal authentication • External authentication using OAuth • Office 365 • External authentication using S2S • On-premise
  • 16.
    Internal Authentication •Used in Client-side calls from pages in app web or remote web which use cross domain library • Incoming calls require a SAML token holding an established user identity • Call targets unique domain of app web associated with an app • SharePoint maps target URL to instance of an app • App code is not required to create and manage security tokens
  • 17.
    App Web •App by default has full permissions to read/write content to app web • No default permissions on any location in the SharePoint host environment • App.master provides UI to go back to host web • Isolated in its own private domain • https://{ TenancyName}-{14 char App UID}. sharepoint.com/ sites/{ ParentSiteName}/{ AppName}/ • http:// apps-{ UniqueID}. sp2013apps.local/ sites/{ ParentSiteName}/{ AppName}/ • Why Private Domain? • XSS: JavaScript code can not call back to host web • JavaScript do not run with the same established user identity as host web • SharePoint environment sees JavaScript callbacks from appweb with unique URLs and can authenticate apps • {StandardTokens}: { HostUrl}, {AppWebUrl}, { Language} • Use Internal Authentication: App is not required to create/manage security tokens
  • 18.
    Demo App Weband Internal Authentication
  • 19.
    External Authentication •Calls to SP from server-side code running in remote web • Used for both OAuth and S2S • Incoming calls require access token with app identity • Access token can optionally carry user identity as well • Call can target any CSOM or REST endpoint in any site • App code is required to create and manage security tokens
  • 20.
  • 21.
    OAuth • Manageapp permission on the web • OAuth.net • Internet protocol/spec for creating/mapping app identity • A cross platform, open protocol for authenticating apps • Internet standard used by Google, Facebook, Twitter • Authorize requests by an app for SharePoint to access SharePoint resources on behalf of a user • SP2013 uses OAuth 2.0 (very different from OAuth 1.0) • OAuth specs provides details on how to create access tokens • Used for external auth in Office 365 • Delegated authorization codes or access tokens are issues by OAuth STS (Windows Azure Control Services) • Remote web must communicate with ACS to obtain access tokens • Access tokens pass to SharePoint host in CSOM or REST API calls • WS-Federation STS and SAML passive sign-in STS are primarily intended to issue sign-in tokens • In SP2013, OAuth STS is uses only for issuing context tokens and not used as identity providers
  • 22.
    OAuth Concepts •Content Owner(s) • SharePoint user(s) who can grant permissions to site content • Content Server • SharePoint web server that hosts site with the content that is to be accessed • Client App/ClientID/AppID • Remote web that needs permissions to access site content • Authentication Server • Trusted service that provides apps with access tokens allowing access to content • Windows Azure ACS in Sp2013 apps case
  • 23.
    App Principals •Tenancy-scoped configuration for app identity • App principals must be registered with SharePoint and ACS • App Principal Properties • Client Id: GUID based identifier for app principal • Client Secret: Key to encrypt message between app and ACS • App Host Domain: Base URL of domain hosting remote web • Redirect URL: URL to a page used to configure security
  • 24.
    Security Tokens usedin OAuth • Context Token • Contextual information passed to app • JWT • Valid for 12 hours • Cache key: identify unique user (user, app, tenant) • Refresh Token • Used by client app to acquire an access token • Valid for 6 months • Access Token • Token passed to SharePoint to app when using external authentication • Valid for 12 hours
  • 25.
  • 26.
  • 27.
  • 28.
    Steps to useOAuth in O365 • Create new Cloud-hosted app project • Register App Principal • Registration handled automatically in autohosted apps • Registration requires manual steps in provider hosted apps • Registration requires extra steps for apps published to Office Store. Have to get client id/secret from Seller Dashboard • App principal properties • Client ID: Guid or app principal • Clint secret: key used to encrypt message sent between app and ACS • App host domain: base url which defined hosting domain for remote web • Redirect URL: URL to a page used to configure on the fly security • Add code in remote web to manage tokens • Code required to retrieve access tokens from ACS • Explicit code required to add access token to csom and rest api calls
  • 29.
    Demo OAuth Tokensand App Principal
  • 30.
    Managing App Principalsin O365 • /_layouts/15/… • AppRegNew.aspx • AppInv.aspx • AppPrincipals.aspx • PowerShell for SPOnline to administer SharePoint apps and app principals
  • 31.