Showing posts with label IdP. Show all posts
Showing posts with label IdP. Show all posts

Monday 26 October 2020

Identity Server - OAuth and OIDC

Overview:  The current version of Identity Server is 4.  Identity server is basically a .NET Core 3.1 application that is an Identify Provider (IdP) similar in role to PingId, SiteMinder, AAD b2C.  Identity server allows application (native mobile, web sites and servers) to securely authenticate users.  In this post OAuth means OAuth2.0.

OAuth2 Grant Types:

Flow Description Client Grant Type
Authorization with PK Authorization Code Grant Type.  Default choice for authorization. Native mobile Apps, Windows app, Browser Apps Code
Client Credential Server-to-server (S2S) communication also refereed to as Machine-to-machine (M2M). Server,Consoles,Services ClientCredentials
Implicit Rather use the Authorization Code Flow with PKCE Native Apps & SPA's often use Implicit Flow Implicit
Hybrid
Device
Resource Owner Pswd Don't use

Scopes: The authorisation Server specifies the "scope" that the user has consented too.  So for an API you can limit the actions the user can perform.  Scopes must be unique strings.  Recommendation is to name your scopes by the API and the Verb e.g. "pauls_api.read" is better than "read".  Scopes are used to give the user access to resources so "read" is not a good idea.  Also scopes have length limits so don't be crazy verbose in naming.

Mandatory Endpoints:  OAuth specifies 2 endpoints namely:
  1. /authorization endpoint - gets the access grant and user consent (only code and implicit flows use this endpoint)
  2. /token Endpoint - issues tokens (client credential only uses the token endpoint, obviously code & implicit flow use both endpoints)
Optional Endpoint Extensions:
  • /revoke - used to revoke a token
  • /userinfo - used to hold profile info for the user e.g. name, email.  The /userinfo endpoint is used in OIDC implementations of OAuth and specifies user must use: address, phone, email, profile in their scopes.
  • /.well-known/oauth-authorization-server - useful to discover the actual OAuth implementation.
Tokens
Access Token:
  • JSON Web Token (JWT) pronounce "JOT" is an access token that contains authorisation and profile data.  The alternative is to use Opaque to JWT but most implementations use JWT.  
  • JWT's need to be validated using the signature.  The JWT Access Token is base 64 encoded and are made up of three parts separated by period signs i.e. HEADER.PAYLOAD.SIGNATURE


Refresh Token:
  • Refresh tokens are opaque
  • Single endpoint with a single function to get a new Access Token.


Interactive description of the OAuth Code Flow process:


Wednesday 22 May 2019

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

Monday 6 June 2016

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."

Sunday 16 August 2015

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).

Thursday 19 March 2015

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.

Tuesday 19 August 2014

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)