SS

Speaker : Paolo Pialorsi

In SharePoint 2013, authentication is done using Classic mode (Windows Identity), bringing an SPUser, or Claims which is translated into a Claims Based Identity. It is also possible to authenticate a used through SAML.

Classic mode authentication is considered as deprecated, and is only available from PowerShell. Legacy application should migrate to Claims. Claims based is the default mode. Claims based enables anonymous authentication, Windows authentication (NTLM or Kerberos), Forms based authentication (with membership API, LDAP or custom Provider) and Trusted Identity Provider (ADFS 2.0/3.0, Azure ACS, Azure Directory Service – AAD, or custom IdP/STS). It is now the default authentication mode.

The Identity Claims has a specific format. Something like the following :

i:0#.w|piasys\paolo => Windows Account

i:0#.f|fbamembership|paolo => FBA Account

i:05.t|piasys-acs|paolo@pialorsi.com => SAML Account

The first letter defines whether it is an identity claim (i) or an other kind of claim (c). Then : is the separator followed by 0 which is reserved. The following digit gives the claim type (# = logon name, 5 = email, a = username, ? = name identifier, ! = identity provider, – = role), followed by the value type of the claim (. = String). The following letter gives the claim issuer (w = Windows, t = trusted identity provider, f = forms authentication, g = custom claims provider).

This defines the claim issuer, the way the user authenticated, separators, issuer name and the claim value.

Windows Azure ACS 2.0 encompasses an identity provider and a security token services, which support different identity provider such as Facebook and Google or any other Customer WS-Federation compliant provider. Specifications supported by ACS 2.0 are OAuth 2.0, WS-Trust, WS-Federation, SAML 1.1/2.0 and JSON web token (JWT).

When trusting an external identity provider, only claims are sent. SharePoint uses claims provider to get claim values. It has 3 out of the box claim providers, for Active Directory, Forms based authentication and any kind of identity provider. To develop custom claim provider, it has to inherit from SPClaimProvider, which provides methods for Name resolution, claim augmentation, etc. A claim provider requires a farm solution (so, not suitable for Office 365).

App authentication is supported only for CSOM or REST API requests.

3 app authentication model : internal app authentication used by SharePoint-Hosted apps, external app authentication via OAuth supported by O365, and external app authentication via server to server which is only supported on-premises.

Server to Server is also called High-Trust authentication, but it does not mean Full Trust. It establishes a direct trust between the servers and is based on a X.509 certificates. It is available for provider-hosted apps and configurable using PowerShell.

For authorization, SPUser and SPGroup classes, inheriting from SPPrincipal, are the main actors, that are almost the same as in SharePoint 2010. They define user or group principals to which it can be given explicit permissions to site, lists, items, etc. The authorizations rely on permission levels that are nothing else than a set of permissions.

Apps are not users and are granted as all or nothing. App can include permissions requests. If the app is granted, the app can be installed. If only one request is not granted, the app will not be installed. Permissions cannot be changed after assignment, but only be revoked. App has only full control on its own app web. Permissions are targeting scopes and rights, such as site collection, list and read, read-write, manage or full-control. The rights can also target a specific service. Rights and scopes are not customizable.