Extranet Authentication Options for SharePoint 2013

Overview: Most large enterprises using SharePoint have implement Extranet solutions and these vary in complexity greatly.  Many implementation I have seen have morphed into bazaar solutions generally due to the tactical solutions implemented over time and were not caused by poor architecture.  It is the nature of these projects to get something out and with the rapid change in authentication over the past 5 years tons of business have landed in complex scenarios.

Office 365 has grown quickly and using Office 365 is generally a good idea however a lot of organisations still are resistant due to a variety of concerns such as regulatory compliance and trust.  Microsoft is definitely removing these barriers and I'd lean towards hosting the SharePoint Extranet in the cloud in the majority of situations.  The biggest barriers to moving to the cloud are Executive level buy in followed by senior IT folks that are bias to sticking to what they knew 10 years ago.   So a lot of the change is around education and providing a clear road-map.  The biggest technical hurdle will be around identify management.

Pretty much every organisation I deal with used Active Directory and then you may have a Federation Service normally ADFS.  You may have you external users in the same AD, a dedicate DMZ AD, or any other user directory including SQL or other LDAP provider.

Using Office 365/SharePoint Online I need to get both my internal and external users to be work with Office 365 and depending on the client setup I need to work thru both scenarios and think about the ramifications.

Note:  Ramifications are: resetting user passwords, does search work for all users and where does the data reside.

Possible Options:

• AzureAD - Azures ACS for user accounts
• Federated Identifies - use ADFS and build trust with ACS, identity and password is under our company control
• AD sync to AzureAD - Think DirSyng, tooling is ADConnect

On an on-prem. SharePoint farm, the following Authentication methods are supported at the Web Application Level:

1. Classic (Windows (Basic/NTLM/Kerberos)), 
2. CBA - Claims Based Authentication backed by either Windows Claims (Windows (Basic/NTLM/Kerberos)) or SAML Claims (ADFS or SiteMinder or Ping or ThinkTexture, ....)
3. FBA - Forms Based Authentication, and 
4. Anonymous (none)

Notes:
http://www.sharepointeurope.com/blog/2015/10/identity-management-in-a-saas-based-world

SharePoint 2010 Claims based security & Security notes

Non-Active Directory users in MOSS could support Forms Based Authentication (FBA) so can use SQL to authenticate users, or other providers.
Claims based model decouples authentication from SharePoint.  You can declaratively setup multiple providers. Using Claims Based Authentication (CBA) you can now mix multiple users from different sources in a single zone/site.
In MOSS needed a separate web.config for each set of users.
Using claims based providers can logic/meta-data to provide different users rights depending on rights.
SAML - security access markup language, used instead of Windows identity security tokens. SAM is better in that the token is extendable to give additional authority/claims. I.e. can give additional info on the security token.
CBA allows use to authenticate internal Windows users and external FBA users in the same web app.
Note: Once a claim is validated, the user is added to the SPWeb properties: Users, AllUsers & SiteCollectionUsers before they are authorised.  So as long as they have been authenticated they are added to the properties shown above.

More Info:
Claims explained on Channel 9

SharePoint 2010 membership provider/Claims based authentication

What is Claims based authentication?
Allows SharePoint to communicate with external membership providers over open communication standards to authenticate a user. The membership provide determines if the user is valid. A token either saying the user is valid or invalid is returned. More info
Authorisation is handled by SharePoint or the logic can be applied by external membership providers.
Forms Based Authentication (FBA) works with your membership provider to give users access off a provide such as LDAP providers like Active Directory (AD).
You can also setup Windows Authentication in the "Identity Provider" where you use either NTLM or Kerbros as well as other ASP.NET providers.
The SecurityTokenService (STS) Application ensures claims tokens are being passed correctly between the provider and SharePoint (Our SPSite). STS allows for multiple providers plugged in our site. STS is setup in the web.config. More info.
Tip: Sign in Url - when setting up FBA, you can use a custom page to add business logic, for instance I assign rights/permissions when a user comes from a trusted 3rd party. More info.
Tip: FBA doesn't have to use claims based authentication as in MOSS. If you have AD but need to provide Internet access then Claims based adds no value. More info.
NTLM vs Kerbros: NTLM stands for NT Lan Manager. Microsoft's challenge response authentication protocol. Kerbros is an open standard authentication protocol, it is more secure in that it is encrypted and token are used to validate parties in the communication process. Kerbros requires ADFS.  Kerbros is therefore more secure however you do need to have a network that supports Kerbrose for it to work. Kerbros is more chatty and introduces more points of failure. NTML is more efficient. Depending on usage such as Internet it will determine the protocol.  I tend to lean towards Kerbros in larger SharePoint implementations if the network supports.  Internet scenarios don't expose ADFS to the Internet so Kerbros is not an option.

More Info:
Setting up SQL claims based FBA

Updated: 2014-02-27
Setting up ADFS2.0
Configure an Authentication Provider for a Web App to use ADFS

http://www.sharepointpals.com/post/Creating-an-ADFS20-TrustedIdentityTokenIssuer-using-PowerShell-in-SharePoint-2013
http://www.sharepointpals.com/post/How-to-Add-more-than-One-SharePoint-2013-WebApplication-to-a-SPTrustedIdentityTokenIssuer-on-ADFS-using-PowerShell