ADAL : Use of token cache in Azure multi-tenancy

Very good Patterns and Practices series of posts here on developing an Azure multi-tenant application.

Part of this is the issue around caching the tokens.

The article has this to say:

"It's relatively expensive to get an OAuth access token, because it requires an HTTP request to the token endpoint. Therefore, it's good to cache tokens whenever possible. The Azure AD Authentication Library (ADAL) automatically caches tokens obtained from Azure AD, including refresh tokens.

ADAL provides a default token cache implementation. However, this token cache is intended for native client apps, and is not suitable for web apps:

• It is a static instance, and not thread safe.
• It doesn't scale to large numbers of users, because tokens from all users go into the same dictionary.
• It can't be shared across web servers in a farm.

Instead, you should implement a custom token cache that derives from the ADAL TokenCache class but is suitable for a server environment and provides the desirable level of isolation between tokens for different users."

Just something to keep in mind!

Enjoy!

Identity : The Microsoft landscape

I get asked a lot about this.

• What is the stack?
• What are the pieces?
• How do they fit together?

There doesn’t seem to be a short, compact overview about this.

So in the spirit of the Github admin who when I ask “Is this feature available and if not when”? replies “Send me a PR”, here goes:

A very short summary – you could write a book on each :-)

In no particular order:

AD DC

Active Directory Domain Controller

The heart of Microsoft on-premises Identity.

It stores users, groups, group policy, printers etc.

Authentication is via Kerberos or NTLM.

In the same domain, IWA can be used if the browser is configured correctly.

AD LDS

Active Directory Lightweight Directory Server - aka ADAM.

Provides ability to store application specific attributes.

Can have many instances on a server, each with a different schema.

Not domain centric.

With ADFS 4.0 (Server 2016) can be used for authentication - ADFS : Authenticating with LDAP.

ADFS

Active Directory Federation Services.

On-premises.

Sits on top of AD. 

Provides WS-Fed / SAML 2.0 / OAuth2 (Server 2016) federation functionality.

Authentication is via WS-Fed or SAML 2 or OAuth.

Has claims rules to manipulate the claims. 

ADFS 4.0 (Server 2016) will support OpenID Connect and OAuth 2.0.

ADFS 4.0 (Server 2016) will authenticate against v3 LDAP or SQL Server.

Has DRS capability to allow devices to be “domain joined”.

Supports IWA.

Can federate with other IDP e.g. OpenAM, Ping Federate, shibboleth, simpleSAMLphp etc.

ADFS 2.0 was a separate download. From then on is a server role and part of the base server.

WAP

Web Application Proxy.

On-premises.

A proxy for ADFS.

Allows ADFS to sit behind a firewall.

Functionality is being added to make it closer to what TMG provided.

Azure AD

Azure Active Directory.

NOT AD in the cloud.

You can think of it as combining AD and ADFS functionality.

Graph based (not LDAP). Supports users and groups only.

Windows 10 devices can be added via “AD Join”.

Has three levels viz. Free / Basic / Premium. Comparison here  – Azure Active Directory editions

Claims collection is hard-coded.

Has outbound SCIM support.

Azure AD Connect

Utility to sync. configured AD attributes from AD to Azure AD. 

This provides Same Sign On. Adding ADFS provides Single Sign On.

Was previously called DirSync.

Azure AD Application Proxy

WAP in the cloud.

Azure AD Domain Services

AD DC in the cloud.

Authentication is via Kerberos or NTLM.

Azure B2C

Business to Consumer.

Allows external user management - registration, SSPR, social logins

Azure B2B

Business to Business

Automated way to provision users so they can authenticate across tenants.

B2B vs. B2C - Comparing capabilities for managing external identities using Azure Active Directory.

Azure Access Panel

Allows end-users to launch their apps and access the self-service features that allow them to manage their apps and group memberships.  

ACS

Access Control Service

The "old" way to connect to social logins - superseded by B2C.

Azure MFA

Multi Factor Authentication.

Easily integrated with Azure applications or on-premises via agent in conjunction with ADFS.

Azure AD Connect Health

Helps monitor and gain insight into on-premises identity infrastructure and the synchronization services.

Monitoring capabilities for key identity components e.g. ADFS, Azure AD Connect, AD DC etc.

Makes the key data points about these components easily accessible, making it easy to get usage and other important insights.

Azure AD Identity Protection 

Helps prevent the use of compromised accounts using industry leading machine learning (ML) based real time detection and automated mitigation.

Helps protect all of the cloud and on-premises applications customers use with Azure AD.

Can auto-remediate by intercepting the request with an adaptive MFA challenge such as an SMS, phone call, push notification or a request for OATH token.

Azure AD PIM

Privileged Identity Management.

Discovery and control of who has administration rights where and when.

Microsoft Advanced Threat Analytics

Detects suspicious user and entry activity, known malicious attacks and security issues.

Cloud App Discovery

Helps IT departments learn which SaaS apps are being used throughout the organization.

Can measure app usage and popularity so that IT can determine which apps will benefit the most from being brought under IT control and being integrated with Azure AD.

Azure SaaS Market Place 

Aka Gallery - Active Directory Marketplace.

Instantly configure popular SaaS cloud applications on Azure AD for SSO and easier user account management.

Wrappers

WIF / OWIN / ADAL : Identity Libraries: Status

Also WIF : Wrappers around protocols  

And OWIN : Differences with WIF

WIF

Windows Identity Foundation.

Provides WS-Fed client protocol support for .NET applications.

Can be passive (browser) or active (WCF).

Older technology.

Capability provided by web.config configuration.

WIF 1.0 (3.5) is a separate download. WIF 4.5 is part of the framework.

OWIN

Open Web Interface for .NET.

Replaces WIF.

Provides WS-Fed / SAML 2.0  / OpenID Connect / OAuth 2.0 client protocol support for .NET applications.

NuGet packages here:

• Microsoft.Owin.Security.WsFederation  
• Microsoft.Owin.Security.OpenIdConnect 
• Kentor.AuthServices.Owin

Capability provided by code.

Can be used for web applications or web API.

.NET Core 1.0 support for OpenID Connect / OAuth 2.0.

Aimed at Azure AD / ADFS with hybrid mode – not a general purpose stack.

ADAL

Active Directory Authentication Library.

OpenID Connect / OAuth 2.0 client protocol support for native devices.

API so underlying protocol could be changed at some future point.

Libraries for JavaScript, Java, PHP etc.

Capability provided by code.

Aimed at Azure AD / ADFS with hybrid mode – not a general purpose stack.

MSAL

Microsoft  Authentication Library - V2 API.

Unified library that helps to develop applications that work with Microsoft Accounts, Azure AD accounts and Azure AD B2C users indifferently – all in a single, streamlined programming model.

Targets the "converged model" i.e. Microsoft Accounts and "Work or School" Accounts combined.

"Successor" to ADAL with the important proviso that it will not work with ADFS and the original Azure AD V1 API.

Microsoft Graph

Was Office 365 Unified API / Graph API.

Exposes multiple APIs from Microsoft cloud services through a single REST API endpoint (https://graph.microsoft.com).

MIM

Microsoft Identity Manager.

Used to be FIM.

Synchronizes identities between directories, databases and applications.

Self-service password, group and certificate management.

Enjoy!

OAuth : Microsoft OWIN (for Identity) and ADAL are not general purpose libraries

I'm seeing a lot of confusion about this.

Microsoft has OWIN client libraries for OpenID Connect / OAuth2.

It also has ADAL - Active Directory Authentication Library (used mainly for native devices).

Both implement the protocols so you would think that you can use these to hook up to any server that implements OpenID Connect / OAuth.

Except that you would be wrong.

OAuth is notorious for incompatibility so you can't really mix and match.

These libraries are aimed at a specific use case i.e. the server is either Azure AD or ADFS.

In addition, the profile is hybrid flow so if your server doesn't implement that you are already out of luck,

Which is not to say that it won't work in some cases.

e.g. IdentityServer 3 does implement the hybrid flow.

Refer : IdentityServer : The WebApp-OpenIDConnect-DotNet Azure AD sample.

Here I show how to use the OWIN library to connect to IdentityServer 3. As you can see, I had to make some alterations.

Enjoy!

ADFS : OpenID Connect and ADAL

This is for Active Directory Federation Services / "AD FS" / ADFS on Windows Server 2016 (currently Technical Preview 2).

My server is in an Azure VM.

It also uses the Active Directory Authentication Library (ADAL).

This is based on AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet.

This is for Azure AD and is a web application that requires authentication with AAD and then calls a secure Web API that uses the current JSON token. The Web API is the Graph API that you use to get attributes from AAD.

So let's translate this to ADFS which now supports OpenID Connect. Somewhat annoying that all the samples are for Azure and none for ADFS, ADFS needs to feel the love :-).

<add key="todo:TodoListResourceid" value="https://myPC/TodoListService" />
<add key="todo:TodoListBaseAddress" value="https://myPC" />
<add key="ida:ClientId" value="OpenIDConnect1234" />
<add key="ida:AppKey" value="[Enter app key as obtained from Azure Portal, e.g. dYfh0H8iRU7FIBnPcYIil/Af6SSAwkxVhB0mA8DbzdQ=]" />
<add key="ida:Tenant" value="adfs.local.cloudapp.net" />
<!--<add key="ida:AADInstance" value="https://login.microsoftonline.com/{0}" />-->
<add key="ida:AADInstance" value="https://adfs.local.cloudapp.net/adfs" />
<add key="ida:PostLogoutRedirectUri" value="https://myPC/TodoListWebApp" />

Changes for the application web.config as above.

I changed StartUp.Auth.cs to the simpler:

app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseOpenIdConnectAuthentication(
     new OpenIdConnectAuthenticationOptions
     {
         ClientId = clientId,
         Authority = Authority,
         PostLogoutRedirectUri = postLogoutRedirectUri,
     });

The ADFS client OAuth configuration is:

 OK - so let's run up this puppy.

We get this error:

MSIS9221: Received invalid OAuth authorization request. The 'redirect_uri' parameter is missing or found empty. Public clients must send the redirect_uri parameter with valid redirect URI in the OAuth authorization request.

Looked through the OWIN code and couldn't see anywhere where this is passed.

So I manually added it to the URL at the end in the browser:

 &redirect_uri=https%3A%2F%2FmyPC1%2FTodoListWebApp

Then off to ADFS, authenticate and back we come.

Clearly, still some work to do with ADAL and TP2!

Enjoy!

ADFS : Protecting Web API with OAuth2

This is for Active Directory Federation Services / "AD FS" / ADFS on Windows Server 2016 (currently Technical Preview 2).

It also uses the Active Directory Authentication Library (ADAL).

Vittorio has a good overview describing Server 2012 behaviour over at Securing a Web API with ADFS on WS2012 R2 Got Even Easier.

How does that look on Server 2016?

The VS solution is pretty much the same. I added a Windows Forms project to the solution which is my native client and the code for that (behind the button) is pretty much the same as  the above post. This calls a web API project in the same solution.

private async void button1_Click(object sender, EventArgs e)
{
            string authority = "https://ADFS_local.cloudapp.net/adfs";
            string resourceURI = "https://myPC/WinServTP2ADALWebApplication/";
            string clientID = "API1234";
            string clientReturnURI = "https://myPC/WinServTP2ADALWebApplication/";

            AuthenticationContext ac = new AuthenticationContext(authority, false);
            AuthenticationResult ar = ac.AcquireToken(resourceURI, clientID, new Uri(clientReturnURI));

            string authHeader = ar.CreateAuthorizationHeader();
            HttpClient client = new HttpClient();
            HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, "https://myPC/WinServTP2ADALWebApplication/api/Values");
            request.Headers.TryAddWithoutValidation("Authorization", authHeader);
            HttpResponseMessage response = await client.SendAsync(request);
            string responseString = await response.Content.ReadAsStringAsync();
            MessageBox.Show(responseString);
}

ADFS_local is a Windows Server 2016 server running as an Azure VM.

Over to ADFS.

The OAuth client now has wizard support as opposed to the PowerShell in the post. It looks like:

You do this under "Clients".

We add the RP manually and notice the new OAuth option.

Notice also the extra menu items on the LHS for OAuth.

You can click on the "All Clients" to add more permissions (scopes). At the moment, it is just for "openid". You could also click on "Add" and select a specific client.

I added "email" and "profile".

(BTW, there is a separate "Scope Descriptions" item in the main menu).

Then choose your Access Policy on the next screen - in this case "Permit everyone". Review and you are done.

So looking at our RP, we have an identifier:

and some OAuth permissions - notice the new tab. That's pretty much it.

OK - so now we have the client and the web API RP all configured and ready to go.

Time to run up the client:

Click the button which calls the API. This is protected as per the configuration and so we get the ADFS logon screen. Authenticate with ADFS and:

We are done!

Enjoy!

Azure : Help me pick an authentication scenario / library

tl;dr - Read the "Authentication Scenarios" and "Which Azure authentication library" articles referenced below.

Starting with Azure Active Directory:

Windows Azure Active Directory Authentication Libraries

which covers:

• Windows Azure AD Authentication Library for .NET
• Windows Azure Authentication Library for Windows Store
• Windows Azure AD Node.js Module

Authentication Scenarios for Azure AD

Azure Active Directory Code Samples

Vittorio Bertocci has a few blogs around Azure Directory Authentication Library (ADAL):

Search results for "adal"

Also:

Which Azure authentication library should I choose? 

And protocol overview:

Azure Active Directory Authentication Protocols

Enjoy!