Authentication – 辨别访问者是否是个valid account
- Identity Scenarios
- Incoming Authentication
A client presents its identity to the platform, authenticating with the Web Application or Web Service.
- Classic Mode(Default in 2010, Still supported in 2013 only by PowerShell)
Classic mode allows the typical Internet Information Services (IIS) authentication methods – Integrated Windows and others.
- Integrated Windows Authentication
- Claim-based Mode(based on Identity and utilizes open-source standards and protocols SAML so that it works with any corporate Identity system)
Enables you to take advantage of all the new features and scenarios in SharePoint 2013 that use server-to-server authentication and app authentication.
- Integrated Windows-claimed(Supported in 2010 by PowerShell only, Default in 2013)
- Forms-based Claim(FBA)(2010. 2013)
- LDAP (such as Novell eDirectory)
- SQL Server DB
- Security Assertion Markup Language-based (SAML1.1-based Claim and WS-Federation Standard)(2010. 2013) for SSO
- SAML Token = SAML Assertion is a XML node with elements(user identify information) which are compressed, encoded and encrypted into a Token
- The user’s credentials never passed through Service Provider MyPhotos.com, only through the Identity Provider.
- The step D has two options to bind user token back to Service Provider:
- HTTP Redirect (for short message like query parameters of URL)
- HTTP POST (for long message by Form)
- But most Mobile Apps are only able to be launched by URL because they cannot access HTTP POST body, so workarounds are: 1) use embedded web Views in Mobile Apps; 2) use a proxy server to receive and access HTTP POST, and parse out SAML Token, then HTTP Redirect to Mobile Apps; 3) Use OAuth instead of SAML.
SAML Identity Providers (custom code is necessary):
- ADFS & Windows Azure Access Control Service(support SAML 1.1/2.0)
- Google or Facebook etc.
- Open Authorization(OAuth 2) (new in 2013) for SSO
It’s a Specification instead of a Standard or a Protocol.
- Identify Provider = Authentication Server
- Only using HTTP Redirect, so compatible with most Mobile Apps
- Should use SSL always
When the app uses its OAuth token to perform some tasks, another app on the same page can use this token to perform actions on behalf of the app identity, the user identity, or both. It’s also possible for a hacker to hijack the OAuth token in an HTTP channel. So that is why OAuth 2.0 requires HTTPs.
- Need an additional round trip to Identity Provider
- Authorization instead of Authentication
OAuth is used only for resource access(Authorization), not for user Authentication, which is an industry standard protocol that allows a user or application to temporarily access resources or information on behalf of another user without providing credentials. SP2013 Cloud App Model is using it to authorize apps to access resources on behalf of users. A trust relationship between SharePoint 2013 and a cloud provider such as Windows Azure Access Control Service (ACS) can also be established. S2S requires user profiles, so user profile mapping and profile imports must be configured. S2S is used by eDiscovery(index mailbox content in Exchange Server 2013 and conversation content in Lync Server 2013), Task management(combine tasks in Outlook 2013 and in SharePoint 2013 into the view of user’s personal site), Site mailboxes(Exchange 2013 mailboxes are viewable in SP2013 websites) and Workflow(authenticate and share information with the new Azure Workflow Server).
- Application authentication model
- Server-to-Server(application-to-application) authentication model
Some service applications, such as Excel Services, PPS or Visio Services, require to use the Windows Identity Foundation (WIF) Claims to Windows Token Service (C2WTS) to translate claims within the farm to Windows credentials for outbound authentication. It is important to understand that C2WTS only functions if the incoming authentication method is either classic mode or Windows claims. The web application cannot use multiple forms of claims on the web application, otherwise the C2WTS will not function.
- Inter/Intra-farm Authentication
SharePoint 2010/2013 Products environments use Claims Authentication for intra- and inter-farm communications with most SharePoint service applications and SharePoint integrated products regardless of the incoming authentication mechanism used. This means that even where classic authentication is used to authenticate with a particular web application, SharePoint Products convert the incoming identity into a claims identity to authenticate with SharePoint Service Applications and products that are claims-aware.
Refer to each product or service application’s documentation to determine whether it can support claims-based authentication and identity delegation. For example, SSRS is NOT claim-aware, and the RSS View Web Part relies on Classic Kerberos.
- Outbound Authentication
This is represented when services within the Farm have to authenticate with external line-of-business systems and services, using two modes:
- Trusted Subsystem
The front-end service authenticates and authorizes the client, and then authenticates with additional back-end services WITHOUT passing the client identity to the back-end system because the back-end system trusts the front-end service to do authentication and authorization on its behalf.
- Using the IIS application pool identity — usually achieved by running code in the web application that elevates permissions while making a call to an external system. Other methods such as using RevertToSelf can also use the application pool’s identity to authenticate with external systems.
- Using a shared service account — typically achieved by storing application credentials in the Secure Store (SSS) then using those credentials to authenticate with an external system. Other methods include storing the service account credentials in other ways such as embedded connection strings.
- Anonymous Authentication — this is where the external system requires no-authentication. Therefore the front-end SharePoint Server service does not have to pass any identity to the back-end system.
The front-end service first authenticates the client, and then uses the client’s identity to authenticate with another back-end system that performs its own authentication and authorization.
- Kerberos Delegation — If the client authenticates with the front-end service by using Kerberos authentication, Kerberos delegation can be used to pass the client’s identity to the back-end system.
- Kerberos enabled services can delegate identity multiple times across multiple services and multiple hops. As an identity travels from service to service, the delegation method can change from Basic to Constrained but not in reverse.
|Basic(Unconstrained) Delegation||Constrained Delegation|
Any service that relies on the Claims to Windows token service (C2WTS), such as Excel Service, PPS and Visio Services, must use Kerberos Constrained Delegation to allow the C2WTS to use Kerberos protocol transition to translate claims into Windows credentials.
Some services that are not relied on C2WTS, such as BDC/BCS, InfoPath Forms Services, Access Services, SSRS and MS Project Server, can use Kerberos Basic(Unconstrained) Delegation.
Either of above two Kerberos are not affected to the SQL Server PowerPivot for SharePoint.
- Claims Authentication — The claims authentication allows the client’s claims to be passed between services as long as there is trust between the two services and both are claims-aware.
(Currently, most of the service applications that are included with SharePoint Server do NOT allow for Outbound Claims authentication, but outbound claims is a platform capability that will be taken advantage of in the future. Further, many of the most common line-of-business systems today do not support incoming claims authentication, which means that using outbound claims authentication may not be possible or will require additional development to work correctly.)
# 关于Classic Mode vs. Claim-based Mode，以及NTLM vs. Kerberos的小结：
例如：Kerberos 和 Claim-based是无从比较的。
- Classic Mode vs. Claim-based Mode
|Classic Mode||Claim-based Mode||Comments|
|Classic identify is “doman\account” format||Claim identify is “i:0#.w|domain\username” format encapsulates in token||A given user can have a classic identity and a claims identity, and SharePoint will treat this as two totally different users.|
|Need AD domain||Needn’t||Not particularly well suited for interoperability with other applications outside your organization.|
|key benefit1: cause application can focus on authorization because it no longer needs to authenticate the user.|
|User identity is based on the user account(name and pwd) and need more queries to Identify Provider such as AD for getting account attributes and information||key benefit2: Less queries to Identify Provider such as AD|
|Claims alone and in combination with OAuth offers new ways to delegate authentication and authorization, and to utilize user profile information|
Claim-based Mode支持更为广泛的(Identify Providers based on SAML standard)认证传输信息格式。Classic Mode所使用的ticket仅仅是Windows所支持的，而Claim-based Mode所使用的token是一个更为通用的接口，可以把更广泛的数据格式，例如，(当然仍然包括Window authentication)、基于 LDAP、SAML 或OAuth的credential等信息封装到这个通用的token中。
- NTML不支持把NTML token传给external applications，而Kerberos支持吧Token传给external applications。而external applications拿到token后可以到DC STS中去验证这个credential是否定义了相应的SPN来访问这个external applications。
- 其它的Claim-based方式，例如：LDAP, SAML等，支持把token/ticket/credential传给external applications，前提是目标applications也配置了相同的CBA模式，并且到同一个STS中去验证credentials。假设SharePoint是CBA-SAML,而SSRS是Windows Authentication mode，那么用户在通过SP页面中的普通links(没有integration SSRS)访问SSRS是就会弹出来让用户输入Windows authentication认的credentials，也就是DC中的STS认的credentials。
- Zones are extension of a Web Application, which is for applying different authentication mode for the Web Application. 但其实，从SP2010开始，同一个Web Application Zone可以配置多个authentication modes，用户访问首页面时，SP将会弹出dropdown list供其选择mode。但是，同一个用户如果用不同的authentication mode来登陆(输入自己的credential)，系统会认为他是两个不同的accounts。
# Two ways of migrating from 2010 Classic to 2013 Claim
- Migrate from classic authentication to claims authentication in SharePoint 2010. SharePoint 2010 content can then be migrated to SharePoint 2013 via normal methods (database attach, etc.).
- Migrate the SharePoint 2010 content to SharePoint 2013 via the database attach method. Convert the classic-mode web application to use claims via PowerShell.
Authorization – 根据辨别的访问者来决定它对什么对象具有什么访问权限
- AD Security Groups present organization structure and person’s group;
- SharePoint Groups present business requirement for (connection between) permissions and objects of SharePoint;
- Generally, the OOB permission levels are enough to most of business requirements, else, we should have to create new permission levels.
Site Settings -> Site Permission -> Permission Level
- AD Security Groups can nest by themselves;
- AD Security Groups can nest to SP Group;
- SP Groups cannot nest by themselves;
- Can check Site Permissions/Basic Permissions (Site-SPGroups-PermissionLevels)
Site Settings -> Site Permission
- Aside from Site Permissions(Basic Permission) such as Owner-FullControl, Visitor-Read or Members-Contribute, we can grant specific object with dedicated permission levels (Object-SPGroups-PermissionLevels) by SP Groups after breaking the object’s inheriting permission.
Object -> Shared With -> Advanced
- Case Study – All items of all lists/libraries can be targeted by logged-on user’s properties(Country, Store Type, Role).
Scenario Assuming: End user fill two Countries, two Store Types and two Roles for an item.
- Establish complete nesting Security Groups and put all end-users to relevant Security Groups
- Event Hander(Create/Modify) need to go through all combinations of the selected security groups for every relevant properties/fields to get a batch of sub Security Groups, break inheriting permission, and grant the permission to the gotten batch of sub Security Groups for the item.
- The Event Handers need to be implemented for all lists/libraries.
- Shortage: Huge challenge to performance and maintain workload.
- Advantage: Filtering/Targeting can be implemented by OOB.
- Create three corresponding metadata sets
- Source code in master page get logged-on user’s properties such as Store Type, Country and Role from Profile list;
- Respectively use three Filter Web Parts(limitation: one Filter Web Part can only pass one property value) to pass values to Target/General Web Parts which will display items(limitation: Target/General Web Parts can only accept one value instead of multi-values of each property. In other words, the items in Target/General Web Parts can and only can targeted/filtered by single value for each property-value.);
- Search result cannot be targeted, which is a big limitation. The “Search trimming” skill of SharePoint can partially resolve it but still cannot avoid the following ones to appear in search result.
- A custom page with web parts that have list web parts on it;
- Reference (Url) to a list/library that contained search term;
- The trimming results may be distributed in several search result pages even some pages are empty.
|<<Store Portal v2 – Enable SSL for SharePoint 2013.docx>>
||<<Enable TDE for Database.docx>>