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

7 comments:

  1. client recognizable proof, permit keys and passwords for the greater part of your other programming.
    solar companies

    ReplyDelete
  2. These kinds of maps will be exceptionally helpful for the R&D personals to assess the situation of their examination and technology, and furthermore they will discover approach to more advance further developed and significant technology. https://www.techpally.com/learn-to-repair-ac/

    ReplyDelete
  3. The instructors themselves are certified instructors for this program and the curriculum is presented by those instructors along with collaboration with partner organizations who bring upon real world scenarios to ensure that the student get to learn the most out of the sessions. MCSE Training London

    ReplyDelete
  4. Just a few weeks ago, our 12-week-old Maltipoo puppy was brought to us. He does, however, snarl, leap, nip, and bark at us once in a while. Rosco is acting better now, but did he ever act this way as a puppy? amazing blog, https://www.logosymmetry.co.uk/blog/developing-wordpress-website-theme

    ReplyDelete
  5. For the greater part of your other programs, you need client identifiers, permit keys, and passwords.
    social media video company

    ReplyDelete
  6. Security for user access is supported by SharePoint at the website, list, list or library folder, and item levels. With an uniform role-based user interface and object model for granting permissions on objects, security management is role-based at all levels and provides cohesive security management across the SharePoint platform. best isalmic school karachi This makes it simpler to handle user rights and group rights across a whole website because list-level, folder-level, or item-level security applies the same user model as website-level security.

    ReplyDelete
  7. SharePoint 2013 interprets the user accounts as AD DS accounts best spa in karachi when using classic mode authentication.

    ReplyDelete