Follow me on Twitter @AntonioMaio2

Friday, March 7, 2014

Notes from SPC14: Authentication and Authorization Infrastructure in Microsoft SharePoint 2013


Wednesday March 5, 2014 10:45-12:00pm
Speaker: Paolo Pialorsi (www.pialorsi.com), MCM, Consultant
ITPro Session

Agenda
  • Authentication
    • Users authentication
    • Federation
    • Apps authentication
    • Custom claim provider
  • Authorization
    • User's authorization
    • App authorization
    • Server to server (high trust) 

Classic Mode
  • Deprecated!
  • For backwards compatibility only
  • Available only throguh PowerShell - no longer in Central Admin
  • Must Convert-SPWebApplication to migrate to claims

 

Claims Based
  • Default mode - only mode available in Central Admin
  • The future of authentication in SharePoint… and across the Microsoft stack 

Claims Modes Available/Supported
  • Anonymous
  • Windows - Basic, NTLM, Kerberos
  • Forms based Auth (FBA) - membership API, LDAP Provider, Claims Provider
  • Claims based authentication

DEMO

Breakdown of claims notation for identity claim - the notation has a specific meaning 

Trusting an external identity provider
  • Windows Azure ACS 2.0
    • Identity provider and security token service
    • Leverages external Identity Providers - MS account, facebook, google, yahoo, ADFS 2.0 or 3.0, Windows Azure AD, customer WS-Federation
    • Free!
    • Protocols: Oauth 3.0, WS-trust, WS-Federation
    • Tokens: SAML 1.1, 2.0, JSON Web Tokens (JWT)

DEMO

  • In Azure Management Portal > AD  - select Access Control Namespaces
  • Define the identity providers we want to use - will have a Windows Live ID Account provider by default (cannot remove)
    • Select the kind of identity provider: ex. For facebook need application ID, application secret
      • For facebook will need to login to developers.facebook.com and create an app to get this info
      • Provide the Windows Azure ACS URL to facebook form in order to get app ID and secret
  • Define Relying Party
    • Provide name, realm, return URL
    • Select token format - SP supports SAML 1.1
    • Define token lifetime (seconds to keep token alive)
  • Define Rule Groups
    • Very similar to ADFS claims rules
    • Can use a Generate button to automatically generate rules
  • Can open the Federation XML file that is generated
    • open it, copy the <x509Certificate> section and save it in a text file - save it as .cer file
    • Keep track of the PassiveRequestorEndpoint as well
    • Will need to use these in PowerShell to trust the ACS identity provider you just created 

Federating with Windows Azure ACS
  • When you trust an external IP you get claims
  • Sometimes you need to augment them
  • Sometimes you need to search for them in the peoplepicker
  • Often you need to authorize based on them 

Claims Providers
  • What you need is a claim provider
  • Claims augmentation - custom claims to extend issued security tokens
  • Names resolution (search, resolve, friendly values for claims, people, roles)
  • Available out of the box
    • SPActiveDirectoryClaimProvider
    • SPFormsClaimProvider
    • SPTrustedClaimProvider 

Developing Custom Claim Provider - Quick Overview
  • Inherit from SPClaimProvider: Microsoft.SharePoint.Administration.Claims
  • Implement methods for
    • Name resolution
    • Claims augmentation
    • Support hierarchies
    • Resolve claims
    • Search claims
  • Requires farm level solution (.WSP)
    • Not appropriate for Office 365
  • Leverages a dedicated feature with a receiver: SPClaimProviderFeatureReceiver
  • Must be activated via PowerShell  

DEMO - how a custom claim provider is built
  • Reviewed code sample of creating a custom claim provider - kept the example simple
  • Constructor
  • Setting default properties
  • Override FillClaimsForEntity

App Authentication
  • App Authentication is supported only for CSOM or REST API requests originated by an App! 

  • Internal App Authentication - when an app invokes CSOM/REST API from within an app web and with SAML token for user SharePoint hosted apps use this kind of app authentication
  • Cross domain calls in Cloud hosted apps use this kind of app authentication

External app authentication via Oauth
  • The app invokes CSO/REST API providing an access token signed by Windows Azure ACS
  • The access token can include app and user identity
  • Access token can be an app only identity
  • Is the only model supported by Office 365 

External App Authentication via server to server
  • App involves CSOM/REST API providing an access token signed with a trusted cert 



Oauth Flow

 
Server to Server (High Trust) Scenario
  • High Trust Not Equal to Full Trust
    • Extension of Oauth
    • Leveraged by apps and infrastructural services (workflow manager, exchange, etc)
    • Can use any user identity
  • Direct Trust Relationship
    • Between SharePoint and the external app/service
    • Based on x509 certs
    • One cert for each app (avoid sharing certs across apps)
    • Can leverage shared certs for trust brokers
  • Available for Provider Hosted Apps
    • Supported by wizard of VS 2012/2013 and Office Developer Tools for VS
    • Configurable using PowerShell

  • Provided example of PowerShell Script 

  • High Trust is NOT SAME as Full Trust!

Authorization
  • SPUser and SPGroup
    • Almost the same as SP2010
    • Define user or group principals - inherit SPPrincipal
    • You can give explicit permissions (authorization) - target site, lists, libraries, items/folders
    • Authorization leverages permission levels
    • Permission levels are made of permissions
      • Manage lists, add items, edit items, delete items, etc.
  • App Permissions
    • Apps are not users
    • Apps granted permissions on all or nothing basis
    • Performed through the app manifest
    • User installing an app grants/denies permissions during installation
    • If permission request is denied the app will not be installed at all
    • User can only grant permissions they have - must at least be a site owner to install an app
    • Cannot change permissions after assigned - can only remove the app

  • Every app by default has full control over its app web - but no other default permissions
  • Permissions are made of scope and right
  • Permission scopes
    • Site collection, web site, list, tenant, services
    • Permissions applied to a target scope, apply also to all the children of that scope
  • Permission Rights
    • Read-only, write, manage, full control
    • Other specific rights for services 

DEMO - SharePoint 2013 Authorization
  • Define permission levels on site collections
  • Define anonymous access
  • Trusting an App upon installation of that App 

Future of Claims Identity in SharePoint
Sesha Mani - Principal Program Manager SharePoint & Office 365 Cloud Services 

  • Started it in SP2010
  • Improved in SP2013 and made it the default
  • Claims infrastructure is at the core of future investments in SharePoint 

Claims, Oauth, S2S in SharePoint - Roadmap

 

S2S scenarios Available Out of Box
  • SharePoint to Exchange - eDiscovery, site mailboxes, mysite project tasks sync
  • High resolution photos
  • SharePoint to SharePoint - translation service, hybrid Duet/SAP, Hybrid Search
  • SharePoint to MTW - multi-tenant workflows (MTW)
  • SharePoint to Apps - App Model extensibility
  • SharePoint to Azure media service - SharePoint Video Portal (coming soon)

Microsoft is fully committed to evolving claims within SharePoint and the rest of the platform 

Wrap Up
  • User authentication claims based
  • External Identity Providers
    • ACS, ADFS
    • Custom claim providers for better user experience
  • App Authentication
    • Internal auth
    • External Auth via Oauth
    • External Auth via S2S
  • Authorization
    • SPPrincipal
    • App Principal

No comments:

Post a Comment