Azure B2C Authentication for SaaS applications

Overview:  This blog post looks at setting up multiple public federation services on an Azure based SaaS web application.  It is worth understanding that a Microsoft account (old passport accounts) is like a google account and not the same as an Organisational Account (Azure AD IT company (e.g. paul@mycompany.com) setup account.

AAD B2C Overview

1. Client using a browser, goes to a website URL
2. User receives a 302 HTTP response and is redirected to Azure's B2C (AAD and Azure B2C are separate services)
3. User is prompted to login (assuming they don't already have a valid token)
4. After the user is authenticated, they get a Valid token.
5. Using a valid token, the users sessions is established on the web site.

The diagram does not show the flow pass B2C, this shall use "Passive-claims base authentication" to select the users Identity Provider e.g. Google account.  Once the user has a google account authenticated, they are redirected back to the B2C service where the Google token is used to issue a B2C user token for the user.  And step 4 continues.

Azure Active Directory (AAD) also sometimes referred to as AAD B2C
Has two types of users, namely:
1. Members - these are internal company users from an organization e.g., paul.beck@mycompany.com
2. Guests - are external users from outside our company e.g., harry@jpmorgan.com
Tip: Native member users passwords are stored in your Azure B2C service.  Whereas, native guest users e.g. harry@jpmorgan.com, actually logs into JP Morgans AAD and our AAD tenant sees him as a guest and issues a SAML token from us based on JPMorgan's assertion that the user is valid on their AAD tenant.
Note:  A guest user can be made a member and a member user can be changed to be a guest user.  There is no good reason that I have come across for switching guests to members (maybe 2 companies merging) but it is possible if you need to do it.
AAD supports the  following protocols: WS-Federation, SAMLP, & OIDC & OAuth2.  WS-Fed and SAMLP are used but go for OIDC as the default.

AAD B2C Instance:
The diagram above show AAD B2C not B2C.  B2B is provisiong on you Azure tenant and is tied to your O365 instance.  B2C is a separate Azure service used fro managing customers identities.  So if I have a website and some mobile applications, offered an API to clients, I would use B2C not B2B for managing security.  You can connect multiple AAD B2C to your single B2C instance.  B2C basically allows you to connect to other Identity providers using SAML, OIDC, OAuth2 and WS-Fed.  B2C also has the option to use it's own local store if the user doesn't want to connect existing accounts.

If a user has a gmail account, B2C can create an object in the service, but the users password is still maintained by Google.   When accessing our applications, the user goes to the B2C service instance, and then is pushed onto their own IdP (Google in this example) , once they authenticate, they are redirected to the B2C servce, get another new B2C token and are redirected back to the app and shall have access.

Billing/Cost of AAD B2C Service:
B2C is base on Monthly Active Users (MAU), you can have 60k users in the B2C but only 20k of the users have actively logged in using the B2C service.  Dormant/unused accounts in a calendar moth are not counted.
Updated 30 Nov 2019: first 50k MAU's are free for single factor authentication.  It's very cheap per user after the initial 50k and get's cheaper the more you have per user i.e. 50k-100k are £0.0041 per user.  So if I have 61,000 users, the first 50,000 are free and I pay £0.0041 per MAU for the next 11,000 users, amounting to £45.10 for my additional 11k users.
Multi Factor Authentication (MFA) is billed at £0.023 per event (think event as each SMS attempt both successful or failed).  So if the users use MFA and each of the 20k MAU users do 3 MFA's per month on average, the first part is free and the MFA part will cost (20,000 users * 3 attempts * 0.023 per SMS) £1380 per month.  It's a bargain.

More Info:
Great Post from my ex colleague Deepak Srinivasan on Guest and Member AAD access
Understanding ADFS Authentication with SharePoint

SAML, OAuth and OpenID Connect

Rough Notes - Fix

Overview:  SAML has been around for a fair amount of time  (roughly 8 years) and still is widely used for authentication and authorisation of end-users on the Internet.  OAuth2 is used to allow internet users to give internet/web-based applications access to the user's information without the user password.  OpenID Connect is an extension to OAuth2 and generally the way to go instead of SAML for user authentication.

Azure Active Directory Supports:

1. SAML 2.0
2. OAuth 2.0,
3. OIDC, and
4. WS-FED.

SAML:

1. SAML is an umbrella standard that covers federation, identity management and single sign-on (SSO); and
2. SAML is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based a markup language for security assertions.

Limitations of SAML:

1.       It was launched in November 2002 which supports SSO but has now been deprecated by a lot of auth suppliers.

2.       SAML is not supported with native Mobile Applications. Hybrid mobile apps can work with it.

3.       As it has now deprecated, finding it may not be supported by the latest technologies applications and technologies. 

OAuth 2.0:
1. Derived from OAuth, Auth2 uses 2 passwords and is more secure.
2. (Open Authorization) is a standard for authorization of resources. It does not deal with authentication. It was released in 2006.

Limitations of OAuth:

1.       It only deals in Authorization so we have a limitation that we cannot verify the user's identity, i.e. Authentication.

OpenID Connect:

1. OpenID Connect (OIDC) is a protocol to verify user identities and get the user profile information. OIDC enables devices/apps to verify identities based on the authentication done by an authentication server
2. It was launched in February 2014
3. OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework
4. OpenID Connect is built on top of OAuth 2.0, specifies a RESTful HTTP API, and uses JSON as a data format (JWT). It has a specialized set of predefined data types and endpoints for exchanging user information between the identity provider and the application.
5. There are two different types of flows in OIDC, pick the appropriate flow, normally Code flow over implicit.

Advantages of OpenID Connect

1.       It supports SSO and federation.

2.       Has good support with .Net Core.

3.       It supports a wide range of clients like web applications, mobile apps and JavaScript applications.

4.       Have support with Azure AAD B2C as per Microsoft guidelines and others like Google+.

Comparing Differences:

1. https://www.gluu.org/resources/documents/articles/oauth-vs-saml-vs-openid-connect/
2. https://stackoverflow.com/questions/7699200/what-is-the-difference-between-openid-and-saml.
3. https://www.quora.com/What-is-the-difference-between-OAuth-OpenID-and-OpenID-Connect

Support with Azure b2c

1. https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-oidc-idp

Web sign-in with OpenID Connect in Azure Active Directory B2C

1. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/development/enabling-openid-connect-with-ad-fs
2. https://docs.microsoft.com/en-us/aspnet/core/security/authentication/ws-federation?view=aspnetcore-2.2

Using Postman to Generate an OAuth Token Example

Using the Generated Bearer token in a get Request

Tip:  To examine a Bearer token use the website https://jwt.io 

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

Hybrid SharePoint and Office 365 Authentication Thoughts

Overview: Hybrid scenarios allow enterprise users to seamlessly interact between SP Online and SP on-prem instances, provide search across on-prem and online sites, access data on-prem. while using Office365/SP Online, use Office 365 apps like Flow, Video, Graph and utilise OneDrive.  Picking the right authentication allows users to have a seamless high-value experience bringing together secure access quickly.  Pretty important and to make this happen you need to deal with access.

Organisations have internal authentication mechanisms such as Microsoft's Active Directory.  Large organisations have a tough time migrating to the cloud and with the rapid changes in Security and the cloud this post aims to broadly define paths or options for architects such as myself to follow.

Options 1. Do nothing.
The 1st option is to ignore the cloud but I am going to presume you want to take advantage of Office 365.

Options 2.  Only use the cloud/O365.
Office 365 is huge and for a small or new business, I would strongly look at only using O365 using Azure AD (AAD) credentials.  This means no or little management of Active Directory (AD) and you can pretty much connect to the whole Microsoft SaaS offering quickly.  Most large SaaS offering can work with Microsoft AAD.  Generally, this option is not suitable for large enterprises.

Option 3.  Internal AD and externally use Office 365 Azure AD.
Easy to implement as the internal and external credentials do not link.  Your users do not get a single sign-on (SSO) experience.  Users use the Azure AD credentials when working with Office 365 and your internal credentials when working on the internal network.  The user needs two accounts and to know when to use them.

Option 4.  Internal AD synchronized and creates similar accounts on Azure AD.
Pretty much the same option as option 3 but the usernames appear to be the same to the end users. There are a few variations in this space, you can simply create the accounts with the same name either manually, using a CSV import or using Directory Sync (DirSync).  At this stage, the passwords and accounts are managed separately, the DirSync reduces effort and provisions and removes accounts in Azure AD to match the companies on-prem. AD.  DirSync will reach the end of support in April 2017.

Option 5.  Internal AD automatically syncronises with Azure AD including password sync.
You still have 2 accounts but the accounts on both sides are kept aligned using DirSync and password synchronization.  The same password is stored both in your on-prem. AD and in Microsoft's Azure AD for each user.  The advantage here is that the user name and password for a user is the same if using internal or external applications secured by on-prem. AD or AAD.  This is not SSO enabled, the user needs to login to both AD's separately.

Option 6.  Azure Active Directory Connect.
Similar to option 5 but the Azure AD Connect tooling does all the synchronization of accounts between on-prem. AD and AAD.  This option/method is easier than option 5 and the latest approach but fundamentally it is the same approach with 2 identical accounts for each user.
Note: Only 1 AAD Connect per AAD B2C tenant.  If you have multiple AD's (e.g. AD forest), you use a single instance of AAD connect to grab each AD's objects.
Note: AAD Connect can write back properties to AD on-prem. but it can't create objects/account.
Note: AAD Connect can selectively grab accounts e.g. exclude some OU's.
Note: Default replication is every 30 minutes, but he pswd hash syncs every 2 min, you can config Azure password rest to push back to on-prem. AD if you use password hash sync.

Options 7.  Federate (ADFS)

Active Directory Federation Service (ADFS) provides an Identify Provider and can pass claims based authentication between a trusted Identity Provider.  This post does not explain passive Identity authentication but this is the more advanced option.  There are a lot of federation services but ADFS tends to be the most common (ThinkTexture, Ping, SiteMinder).

Home Realm Discovery (HRD)

When accessing SharePoint Online, you go to AAD as each SPO has it's own AAD.  On AAD you may have ADFS, partners Ping Federation service, other organisations AAD to actually authenticate the user.  So the login experience needs to know where to authenticate the user.  To do this use MS and you can also build custom HRD.  When the user enters the username or email, they are forwarded onto the appropriate ADFS or Federation service to authenticate the user.

Ariel Gordon describes HRD at Microsoft below: 

"How does Home Realm Discovery work?

In the cases above, apps direct users to Azure AD's common endpoint, and Azure AD shows a generic sign-in page. This page waits for users to enter their username then, as soon as the focus moves away from the username field, it makes a server call to look up the configuration for the user's domain. In case of a federated domain, the login page then initiates a redirect to the federation server, such as ADFS. Users then enter their credentials on the federation server's own login page which displays their organization's branding.

When we introduced Company Branding last year, we mimicked this UX behaviour: the Azure AD sign-in page starts off with generic branding then looks up the organization's branding elements after the server call is made. In both cases (federation and company branding) the goal is to ensure that users enter their credentials on a page that reflects their organization's brand.

When does it make sense to bypass Home Realm Discovery?

If your application targets users in a single organization, there's no need to use Azure AD's Home Realm Discovery and you can "accelerate" users to their organization's sign-in page. To do this, your application needs to pass a domain hint to Azure AD, effectively stating "I've already established that the user who's about to sign in is from <this organization>."

When Azure AD receives such a hint, it performs Home Realm Discovery on the domain name hint before rendering a single pixel. If the domain is federated, Azure AD immediately redirects users to the federation server. If the domain is managed, it checks whether Company Branding has been configured for the domain and displays it when found."

FedAuth Notes for Problem Solving

Overview:  These are my notes on FedAuth relating to SharePoint 2013.

SharePoint (SP) 2013 uses Claim Based Authentication (CBA).  In this example, I am looking at SiteMinder (a CA product) as the Federation Service (this is the equivalent to ADFS (Active Directory Federation Service) as the Identity Provider (IdP)).
Basic Flow of SP CBA Authentication:

1. SP looks for a FedAuth cookie; if  there is no FedAuth cookie for the users, it shall redirect the user to login via the IdP (AAD/SiteMinder/ADFS et al.). 
2. The IdP returns a valid SAML token to SharePoint's STS.
3. The STS generated a FEDAUTH cookie for the user to hold the current users session lifespan state (to keep the user log in).  The user holds the STS token not the SAML token.  The FedAuth in is a pointer to the SAML token held in the SharePoint Token Cache.

The default behaviour of SharePoint is to store the FEDAUTH cookie on the user’s disk, with a fixed expiration date. The expiration of the FEDAUTH cooking can be for a fixed time or a sliding session (if the user interacts with SP, the SP session is extended).  FedAuth can be stored on the Disk (default or in memory (not persisted between browser close downs). 

Note:  Changing where the cookie is stored affects the way the user shall login and effects Office application login such as Word.  Test thoroughly before changing)

Note:  Watch the IdP providers expiration policy vs what you set up in SP.  As an example, you could remove a user from the IdP, however, the session is still persisted and the user can still interact with SharePoint.   From MSDN "Make sure that the value of the LogonTokenCacheExpirationWindow property is always less than the SAML token lifetime; otherwise, you'll see a loop whenever a user tries to access your SharePoint web application and keeps being redirected back to the token issuer." 

Note: Closing a browser window with the FEDAuth stored to Disk does not invalidate the SharePoint session.  So the FedAuth shall persist when IE is close.  However, by keeping the session lifespan/FedAuth lifetime relatively short, the  to be relatively short (think less than an hour) your security is better.
Note: Change from FedAuth to session based sessions should taken lightly, Office products need to be thoroughly tested and generally won't work seamlessly.

Updated 11 Feb 2019: rtFA cookie
"The root Federation Authentication (rtFA) cookie is used across all of SharePoint Online and the rtFA cookie is used to authenticate the user silently without a prompt.  So when moving from OneDrive to SPO or Admin sites, the user does not get additional prompts for login.  When a user signs out of SharePoint Online, the rtFA cookie is deleted."

References:
SharePoint Authentication and Session Management
https://msdn.microsoft.com/en-us/library/hh446526.aspx
Remote Authentication for SharePoint Online (RTFA)
Why IE and Office work together in SP
Adding, removing SP claims and managing security using claims  and NB! also
Logout of SharePoint

 NB!  http://blog.robgarrett.com/2013/05/06/sharepoint-authentication-and-session-management/

Check Cookie TimeOut; set by formula:
FedAuth LifeTime = IdP endpoint SAML token lifetime Duration - STS LogonTokenCacheExpirationWindow

Update 04 Feb 2016: screenshot for clarity:

My blog post on changing from FedAuth to session based cookies.  The post also shows how to examine the cookies for Internet Explorer (IE).

Identity Providers for SharePoint

Overview:  I have worked with and evaluated a couple of Services and Federation Server products.  Here is an old pot of setting up claims, at the bottom I have some thoughts on different services/server products.

Background: SAML and WS-Federation protocols are standard Single Sign-On protocols, the following version exist:

• SAML 1.0, SAML 1.1, SAML 2.0
• WS-Federation

Security Assertion Markup Language (SAML) is an XML-based protocol for exchanging authentication and authorization data between security domains.

SAML enables web-based authentication scenarios including cross-domain single sign-on (SSO).  SAML is a token representing a principal that normally represents a user but can represent an app.

  

Other terms to understand:

• Identity provider (IdP) think ADFS/Azure ACS,
• Service provider (SP) is the SAML consumer in our context this is SharePoint but this can be an MVC app.
• Realm

OOTB SP2010 and SP2013 support SAML1.1 not SAML2.0, you can write custom code or use a Federation Server like ADFS to convert the SAML2.0 so it will work with SP.

Identity Provider (IdP) Products:

1. Microsoft ADFS
2. Ping Federate
3. ThinkTexture Identity Server
4. CA-SiteMinder
5. IBM Tivoli (CAM)
6. Oracle Access Manager
7. ComponentSpace
8. Shibboleth
9. RSA Federated Identity Manager
10. Entrust GetAccess

 IdP Services:

1. Azure Active Directory
2. LiveId
3. Google
4. Facebook
5. LinkedIn
6. Yahoo

This list is in no way exhaustive, pls post if you feel I am missing any providers.

SharePoint 2013 on-prem using Windows Live Id via Azure ACS

Overview:  I have a pretty simple requirement to allow users to register on my customers public SharePoint 2013 web sites.  I have setup custom providers and thought ACS was going to make me a hero at my client.  The whole experience is terrible and I can't see why anyone would use the default of LiveId via ACS due to the implementation.

Opinion: I hate the way ACS works with Windows Live Id, it is so bad I can't see a scenario when a client would use it.

Anyway, I have SP2013 SP1 on-prem and I want to hook at ACS allowing customer to register on the site and get elevate permissions on the site.  I'd like them to use multiple 3rd party authentication providers such as Facebook, Windows Live Id, LinkedIn and Google.  In my PoC I decide to simply use Live Id as it is the default on ACS and as both services are Microsoft owned it must be the easiest. 

I worked thru Wictor Wilem's post series and as usual Wictor has provide a great resource.  I had to make minor adjustments to get it to work for me on SP2013 but overall, Wictors series of posts is a good place to start.

The 1st issue I got was when logging in using Windows Live ID, I was continuously redirect back to the /_login/default.aspx page.

After bashing my head trying to figure out what the issue was I realised in Wictor's common issues post in the series, he mentioned the claims mapping/rule needs to be adjusted for Live ID authentication. 

I now was getting an access denied, which at least told me the claim was hooking up.

The next issue was now I was getting the message you are not authorised "Sorry, this site hasn't been shared with you."

Give all authenticated users access to the site as shown below.

Once you login you will notice a horrible looking user that is logged in.   You can assign permissions using the "Friendly Username".

Common public Federation (IdP) Identifcation provides are:

• LiveId (MS - not where you would expect the MS offering to be)
• Google (constantly changing - easy hookup)
• FaceBook
• LinkedIn

Common Enterprise IdP Servers/Services are:

• Microsoft ADFS (best default option for greenfield SP)
• PingFederate (pretty expensive but a comprehensive solution, use if already in place or the advanced features really suit the business at an enterprise level)
• ThinkTextures IdentityServer (Great for customisation, difficult support but for the hardcore tecky type organisation a good option)
• CA-SiteMinder (Good product, used in enterprises and hooks up well to SP.  Has a large set of tools and options).  Update: 19-Nov-2015, seen another large implementation of SiteMinder, it has expensive add-in modules and extremely problematic.  SP agent needs AD groups.
• RSA Federated Identity Manager (No experience)
• Entrust GetAccess (No Experience)
• IBM Tivoli (CAM) (Had a hard time with this a few years back)
• ComponentSpace (Good for .NET customisations, not a large Federation service Server)

ACS for SharePoint 2013 in a Picture

CBA for Developement

Problem: Claims Base Authentication (CBA) requires swapping certificates with each machine that will use CBA on a development domain, if you have 20 dev machines you will need to swap certs with ADFS and 20 developer machines. 

Note: This post assumes all dev machines are on a single domain however several approaches will work on a standalone machine however.  If ADFS is present on the local dev use it for CBA in your development environment.

Initial Hypothesis:
If your VM's are all on the same domain you can always use classic mode authentication and test the CBA on a build server.  This does not make the dev env mimic the test, QA & production servers that are using claims for authentication.
 
Resolution:You could setup your own STS server/Service (feeding off SQL or LDAP) or use the WIF toolkit to create a claims service.
Or use SelfSTS tool to generate claims that SharePoint can consume.

More info:
Setting up and testing your own STS Service
http://msdn.microsoft.com/en-us/library/ff955607.aspx
http://blogs.msdn.com/b/sharepointdev/archive/2011/09/12/claims-architecture-for-sharepoint-2010-developers.aspx
http://archive.msdn.microsoft.com/SelfSTS/
Simple channel 9 Video explain CBA & WIF